From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6002 invoked by alias); 7 Sep 2003 07:52:27 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 5990 invoked by alias); 7 Sep 2003 07:52:27 -0000 Date: Sun, 07 Sep 2003 07:52:00 -0000 Message-ID: <20030907075227.5989.qmail@sources.redhat.com> From: "gbeauchesne at mandrakesoft dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20030906231705.12199.gbeauchesne@mandrakesoft.com> References: <20030906231705.12199.gbeauchesne@mandrakesoft.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug optimization/12199] [3.3-hammer regression] long double miscompilation in gsl/amd64 X-Bugzilla-Reason: CC X-SW-Source: 2003-09/txt/msg00573.txt.bz2 List-Id: 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.