653777 - "non-relocatable subtraction expression" trying to compile js/src/jsapi.cpp on mac os x 10.5

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Hanspeter Niederstrasser]

10.5.8 with i686-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5577)

g++-4.2 -arch i386 -o jsapi.o -c  -fvisibility=hidden -DOSTYPE=\"Darwin9.8.0\" -DOSARCH=Darwin -DEXPORT_JS_API -D__STDC_LIMIT_MACROS -DJS_HAS_CTYPES -DDLL_PREFIX=\"lib\" -DDLL_SUFFIX=\".dylib\" -Ictypes/libffi/include -I.  -I/src/mozilla-central/js/src -I. -I./../../dist/include -I./../../dist/include/nsprpub  -I/src/mozilla-central/obj-i386-apple-darwin9.8.0-mac/dist/include/nspr   -I/src/mozilla-central/js/src -I/src/mozilla-central/js/src/assembler -I/src/mozilla-central/js/src/yarr  -fPIC  -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -fno-strict-aliasing -fpascal-strings -fno-common -pthread  -DNDEBUG -DTRIMMED -g -O3 -fstrict-aliasing -fno-stack-protector -fomit-frame-pointer -DUSE_SYSTEM_MALLOC=1 -DENABLE_ASSEMBLER=1 -DENABLE_JIT=1   -DMOZILLA_CLIENT -include ./js-confdefs.h -MD -MF .deps/jsapi.pp /src/mozilla-central/js/src/jsapi.cpp
/var/folders/VJ/VJI1GqIRGmOqqRYrL1IClU+++TI/-Tmp-//ccgNAqYP.s:6798:non-relocatable subtraction expression, "LC3" minus "L00000000018$pb"
/var/folders/VJ/VJI1GqIRGmOqqRYrL1IClU+++TI/-Tmp-//ccgNAqYP.s:6798:symbol: "L00000000018$pb" can't be undefined in a subtraction expression
/var/folders/VJ/VJI1GqIRGmOqqRYrL1IClU+++TI/-Tmp-//ccgNAqYP.s:unknown:Undefined local symbol L00000000018$pb
make[1]: *** [jsapi.o] Error 1
make: *** [default] Error 2

