Re: Processor-specific code

I believe that you understand incorrectly. Of course, you're right. We can choose not to support alteration of rounding mode, but we might want to add that nice feature into gfortran. So, I'll stop invoking the standard, but I still think it would be interesting. Of course, since noone seems to

Re: My opinions on tree-level and RTL-level optimization

On Sat, 16 Apr 2005, Richard Kenner wrote: > Although, RTL expansion may introduce new loops, these tend to be > rare, and the expanders have all the information they need to > hoist/sink invariant expressions and unroll/peel themselves. > > I disagree. In order to make the proper dec

Re: Processor-specific code

"Joseph S. Myers" <[EMAIL PROTECTED]> writes: > On Thu, 14 Apr 2005, Richard Henderson wrote: > > > On Thu, Apr 14, 2005 at 10:47:26AM -0700, Steve Kargl wrote: > > > Does gcc support > > > #pragma STDC FENV_ACCESS > > > > No, but we currently act like access is "on". > > I thought we acted li

Re: Processor-specific code

Paul Koning <[EMAIL PROTECTED]> writes: > > "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: > > Dave> Original Message > >> From: Paul Koning Sent: 15 April 2005 17:56 > > >>> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: > >> > Dave> Doesn't the C language spec require th

Re: Heads-up: volatile and C++

Jason Merrill <[EMAIL PROTECTED]> writes: > On Thu, 14 Apr 2005 10:12:37 -0400, "Michael N. Moran" <[EMAIL PROTECTED]> > wrote: > > > Jason Merrill wrote: > >> The C++ committee (well, a subgroup represented at this meeting by Hans > >> Boehm) is working on a memory model that supports threaded

Re: GCC 4.0 RC1 Available

Andrew Haley <[EMAIL PROTECTED]> writes: > Ranjit Mathew writes: > > Geoffrey Keating wrote: > > [...] > > > which I see you've already committed a patch for, and a large number > > > of Java failures. > > > > > > You can see full test results at > > [...] > > > > > >

Re: empty switch substituion doesn't erase matching switch?

On Sun, Apr 17, 2005 at 07:48:53PM -0700, Gary Funck wrote: > This usage of a null substitution came up while I was trying to use > this form of spec. for a different switch, but the following illustrates > the problem using the existing gcc compiler as built for Redhat Linux > running on an SGI Al

RE: function name lookup within templates in gcc 4.1

Thanks for the verification! Regards, Gareth Pearce > > > On Apr 17, 2005, at 10:37 PM, Gareth Pearce wrote: > > > So I just started trying out gcc 4.1 - with a program which compiles > > and > > runs fine on gcc 3.3. > > > > Attached is a reduced testcase which shows runtime segfault due to >

empty switch substituion doesn't erase matching switch?

This usage of a null substitution came up while I was trying to use this form of spec. for a different switch, but the following illustrates the problem using the existing gcc compiler as built for Redhat Linux running on an SGI Altix: Given a spec of this form, %{S:X} substitutes X, if the -S

Re: Processor-specific code

FX Coudert wrote: [attribution lost] > > You'll find that globally changing the rounding mode will screw up > > libm functions. Which is pretty much going to make this useless. > > OK. I didn't know that, and it's going to be annoying. So, the GNU libm > doesn't enable us to call mathematical fun

Re: function name lookup within templates in gcc 4.1

On Apr 17, 2005, at 10:37 PM, Gareth Pearce wrote: So I just started trying out gcc 4.1 - with a program which compiles and runs fine on gcc 3.3. Attached is a reduced testcase which shows runtime segfault due to stack overflow if compiled with 4.1 but does not with 3.3. Trivial work around is

Re: GCC 4.0 Freeze

On Sat, Apr 16, 2005 at 11:37:14PM -0400, Jack Howarth wrote: >Even if there were complete g77 compatibility in g95, folks may want > to stick with the g77 version from gcc 3.4 for awhile purely for > performance reasons. In doing some test runs of the APBS > Adaptive Poisson-Boltzmann Solver

function name lookup within templates in gcc 4.1

So I just started trying out gcc 4.1 - with a program which compiles and runs fine on gcc 3.3. Attached is a reduced testcase which shows runtime segfault due to stack overflow if compiled with 4.1 but does not with 3.3. Trivial work around is to move the specific declaration above the template d

Re: C++ ABI mismatch crashes

Mike Hearn <[EMAIL PROTECTED]> wrote: I have a copy of Inkscape compiled with GCC 3.3, running on a GCC 3.4 based system. All of the C++ libraries it links directly against, like GTKmm, are statically linked. In other words, it dynamically links against no C++ libraries. Inkscape dlopens libgtkspel

Re: Processor-specific code

You'll find that globally changing the rounding mode will screw up libm functions. Which is pretty much going to make this useless. OK. I didn't know that, and it's going to be annoying. So, the GNU libm doesn't enable us to call mathematical function with non-default rounding mode? IIUC, this i

Re: How to -Werror in a fortran testcase?

On Sunday, April 17, 2005, at 03:54 AM, Paul Brook wrote: Doesn't dejagnu do this anyway? Ie. any unexpected errors or warnings will cause the test to fail. Yes, see ``excess''.

gcc-4.1-20050417 is now available

Snapshot gcc-4.1-20050417 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050417/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 CVS branch with the following options: -D2005-04-17 17:43 UTC You'll

Re: Vectorizing my loops. Some problems.

On Sat, 16 Apr 2005, Øystein Johansen wrote: > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > make: *** [neuralnet.o] Error 1 > > Should I report this to the bug database or is this a known bug? And > what is it a

