198692 - fast-math leads to bad preferences (gcc says do not use fast-math)

Status: VERIFIED INVALID

(Core :: JavaScript Engine, defect)

Description

[Sam Halliday]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.3) Gecko/20030321
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.3) Gecko/20030321

This is a big which is being opened as 'resolved', but maybe the docs deserve a
little mention. If mozilla is built with the CFLAGS containing '-ffast-math', it
will silently fail the compile. What will happen is that users will be unable to
save any preferences, but other browsing experiences will be unaffected.

Reproducible: Always

Steps to Reproduce:
1. Compile with '-ffast-math'
2. Use Mozilla
3. See you can't save any preferences




Moral of story... don't use exotic optimisations!

Comment 1

[hacker formerly known as [e-mail]]

If it fails the compile, you will not be able to run the mozilla binary.  Can
you provide any more details like *why* -ffast-math breaks?  Are you only
setting CFLAGS or is CXXFLAGS set as well?  If the former, then there's only a
handful of code that is probably affected like this (js is my guess).

Comment 2

[Sam Halliday]

thats why i said it 'silently' fails the compile. the binary runs fine in all
regards besides saving preferences.

sorry, should have said...
CXXFLAGS="$CFLAGS"

i dont have a clue *why* it breaks the compile. fast-math is a fairly exotic
optimisation, and although in theory it shouldn't break clean code... it does.
it may be a gcc bug rather than a mozilla one.

i would agree with you, i believe this has roots in the js code. the javascript
console gave lots of errors when even browsing the preferences (which it couldnt
even read... defaults were non-existant). see bug 197753 for my intial discovery
of this problem.

gcc seems to struggle with compiling js with any high optimisation level. it
also dies on file js/src/jsdtoa.c if trying to use the SSE2 instruction set (on
a side note... this should break the compile for itanium and x64)

gcc -s -o jsdtoa.o -c -DOSTYPE=\"Linux2.4\" -DOSARCH=\"Linux\" -DOJI
-DEXPORT_JS_API  -DJS_USE_SAFE_ARENA   -I../../dist/include/js
-I../../dist/include -I/home/LFS/lfs/mozilla/mozilla/dist/include/nspr      -I.
-I/usr/X11R6/include   -fPIC -I/usr/X11R6/include -Wall -W -Wno-unused
-Wpointer-arith -Wcast-align -pedantic -Wno-long-long -O3 -march=pentium4 -mmmx
-mfpmath=sse -msse -msse2 -fomit-frame-pointer -pthread -pipe  -DNDEBUG
-DTRIMMED -ffunction-sections -O3 -march=pentium4 -mmmx -mfpmath=sse -msse
-msse2 -fomit-frame-pointer  -I/usr/X11R6/include -include
../../mozilla-config.h -DMOZILLA_CLIENT -Wp,-MD,.deps/jsdtoa.pp jsdtoa.c
jsdtoa.c: In function `JS_strtod':
jsdtoa.c:1239: warning: `rv0' might be used uninitialized in this function
jsdtoa.c:1874: unable to find a register to spill in class `AREG'
jsdtoa.c:1874: this is the insn:
(insn:QI 2402 2401 2403 (set (reg:CCNO 17 flags)
        (compare:CCNO (and:SI (subreg:SI (reg/v:DI 21 rxmm0 [369]) 0)
                (const_int 1 [0x1]))
            (const_int 0 [0x0]))) 281 {testsi_1} (insn_list 2398 (nil))
    (expr_list:REG_DEAD (reg/v:DI 21 rxmm0 [369])
        (nil)))
jsdtoa.c:1874: confused by earlier errors, bailing out
make[3]: *** [jsdtoa.o] Error 1
make[3]: Leaving directory `js/src'

sorry i cant help you with *how* exactly fast-math breaks the compile, i
actually started this bug so that people experiencing the same thing could see
the error and fix it, not as a 'fix me quick' bug.

Comment 3

[hacker formerly known as [e-mail]]

Sorry, I get perplexed by bug reports that start with 'it failed to compile and
did <X> when I ran it'.  The build completed and you're seeing a runtime
failure.   I'm passing this over to the js team but I see this note in the gcc
man page which makes me think the problem is not fixable and it's another one fo
those "don't do that" issues.

       -ffast-math
              This option allows GCC to violate some ANSI or IEEE
              rules/specifications  in the interest of optimizing
              code for speed.  For example, it allows the compil&#65533;
              er  to  assume  arguments  to the sqrt function are
              non-negative numbers.

              This option should never be turned on by  any  `-O'
              option  since it can result in incorrect output for
              programs which depend on an exact implementation of
              IEEE  or  ANSI  rules/specifications for math func&#65533;
              tions.

Comment 4

[Sam Halliday]

no need to be perplexed... i did not say it failed to compile; i said it failed
*silently*. meaning it DID compile, but wrongly. i call that a silent fail...
you may call that a runtime failure. i say pot-ato, you say pot-at-o... i
thought the context was obvious, sorry if i confused you.

> it's another one of those "don't do that" issues.
yes, it is. that is why i started the bug as severity 'minor' (easy workaround).
it would of course be nice if mozzy could be compiled with fast-math, as it is
the only app on my system to suffer this problem (besides glibc, which would be
silly to compile with fast-math for internal reasons), but, it really is no big
deal.

i would much prefer to see mozilla compiling with -sse2 enabled, as i believe
failing sse2 builds will result in broken 64 bit code. itanium uses sse2
exclusively for double precision ops, trashing the 387 chip. but this is a gcc
bug. should i report it to them? or should i let one of you guys do that? since
you know the code and i dont...

thanks for the responses... i really did just report this bug so that people
getting the same thing could avoid using heavy opts; i already know of 3 other
people who have experienced this.

Comment 5

[Phil Schwartau]

Reassigning; cc'ing Roger and Waldemar -

Comment 6

[tenthumbs]

The -mfpmath=sse thing isn't relevant. A "normal" -O2 --ffast-math build behaves
oddly.

One very important thing is that -ffast-math also defines the __FAST_MATH__
preprocessor symbol which may alter how the system include files behave. On
Linux look at /usr/include/bits/mathinline.h.

Comment 7

[Sam Halliday]

yes, sorry about that; the sse stuff was just a side note.

the bottom line is... fast-math should not be used unless you know the code can
handle it; this bug report exists just to warn people not to use it.

Comment 8

[Waldemar Horwat]

"Doctor, it hurts when I do that."
"Don't do that!"

The description of -ffast-math is vague -- it basically says that your code will
not compile correctly, and has been described as such on various newsgroups.
The numeric code in Mozilla and JS is quite optimized and relies on having
correct error bounds and such to function correctly.

Btw, also avoid -funsafe-math-optimizations, which is turned on by -ffast-math
in some versions of GCC and does roughly the same thing.  -ffast-math also turns
on two other options, -fno-trapping-math and -fno-math-errno.  I am not aware of
any uses of traps, so -fno-trapping-math ought to be ok.  -fno-math-errno is
probably ok too.

Comment 9

[Brendan Eich [:brendan]]

So is this bug INVALID?  I think so.

/be

Comment 10

[Phil Schwartau]

Marking Verified.

Sam: thank you for this report -

Comment 11

[timeless]

*** Bug 165367 has been marked as a duplicate of this bug. ***