Same type of error as in bug 624080 but in a different file.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Yep, sounds like more "apple's GCC optimizer in 32-bit mode breaks with non-finite doubles".  :(

Comment 2

[Boris Zbarsky [:bzbarsky]]

What's odd is that we're not hitting this with the 32-bit build on trunk (building on 10.6).

Comment 3

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

Reminds me of bug 435442 comment 58 - 60.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Apparently bug 640494 is what introduced the relevant code?

Comment 6

[Boris Zbarsky [:bzbarsky]]

And yes, the code in bug 640494 is similar in spirit to the NS_IEEEPositiveInfinity() code that apple's GCC miscompiled in bug 435442.  I still wonder why we're not hitting this on 10.6, though....

Comment 7

[Mike Hommey [:glandium]]

This /could/ be a -O3 problem.

Comment 8

[Mike Hommey [:glandium]]

(In reply to comment #7)
> This /could/ be a -O3 problem.

Which it's apparently not.

Comment 9

[Mike Hommey [:glandium]]

Ok, this is crazy. The error happens in this assembly:

.globl _JS_NewNumberValue
_JS_NewNumberValue:
        pushl   %ebx
        subl    $16, %esp
        movsd   28(%esp), %xmm1
        movl    36(%esp), %ebx
        ucomisd %xmm1, %xmm1
        jp      L1300
        je      L1290
        leal    LC8-"L00000000024$pb"(%ebx), %eax
        (...)

L00000000024$pb is effectively not defined.

What is crazy is that JS_NewNumberValue doesn't use anything that bug 640494 changes, even indirectly.

What is interesting, though, is that it uses JS_CANONICALIZE_NAN, just like bug 624080.

Is there any reason we couldn't replace d != d in JS_CANONICALIZE_NAN with JSDOUBLE_IS_NaN (except for the fact that including jsnum.h in jsval.h is a nightmare) ?

Comment 10

[Hanspeter Niederstrasser]

For what it's worth, the build works if I put --disable-optimize in .mozconfig, which led me to the following...

(In reply to comment #8)
> (In reply to comment #7)
> > This /could/ be a -O3 problem.
> 
> Which it's apparently not.

You sure?  I removed -O3 in js/src/Makefile.in:90:MODULE_OPTIMIZE_FLAGS and the build progressed through without this error.  -O2 also caused the failure, but -O1 didn't.  So high end optimization does seem to bring out the worst in Apple's gcc.

Comment 11

[Jim Blandy :jimb]

(In reply to comment #9)
> Is there any reason we couldn't replace d != d in JS_CANONICALIZE_NAN with
> JSDOUBLE_IS_NaN (except for the fact that including jsnum.h in jsval.h is a
> nightmare) ?

We could move JSDOUBLE_IS_NaN to jsval.h if that would help work around this problem. We'd need a comment explaining why the more straightforward code won't do, so that someone coming across it later when Apple's compilers are fixed will understand that they can re-simplify. Certainly jsnum.h needs to remain private.

Comment 12

[Mike Hommey [:glandium]]

Attachment: Use JSDOUBLE_IS_NaN in JS_CANONICALIZE_NAN to work around build failure on OSX 10.5

Note that we probably could backout bug 624080 once this lands.

Comment 13

[Mike Hommey [:glandium]]

Attachment: Use JSDOUBLE_IS_NaN in JS_CANONICALIZE_NAN to work around build failure on OSX 10.5

Previous one was failing to build on windows

Comment 14

[Mike Hommey [:glandium]]

Roc, since you were hitting this bug, can you check that the patch fixes it for you, and that reverting bug 624080 afterwards works too?

Comment 15

[Hanspeter Niederstrasser]

(In reply to comment #13)
> Created attachment 544226 [details] [diff] [review] [review]
> Use JSDOUBLE_IS_NaN in JS_CANONICALIZE_NAN to work around build failure on
> OSX 10.5
> 
> Previous one was failing to build on windows

Does not work for me on 10.5.8

*****
g++-4.2 -o jsapi.o -c  -fvisibility=hidden -DOSTYPE=\"Darwin9.8.0\" -DOSARCH=Darwin -DEXPORT_JS_API -DIMPL_MFBT -D__STDC_LIMIT_MACROS -DJS_HAS_CTYPES -DDLL_PREFIX=\"lib\" -DDLL_SUFFIX=\".dylib\" -Ictypes/libffi/include -I.  -I/src/mozilla-central/js/src -I. -I./../../dist/include -I./../../dist/include/nsprpub  -I/src/mozilla-central/obj-i386-apple-darwin9.8.0-mac/dist/include/nspr   -I/src/mozilla-central/js/src -I/src/mozilla-central/js/src/assembler -I/src/mozilla-central/js/src/yarr  -fPIC  -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -fno-strict-aliasing -fno-common -pthread -pipe  -DNDEBUG -DTRIMMED -g -O3 -fstrict-aliasing -fno-stack-protector -fomit-frame-pointer -DUSE_SYSTEM_MALLOC=1 -DENABLE_ASSEMBLER=1 -DENABLE_JIT=1   -DMOZILLA_CLIENT -include ./js-confdefs.h -MD -MF .deps/jsapi.pp /src/mozilla-central/js/src/jsapi.cpp
{standard input}:6948:non-relocatable subtraction expression, "LC3" minus "L00000000022$pb"
{standard input}:6948:symbol: "L00000000022$pb" can't be undefined in a subtraction expression
{standard input}:6837:non-relocatable subtraction expression, "LC3" minus "L00000000022$pb"
{standard input}:6837:symbol: "L00000000022$pb" can't be undefined in a subtraction expression
{standard input}:unknown:Undefined local symbol L00000000022$pb
*******

My .mozconfig
****
. $topsrcdir/browser/config/mozconfig

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-${TARGET_CPU}-apple-darwin${DARWIN_VERSION}-mac
mk_add_options AUTOCONF=/sw/lib/autoconf2.13/bin/autoconf

ac_add_options --prefix=/tmp/prefix
ac_add_options --enable-official-branding
****

Comment 16

[Mike Hommey [:glandium]]

Could you make -C $objdir/js/src jsapi.s and attach the file here? (it looks like from the error that it's not exactly the same)

Comment 17

[Mike Hommey [:glandium]]

(In reply to comment #16)
> Could you make -C $objdir/js/src jsapi.s and attach the file here?

(the resulting $objdir/js/src/jsapi.s file, that is)

Comment 18

[Hanspeter Niederstrasser]

Attachment: jsapi.s after patching with attachment 544226

"make -C obj-i386-apple-darwin9.8.0-mac/js/src jsapi.s" output.

Had to gzip it because it was too big otherwise (6MB).

Comment 19

[Mike Hommey [:glandium]]

So, it still happens in the same function, though the code is significantly different :(

Comment 20

[Mike Hommey [:glandium]]

Attachment: Use JSDOUBLE_IS_NaN in JS_CANONICALIZE_NAN to work around build failure on OSX 10.5

Could you try this one, that changes the JSDOUBLE_IS_NaN implementation? (and apparently happens to fix bug 653056)

Comment 21

[Hanspeter Niederstrasser]

Something changed in the tree in the past 2 days.  I pulled an update to the tree, removed my $OBJDIR and rebuilt w/out any of the patches, and the build continued past jsapi.cpp (and crashed in content/canvas/src/CanvasUtils.cpp with the same type of non-relocatable error which I'll deal with later).

My 2 day window is based on failing as described here after doing 'hg update -d "2011-07-10" ', and mostly succeeding with 'hg update -d "2011-07-11" '.  Is there a way to narrow the time period?

Comment 22

[Mike Hommey [:glandium]]

(In reply to comment #21)
> Something changed in the tree in the past 2 days.  I pulled an update to the
> tree, removed my $OBJDIR and rebuilt w/out any of the patches, and the build
> continued past jsapi.cpp (and crashed in content/canvas/src/CanvasUtils.cpp
> with the same type of non-relocatable error which I'll deal with later).
> 
> My 2 day window is based on failing as described here after doing 'hg update
> -d "2011-07-10" ', and mostly succeeding with 'hg update -d "2011-07-11" '. 
> Is there a way to narrow the time period?

Try this:
hg bisect --help

Comment 23

[Hanspeter Niederstrasser]

The first good revision is:
changeset:   72585:64d00c88b3a6
user:        Mike Hommey <[e-mail]>
date:        Mon Jul 11 07:57:35 2011 +0200
summary:     Bug 654664 - Optimize JSDOUBLE_IS_NEGZERO after bug 640494. r=jimb

And manually backing out the patch from that bug gives me the jsapi.o error.

Comment 24

[Mike Hommey [:glandium]]

Interesting. Could you also try reverting the patch from bug 624080 and see if js/src still builds ?

Comment 25

[Hanspeter Niederstrasser]

On an otherwise updated clean tree, if I revert the patch from bug 624080 (attachment 502700 [details] [diff] [review]), the build fails on js/src/jsclone.o in the same way as decsribed in bug 624080.

Comment 26

[Mike Hommey [:glandium]]

What is weird, though, is that a change to JSDOUBLE_IS_NEGZERO, which is not involved in JS_NewNumberValue (which is the function that was broken in this bug), somehow prevented gcc to generate broken assembly...

Anyways, maybe we can mark this bug as WORKSFORME, and you should probably file a new bug for the content/canvas/src/CanvasUtils.cpp problem.

Comment 27

[Hanspeter Niederstrasser]

Marking WFM since indirectly fixed (apparently by bug 654664).

The content/canvas/src/CanvasUtils.cpp problem is bug 671423