[RFC] warning: initialization discards qualifiers from pointer target type

> warning: initialization discards qualifiers from pointer target type > > This warning can not be disabled using -Wno-cast-qual > (or any other warning flags). Is it intentional ? > Otherwise I'll prepare patch. > > const char *a( void ) > { >return "abc"; > } > > int main( void ) > { >

[RFC] warning: initialization discards qualifiers from pointer target type

warning: initialization discards qualifiers from pointer target type This warning can not be disabled using -Wno-cast-qual (or any other warning flags). Is it intentional ? Otherwise I'll prepare patch. Thanks, - Devang const char *a( void ) { return "abc"; } int main( void ) {

Re: internal compiler error at dwarf2out.c:8362

James E Wilson wrote >You shouldn't be trying to build your own types in a machine dependent >attribute handler function. The compiler's type system is determined by >front-ends mainly, and some middle-end infrastructure, and isn't your domain >to mess with. This stuff is subject to change, at

Re: C++ ABI mismatch crashes

On Sat, 16 Apr 2005 21:30:55 -0700, Joe Buck wrote: > Do we really promise somewhere that this will work? I know that we warn > in other places that it probably will not. Yes, see the "Testing Multi-ABI binaries" section here: http://gcc.gnu.org/onlinedocs/libstdc++/abi.html > Yes, symbol versi

re: Problem with weak_alias and strong_alias in gcc-4.1.0 with MIPS...

"Steven J. Hill" <[EMAIL PROTECTED]> wrote: I have a working MIPS cross toolchain with: binutils-2.15 gcc-3.4.2 glibc-2.3.4 linux-2.6.12 and then decided to work with gcc-4.1.0 out of the cvs head. I am now getting build problems with glibc-2.3.4 with the first major snafu being: ../sys

Re: My opinions on tree-level and RTL-level optimization

Am Sonntag, 17. April 2005 16:26 schrieb Daniel Jacobowitz: > On Sun, Apr 17, 2005 at 03:19:43PM +0200, Björn Haase wrote: > > Hi, > > > > while lacking the deep insight into GCC internals most of you have, I'd > > never the less like to ask you to be very prudent concerning the issue of > > remova

Re: GCC 4.0 RC2 Status

> I'm not going to wait very long even for this bug, though. Instead, I'm > going to get 4.0.0 out the door, and move on to 4.0.1, sticking as close > to the announced schedule as possible. FWIW the recent Java failures have been fixed (thanks to the Java hackers!) on SPARC, so the 4.0.0pre comp

Re: My opinions on tree-level and RTL-level optimization

On Sun, Apr 17, 2005 at 03:19:43PM +0200, Björn Haase wrote: > Hi, > > while lacking the deep insight into GCC internals most of you have, I'd never > the less like to ask you to be very prudent concerning the issue of removal > of seemingly unnecessary RTL optimizations. > In contrast to 32 bit

Re: Heads-up: volatile and C++

On Thu, 14 Apr 2005 23:11:03 -0400, Diego Novillo <[EMAIL PROTECTED]> wrote: > Again, not always. Consider chaotic asynchronous algorithms > (like variations of simulated annealing). They need no locks nor > any other kind of synchronization, though sometimes they'll use > some form of control s

Re: My opinions on tree-level and RTL-level optimization

Hi, while lacking the deep insight into GCC internals most of you have, I'd never the less like to ask you to be very prudent concerning the issue of removal of seemingly unnecessary RTL optimizations. In contrast to 32 bit targets, for 8 and 16 bit targets the RTL representation possibly might

Re: The subreg question

Hi, I have been working on very similar issues for the avr target. You might have a look at the patch I have posted today and the corresponding discussion thread at the gcc-patches list. I have also observed, that gen_highpart and gen_lowpart sometimes causes an ICE for reasons. ... did not f

Re: How to -Werror in a fortran testcase?

On Saturday 16 April 2005 19:32, Richard Guenther wrote: > Hi! > > gfortran does not support -Werror it seems. It should, this is a bug. > What do I need to put in dg-options to make a testcase fail, if there is > any warning? Doesn't dejagnu do this anyway? Ie. any unexpected errors or warnings

Re: Problem with weak_alias and strong_alias in gcc-4.1.0 with MIPS...

Steven J. Hill <[EMAIL PROTECTED]> wrote: > ../sysdeps/ieee754/dbl-64/s_isinf.c:29: error: 'isinf' aliased to > undefined symbol '__isinf' > ../sysdeps/ieee754/dbl-64/s_isinf.c:31: error: '__isinfl' aliased > to undefined symbol '__isinf' > ../sysdeps/ieee754/dbl-64/s_isinf.c:32: error

Re: Cross Compile PowerPC for ReactOS

James Tabor wrote: Hi! I started resurrecting PowerPC WinNT GCC support, Ha! I'm running into this atm. /home/gcc-3.4.3-ros/CROSS/gcc/xgcc -B/home/gcc-3.4.3-ros/CROSS/gcc/ -B/usr/powerpcle-pe/bin/ -B/usr/powerpcle-pe/lib/ -isystem /usr/powerpcle-pe/include -isystem /usr/powerpcle-pe/sys-include

The subreg question

I have a chip which is developed by other lab. It's VLIW architecture and it contains 2 RISCs and 8 DSPs. The size of all registers are 32 bits. There is a special instruction in the RISC which is called `movi' (move immediate). Its syntax and semantic are: movilr1, # (moves # to LSB 16-bit,