This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug optimization/12199] [3.3-hammer regression] long double miscompilation in gsl/amd64


PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12199



------- Additional Comments From gbeauchesne at mandrakesoft dot com  2003-09-07 07:52 -------
Subject: Re:  [3.3-hammer regression] long double miscompilation in gsl/amd64

Hi,

> I think the reason why with -O2, it is exhausted, is because check and 
> (I think fabs, might have
> already) gets inlined because unit-at-a-time is enabled on the 
> 3.3-hammer branch (and the
> mainline also) at -O2 and above.

Actually it is also exhausted with a 3.3-hammer branch snapshot as far 
as 2003/05/27, i.e. without -funit-at-a-time support by default at -O2. 
I strongly believe fabs() & check() are not the culprit since in the 
original GSL test, they were part of other files I haven't rebuilt when 
reducing the testcase.

> It would be nice to know if this bug is also on the mainline.

It doesn't occur on mainline of yesterday.

> Also what happens if you add __attribute__((__no_inline__)) to the 
> function check, does it still
> create wrong code?

It does.

Bye,
Gwenole.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]