This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug optimization/12199] [3.3-hammer regression] long double miscompilation in gsl/amd64
- From: "gbeauchesne at mandrakesoft dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 7 Sep 2003 07:52:27 -0000
- Subject: [Bug optimization/12199] [3.3-hammer regression] long double miscompilation in gsl/amd64
- References: <20030906231705.12199.gbeauchesne@mandrakesoft.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
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.