--- Comment #7 from rguenth at gcc dot gnu dot org 2006-08-09 07:31 ---
So, I have a fix as the problem is latent on mainline, too.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from bonzini at gnu dot org 2006-08-09 07:42 ---
Uhm, fixing this will resurface a wrong-code bug, PR28651, which is more
important than this missed optimization. :-(
--
bonzini at gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from pluto at agmk dot net 2006-08-09 09:45 ---
works fine with 4.2.0-20060806 rev. 115974 on x86-64.
current 4.1.2 build in progress...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20586
--- Comment #8 from patchapp at dberlin dot org 2006-08-09 09:50 ---
Subject: Bug number PR28651
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00247.html
--
http://gcc.gnu.org/bugzilla/sh
When compiling the code below with '-O -Wuninitialized', I get spurious
warnings:
piekana:~$ cat gforttest.f90
program runoptf90
implicit none
real :: x(1)
call simulated_annealing (x)
contains
subroutine simulated_annealing (xmin)
real, intent(inout) :: xmin(:)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 10:20 ---
Actually this is worse than what is said here, this is wrong code. In a
prerelease of 4.1.0, we allocate r after we allocate x so the size of x is not
know at the time we allocate r.
--
pinskia at gcc dot gnu do
--- Comment #9 from pluto at agmk dot net 2006-08-09 10:36 ---
the only "C" bootstrap still shows failures for 4.1.2.
Bootstrap comparison failure!
./c-format.o differs
./combine.o differs
./expmed.o differs
./global.o differs
./i386.o differs
./reg-stack.o differs
./regclass.o differs
--- Comment #2 from snordin_ng at yahoo dot fr 2006-08-09 10:39 ---
Thanks for this astuteness. It's great and works well.
Since we use lcov to obtain a suitable output in html format
for class and method's coverage, I'll try to modify it using
c++filt.
I'll inform you about results.
-
--- Comment #2 from erik dot edelmann at iki dot fi 2006-08-09 10:54
---
(In reply to comment #1)
> Actually this is worse than what is said here, this is wrong code. In a
> prerelease of 4.1.0, we allocate r after we allocate x so the size of x is not
> know at the time we allocate r.
--- Comment #8 from jr at e-integration dot net 2006-08-09 13:52 ---
Created an attachment (id=12046)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12046&action=view)
gcc-4.1.1/gcc/gthr-solaris.h weak declaration
Fails with latest gcc-4.1.1/gcc/gthr-solaris.h file during bootstra
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
See http://gcc.gnu.org/ml/fortran/2006-08/msg00145.html
Currently gfortran calls cpp with the option -traditional-cpp. Using this
option, newer macros like
#define msg(x) print *, #x
don't work (the #x causes the argument to be quoted). (See url/email for
example.)
I couldn't find any standard
--- Comment #3 from patchapp at dberlin dot org 2006-08-09 14:20 ---
Subject: Bug number PR28630
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00265.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #4 from patchapp at dberlin dot org 2006-08-09 14:20 ---
Subject: Bug number PR28600
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00266.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #5 from jakub at gcc dot gnu dot org 2006-08-09 14:29 ---
It was caused by the openmp changes, but guess usually the parent routine
at least touches the dummy argument and therefore it would be added to the
right context.
I was testing:
--- trans-decl.c.jj 2006-08-09 15:3
--- Comment #52 from whaley at cs dot utsa dot edu 2006-08-09 14:33 ---
Paolo,
>In some sense, this is the peephole I would rather *not* do. But the answer
>is yes. :-)
Ahh, got it :)
>So, do you now agree that the bug would be fixed if the patch that is in GCC
>4.2 was backported
gcj -O2 -fomit-frame-pointer -fweb -frename-registers -fPIC -fjni -shared
-Wl,-O2,--as-needed,--enable-new-dtags,-soname,libecj.so.3 -o libecj.so.3
ecj.jar
org/eclipse/jdt/internal/compiler/lookup/Scope.java: In class
'org.eclipse.jdt.internal.compiler.lookup.Scope':
org/eclipse/jdt/internal/compil
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-08-09 14:38 ---
I can trivially fix this, but the code isn't going to do what you want when i'm
done, since it is an aliasing violation :)
The assert in question just happens to be good at catching them.
--
http://gcc.gnu.org/
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot
|dot org
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot
|dot org
--- Comment #2 from janis at gcc dot gnu dot org 2006-08-09 15:46 ---
A regression hunt on powerpc-linux identified this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=102182
r102182 | giovannibajo | 2005-07-20 01:19:59 + (Wed, 20 Jul 2005)
--
janis at gcc dot gnu dot o
--- Comment #53 from whaley at cs dot utsa dot edu 2006-08-09 15:52 ---
Created an attachment (id=12047)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12047&action=view)
benchmark wt vectorizable kernel
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-08-09 15:52
---
> Fails with latest gcc-4.1.1/gcc/gthr-solaris.h file during bootstrap.
As indicated in the "target milestone" field, this will be fixed in 4.1.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28247
--- Comment #54 from whaley at cs dot utsa dot edu 2006-08-09 16:08 ---
Dorit,
OK, I've posted a new tarfile with a safe kernel code where the loop is not
unrolled, so that the vectorizer has a chance. With this kernel, I can make it
vectorize code, but only if I throw the -funsafe-mat
+++ This bug was initially created as a clone of Bug #28247 +++
gcc 4.1.1 cannot buld on Solaris 9 sparc:
$ ./configure --prefix=/home/gcc --enable-threads=solaris
--enable-languages=c,c++ --enable-shared=libstdc++ --disable-multilib
--disable-nls sparc64-sun-solaris2.9
$ make
...
/home/devel/tm
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-09 16:44
---
*** Bug 28665 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 16:44 ---
What don't you understand that this was already fixed for the next release of
4.1.x aka 4.1.2?
*** This bug has been marked as a duplicate of 28247 ***
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from jr at e-integration dot net 2006-08-09 16:52 ---
Created an attachment (id=12048)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12048&action=view)
/gcc-4.1.1/gcc/gthr-solaris.h Solaris threads header file
bootstrap fails:
Here's my configure:
--- Comment #3 from pault at gcc dot gnu dot org 2006-08-09 17:47 ---
uuuhhh! This is horrible and is a reflection of the symtree being ordered as a
binary tree. If 'r' is renamed 'zr', the order of translation is changed and
the code runs correctly; albeit still with an unrequited ub
--- Comment #1 from janis at gcc dot gnu dot org 2006-08-09 17:48 ---
A regression hunt using an s390-linux cross compiler on powerpc-linux, with the
submitter's testcase and options, identified this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=88869
r88869 | pinskia | 2004-1
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-09 17:56 ---
My patch just exposed a latent bug as it does nothing that was not already done
before RTH removed the folding.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24367
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 18:03 ---
One problem without using -tranditional-cpp is that some tokens in C are not
tokens in Fortran so you could get the wrong result. This is why
-tranditional-cpp is used.
There is no standard for Preprocessed Fortran
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28600
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28663
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-08-09 18:10 ---
> One problem without using -tranditional-cpp is that some tokens in C are not
> tokens in Fortran so you could get the wrong result. This is why
> -tranditional-cpp is used.
I though the -lang-f
/* { dg-do compile } */
/* { dg-options "-O2 -fforce-addr" } */
extern int foo (void *, long, double *);
extern int bar (void *, double, long *);
extern double copysign (double, double);
extern double floor (double);
int
test (void *a, long *b, long *c)
{
double x, z;
if (!foo (a, b[0], &x))
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28132
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 18:16 ---
This is a dup of bug 28132.
*** This bug has been marked as a duplicate of 28132 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-09 18:16 ---
*** Bug 28667 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pault at gcc dot gnu dot org 2006-08-09 18:27 ---
(In reply to comment #5)
> It was caused by the openmp changes, but guess usually the parent routine
> at least touches the dummy argument and therefore it would be added to the
> right context.
> I was testing:
> ---
--- Comment #7 from jakub at gcc dot gnu dot org 2006-08-09 18:36 ---
Go with your version, you posted first ;).
I added the comment just to support your patch, that I independently came
to a (almost) same fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-09 18:43
---
Subject: Bug 28637
Author: lmillward
Date: Wed Aug 9 18:43:06 2006
New Revision: 116043
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116043
Log:
2006-08-09 Lee Millward <[EMAIL PROTECTED]>
PR
--- Comment #1 from lmillward at gcc dot gnu dot org 2006-08-09 18:43
---
Subject: Bug 28639
Author: lmillward
Date: Wed Aug 9 18:43:06 2006
New Revision: 116043
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116043
Log:
2006-08-09 Lee Millward <[EMAIL PROTECTED]>
PR
--- Comment #1 from lmillward at gcc dot gnu dot org 2006-08-09 18:43
---
Subject: Bug 28641
Author: lmillward
Date: Wed Aug 9 18:43:06 2006
New Revision: 116043
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116043
Log:
2006-08-09 Lee Millward <[EMAIL PROTECTED]>
PR
--- Comment #1 from lmillward at gcc dot gnu dot org 2006-08-09 18:43
---
Subject: Bug 28638
Author: lmillward
Date: Wed Aug 9 18:43:06 2006
New Revision: 116043
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116043
Log:
2006-08-09 Lee Millward <[EMAIL PROTECTED]>
PR
--- Comment #1 from lmillward at gcc dot gnu dot org 2006-08-09 18:43
---
Subject: Bug 28640
Author: lmillward
Date: Wed Aug 9 18:43:06 2006
New Revision: 116043
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116043
Log:
2006-08-09 Lee Millward <[EMAIL PROTECTED]>
PR
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-09 18:44
---
Fixed on mainline. Will be fixed on 4.1 branch when the patch for PR 27668 is
reverted.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-09 18:45
---
Fixed on mainline.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-09 18:45
---
Fixed on mainline.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-09 18:47
---
Partially fixed on mainline, the testcase now ICE's in the same place as PR
24791.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28639
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-09 18:47
---
Partially fixed on mainline, the testcase now ICE's in the same place as PR
24791.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28641
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 19:08 ---
6809 is not in the FSF GCC at all.
Contact the person who you got the compiler from.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
>
> Here's some questions I need to figure out:
> (1) Why do I have to throw the -funsafe-math-optimizations flag to
> enable this?
>-- I see where the .vect file warns of it, but it refers to an SSA
line,
> so I'm not sure what's going on.
This flag is needed in order to allow vectoriza
--- Comment #55 from dorit at il dot ibm dot com 2006-08-09 19:10 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse x87 code
on all platforms than gcc 3
>
> Here's some questions I need to figure out:
> (1) Why do I have to throw the -funsafe-math-optimizations flag to
> enab
Tied to version 3.4.5, unable to try with current build.
Here is the output, followed by part of the preprocessed source:
Output:
[EMAIL PROTECTED] flt]$ /usr/users/bonomo/gnu/cross/m6809/bin/gcc -v -save-temps
-Wall -B/usr/users/bonomo/gnu/cros
s/m6809/bin/ -S -c test.c^M
Reading specs from /us
--- Comment #2 from bonomo at sal dot wisc dot edu 2006-08-09 19:14 ---
Subject: Re: internal compiler error: in find_reloads, at
reload.c:3690
Ah! This is not really a gcc bug then. That's a bit of
a relief.
Rich
On Wed, 9 Aug 2006, pinskia at gcc dot gnu dot org wrote:
>
>
> --
>
>
>
> --- Comment #2 from bonomo at sal dot wisc dot edu 2006-08-09 19:14
> ---
> Subject: Re: internal compiler error: in find_reloads, at
> reload.c:3690
>
>
> Ah! This is not really a gcc bug then. That's a bit of
> a relief.
It is most likely a GCC bug but with the port to
--- Comment #3 from pinskia at physics dot uc dot edu 2006-08-09 19:16
---
Subject: Re: internal compiler error: in find_reloads, at reload.c:3690
>
>
>
> --- Comment #2 from bonomo at sal dot wisc dot edu 2006-08-09 19:14
> ---
> Subject: Re: internal compiler error: in
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-08-09 19:17
---
The file you've attached is incorrectly patched. Please get it from a snapshot
or the SVN repository.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28665
In cp/decl.c there is this code.
error ("%smember function %qD cannot have cv-qualifier",
(ctype ? "static " : "non-"), decl);
The first string, "%smember ..." is available for translation in the po-file,
but not the parts substituted, static and non-. And even if they were, i
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-08-09 20:03
---
poog% uname -a
SunOS poog 5.9 Generic_117171-12 sun4u sparc SUNW,Sun-Fire-V250
poog% gcc/xgcc -v
Using built-in specs.
Target: sparc64-sun-solaris2.9
Configured with: /home/eric/svn/gcc-4_1-branch/configure
sparc
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 21:08 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #56 from whaley at cs dot utsa dot edu 2006-08-09 21:33 ---
Dorit,
>This flag is needed in order to allow vectorization of reduction (summation
>in your case) of floating-point data.
OK, but this is a bd flag to require. From the computational scientist's
point of view
>
>
>
> --- Comment #56 from whaley at cs dot utsa dot edu 2006-08-09 21:33
> ---
> Dorit,
>
> >This flag is needed in order to allow vectorization of reduction (summation
> >in your case) of floating-point data.
>
> OK, but this is a bd flag to require. From the computational s
--- Comment #57 from pinskia at physics dot uc dot edu 2006-08-09 21:46
---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse x87 code on all
platforms than gcc 3
>
>
>
> --- Comment #56 from whaley at cs dot utsa dot edu 2006-08-09 21:33
> ---
> Dorit,
>
> >This fl
--- Comment #15 from eedelman at gcc dot gnu dot org 2006-08-09 21:55
---
Created an attachment (id=12049)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12049&action=view)
Updated patch
Fix the problem reported by Jack.
--
eedelman at gcc dot gnu dot org changed:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28600
struct X { X( int ); };
struct Y { Y( X const& ); };
void test()
{
Y y1( 1 ); // conversion works fine.
Y y2 = 2; // error: conversion from ‘int’ to non-scalar
// type ‘Y’ requested.
}
msvc accepts both variants, g++ only one.
is it a bug in g++ or in msvc?
--
This happens when trying to compile strigi 0.3.2
(http://www.vandenoever.info/software/strigi/) with gcc trunk from today
results in
Linking CXX executable dummyindexer
CMakeFiles/dummyindexer.dir/dummyindexer.o: In function `__exchange_and_add':
/usr/lib/gcc/i586-pc-linux-gnu/4.2.0/../../../../in
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 22:51 ---
What options are being used to compile the software with?
if -march=i386, then this is not a bug with the compiler.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #2 from bero at arklinux dot org 2006-08-09 22:54 ---
-O2 -march=i586 -mcpu=i686 -fomit-frame-pointer
--
bero at arklinux dot org changed:
What|Removed |Added
--- Comment #58 from whaley at cs dot utsa dot edu 2006-08-09 23:01 ---
Andrew,
>Except for the fact IEEE compliant fp does not allow for reordering at all
>except
>in some small cases. For an example is (a + b) + (-a) is not the same as (a +
>(-a)) + b,
>so reordering will invalid IEE
--- Comment #3 from pcarlini at suse dot de 2006-08-09 23:08 ---
First, a general remark: this kind of error must never happen, irrespective of
the options used to build user code and/or GCC.
Then, it looks like _GLIBCXX_ATOMIC_BUILTINS is defined for that installation
of GCC. In turn,
--- Comment #4 from pcarlini at suse dot de 2006-08-09 23:30 ---
One additional remark: if the entire software package is really built with
-march=i586, then, in any case, the __sync_fetch_and_add call at line 47 of
atomicity.h is expanded in line and the link problem cannot occur as rep
--- Comment #5 from pcarlini at suse dot de 2006-08-09 23:48 ---
Benjamin, in case this problem is confirmed (and some strange details of the PR
are sorted out), can you please double check that we are not incurring in the
issue I was fearing here:
http://gcc.gnu.org/ml/libstdc++/2006
--- Comment #6 from bero at arklinux dot org 2006-08-09 23:55 ---
Ok, misunderstanding about the compiler flags -- -march=i586 was used to build
the compiler, strigi was built without any -march= tags (making the default
i386, I guess).
Using -march=i586 in strigi makes the problem go a
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-09 23:58 ---
Can you give your exact commands use to build GCC?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from pcarlini at suse dot de 2006-08-10 00:05 ---
(In reply to comment #6)
> Ok, misunderstanding about the compiler flags -- -march=i586 was used to build
> the compiler, strigi was built without any -march= tags (making the default
> i386, I guess).
>
> Using -march=i58
With revision 116045, gcc mainline went into infinite loop when compiling
libstdc++-v3/src/wlocale-inst.cc.
--
Summary: [4.2 Regression]: Gcc went into infinite loop when
building libstdc++
Product: gcc
Version: 4.2.0
Status: UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-10 02:08 ---
Testcase?
Do you ever follow directions?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from pault at gcc dot gnu dot org 2006-08-10 04:29 ---
(In reply to comment #3)
> order the declarations or something.
>
> Paul
>
Having slept on it, I realise that this will not work because the statement
order should not matter. I think that there will have to be
--- Comment #5 from patchapp at dberlin dot org 2006-08-10 04:35 ---
Subject: Bug number PR25828
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00300.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from pault at gcc dot gnu dot org 2006-08-10 04:56 ---
I can see what the problem is - when I wrote this section of code in expr.c, I
did the conditions for "step" and "finish" correctly but for "begin", I wrote:
/* Obtain the start value for the index. */
if
--- Comment #2 from hjl at lucon dot org 2006-08-10 06:16 ---
Created an attachment (id=12050)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12050&action=view)
A tescase
This is the best I can get so far. Gcc hangs with -O2 -g.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #3 from hjl at lucon dot org 2006-08-10 06:22 ---
This patch
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00238.html
causes the gcc to hang. Gdb backtrace looks like
(gdb) bt
#0 htab_find_slot_with_hash (htab=0x602cce30,
element=0x25417b20, hash=30308,
--- Comment #7 from bonzini at gnu dot org 2006-08-10 06:28 ---
Was this implemented? There is an expand_builtin_sincos, but I think it cannot
remove TREE_ADDRESSABLE on the arguments, making most of the performance
advantages go away...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #59 from paolo dot bonzini at lu dot unisi dot ch 2006-08-10
06:52 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse
x87 code on all platforms than gcc 3
> Thanks for the response, but I believe you are conflating two issues (as is
> this flag, which is why this
88 matches
Mail list logo
