237594 - Need configure.in test to check whether gcc breaks with certain optimizer switches

Status: RESOLVED WONTFIX

(SeaMonkey :: Build Config, defect)

Description

[Roland Mainz]

[Follow-up of bug 233497]
We need configure.in test to check whether the gcc compiler generates wrong code
when certain optimisation switches like -Os are set.

From bug 233497:
-- snip --
-- Additional Comment #39 From Andrew Schultz 2004-03-11 12:36 PST [reply]  

[e-mail] pointed to http://gcc.gnu.org/PR12308 and said the next Fedora
gcc RPMs would have the fix.

Based on my limited understanding of the bug @gcc.org, the optimization flags
that are triggering the bug here probably just set up the proper environment for
the bug to occur.  For instance, the testcase @gcc.org has the bug with -O2. 
-fno-gcse might or might not resolve all symptoms of the bug.

It might be worthwhile build a custom gcc so that at least mozilla.org's
binaries work ok.

I'll test out the dbaron's Mozilla patch and the gcc patch tonight.

Also, gcc-3.2.3-24 is not affected by this bug (at least not my testcase), so
any configure.in test could be confined to gcc > 3.2


-- Additional Comment #40 From David Baron 2004-03-11 12:46 PST [reply]  

If there's a relevant compiler bug that we can detect with a configure.in test,
we should do it (the test should fail and tell people what options to use
instead).  (We already have a test for a long long bug with gcc 2.7.x that shows
up with --enable-pedantic.)

Also, -O2 apparently does -fgcse as well.
-- snip --

Testcase program can be found under
http://bugzilla.redhat.com/bugzilla/attachment.cgi?id=98452&action=edit

Comment 1

[Roland Mainz]

Requesting "blocking 1.7b" status, IMHO we should stop distributors from
shooting themselvs into the feet... malfunction builds usually result in bad
press and worse...

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm not the person to do this, since I'm not set up to simplify the testcase
that shows the problem.

Comment 3

[Roland Mainz]

ajschult:
can you make a simplified testcase for configure.in, please ?

Comment 4

[Andrew Schultz]

Attachment: patch

testcase taken from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12308#c0
the testcase I attached to Red Hat's bugzilla did not trigger the bug on gcc
3.4 while the one at gnu.org did trigger it with gcc 3.4.

with the patch, configure bails if the bug occur and instrusts the user to
recompile with -fno-gcse.

Comment 5

[Andreas Lange]

+yes)
+    AC_MSG_ERROR([Your compiler appears to have a known bug where when using
-Os.  Reconfigure using --fno-gcse. ])
+    ;;

Perhaps the warning should be differently worded? ("...where when...")

Comment 6

[Andrew Schultz]

Attachment: patch better grammer with

thanks Andreas

Comment 7

[Roland Mainz]

Andrew Schultz:
Is the test specific for gcc or for all compilers ? I suggest to make the test
mandatory for all compilers on Unix/Linux... maybe some day we're thankfull that
the test found a problem before someone had to sacrify a weekend with
debugging...

Comment 8

[Andrew Schultz]

> Is the test specific for gcc or for all compilers ? I suggest to make the test

The check is performed for all compilers on all platforms...

> mandatory for all compilers on Unix/Linux... maybe some day we're thankfull that
> the test found a problem before someone had to sacrify a weekend with
> debugging...

well, chances would be exceedingly low that the same exact bug would show up on
another compiler using that exact testcase -- and if it did, -fno-gcse would be
no help.  And we can't exactly include a C/C++ test suite in configure.in.

Comment 9

[Brendan Eich [:brendan]]

I think this is the wrong approach.  Sorry, there are many cases where people
have had to find workaround in the code for compiler bugs.  Just turning off
gcse or other optimizations should be avoided, especially for all Unix
compilers, as if they all had the same bugs, or were equally buggy.

Roland, you can spend your weekends however you like, but we'll thank you if you
help isolate the code that's being miscompiled and develop a better workaround.
 If you don't have the time, that's ok -- but someone else may, and deoptimizing
whole files is not the right first, or second, or even third answer.

/be

Comment 10

[Serge Gautherie (:sgautherie)]

Andrew,
Are you still working on this ?

Comment 11

[Andrew Schultz]

No, this seems to be WONTFIX.  The buggy compilers are probably unused at this point anyway.