74092 - build with Forte6Update2EA2's -xipo option fails

Status: RESOLVED INCOMPLETE

(SeaMonkey :: Build Config, defect, P3)

Description

[Roland Mainz]

Mozilla milestone 0.8.1 build with Sun Workshop 6(=Sun Forte) and the
interprocedural optimization (-xipo) turned on.

What is "-xipo" ?
-- snip --
This new compiler flag performs whole-program optimizations by invoking an
interprocedural analysis pass. Unlike -xcrossfile, -xipo performs optimizations
across all object files in the link step and is not limited to the source files
on the compile command.
-xipo is particularly useful when compiling and linking large multi-file
applications. Object files compiled with this flag have analysis information
compiled within them that enables interprocedural analysis across source and
pre-compiled program files. However, analysis and optimization are limited to
the object files compiled with -xipo and do not extend to object files in
libraries.
-- snip --

In theory a Mozilla5 compiled with -xipo turned-on should be _much_ faster...
...but in reality it ends-up in the following _pain_:
-- snip --
% export CC=/opt/SUNWspro/bin/cc CXX=/opt/SUNWspro/bin/CC CFLAGS="-I/usr/include
-I/usr/local/include" CXXFLAGS="-I/usr/include -I/usr/local/include"
% ../../../../tmp/moz_0_8_1/mozilla/configure --with-xprint --enable-mathml
--enable-svg --enable-xsl --enable-extensions --enable-nspr-autoconf
--enable-optimize="-fast -xarch=v7 -xipo" --disable-tests --disable-debug 2>&1 |
tee -a buildlog_ws6_gtk.log
% time nice -n 15 make 2>&1 | tee -a buildlog_ws6_gtk.log
# [snip]
/opt/SUNWspro/bin/cc -o prmjtime.o -c -DOSTYPE=\"SunOS5\" -DOJI -DEXPORT_JS_API 
-DJS_USE_SAFE_ARENA   -I../../dist/include -I../../dist/include     
-I../../../../../../tmp/moz_0_8_1/mozilla/js/src -I/usr/openwin/include   -KPIC
-I/usr/openwin/include -I/usr/include -I/usr/local/include -mt -fast -xarch=v7
-xipo  -DNDEBUG -DTRIMMED -I/usr/openwin/include -DBROKEN_QSORT=1
-DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d_ino -DMOZ_WIDGET_GTK=1
-DMOZ_ENABLE_XREMOTE=1 -DMOZ_DEFAULT_TOOLKIT=\"gtk\" -DSTDC_HEADERS=1
-DHAVE_ST_BLKSIZE=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1
-DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1 -DHAVE_DIRENT_H=1
-DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1
-DHAVE_SYS_FILIO_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1
-DHAVE_SYS_VFS_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1
-DHAVE_LIBSOCKET=1 -DHAVE_LIBPOSIX4=1 -D_REENTRANT=1 -DHAVE_RANDOM=1
-DHAVE_QSORT=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1
-DHAVE_SNPRINTF=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1
-DHAVE_USLEEP=1 -DHAVE_RINT=1 -DHAVE_GETTIMEOFDAY=1 -DGETTIMEOFDAY_TWO_ARGS=1
-DHAVE_DEV_ZERO=1 -DHAVE_IOS_BINARY=1 -DHAVE_OSTREAM=1 -DHAVE_CPP_EXPLICIT=1
-DHAVE_CPP_SPECIALIZATION=1 -DHAVE_CPP_MODERN_SPECIALIZE_TEMPLATE_SYNTAX=1
-DHAVE_CPP_PARTIAL_SPECIALIZATION=1 -DHAVE_CPP_ACCESS_CHANGING_USING=1
-DHAVE_CPP_AMBIGUITY_RESOLVING_USING=1 -DHAVE_CPP_NAMESPACE_STD=1
-DHAVE_CPP_UNAMBIGUOUS_STD_NOTEQUAL=1 -DHAVE_CPP_NEW_CASTS=1
-DHAVE_CPP_DYNAMIC_CAST_TO_VOID_PTR=1 -DNEED_CPP_UNUSED_IMPLEMENTATIONS=1
-DHAVE_I18N_LC_MESSAGES=1 -DMOZ_MAIL_NEWS=1 -DMOZ_ENDER_LITE=1
-DNS_MT_SUPPORTED=1 -DCPP_CV_QUALIFIERS_CAUSE_AMBIGUITY=1
-DMOZ_USER_DIR=\".mozilla\" -DMOZ_XUL=1 -DINCLUDE_XUL=1 -DMOZ_MATHML=1
-DMOZ_SVG=1 -DMOZ_XSL=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1
-DHAVE_MOVEMAIL=1 -DJS_THREADSAFE=1  -DMOZILLA_CLIENT
../../../../../../tmp/moz_0_8_1/mozilla/js/src/prmjtime.c
rm -f libmozjs.so
/opt/SUNWspro/bin/CC -library=iostream -I/usr/openwin/include -I/usr/include
-I/usr/local/include -mt -fast -xarch=v7 -xipo  -DNDEBUG -DTRIMMED -G -Qoption
ld -z,muldefs -h libmozjs.so -o libmozjs.so    jsapi.o jsarena.o jsarray.o
jsatom.o jsbool.o jscntxt.o jsdate.o jsdbgapi.o jsdhash.o jsdtoa.o jsemit.o
jsexn.o jsfun.o jsgc.o jshash.o jsinterp.o jslock.o jslog2.o jslong.o jsmath.o
jsnum.o jsobj.o jsopcode.o jsparse.o jsprf.o jsregexp.o jsscan.o jsscope.o
jsscript.o jsstr.o jsutil.o jsxdrapi.o prmjtime.o      -xildoff  -lm -lposix4
-ldl -lnsl -lsocket -L../../dist/bin -lplds4 -lplc4 -lnspr4 -lpthread -lposix4
-lsocket -liostream -lCrun -ldl -lm    
ld: fatal: library -lplds4: not found
ld: fatal: library -lplc4: not found
ld: fatal: library -lnspr4: not found
ld: fatal: File processing errors. No output written to libmozjs.so
make[2]: *** [libmozjs.so] Error 1
make[2]: Leaving directory
`/shared/bigtmp/moz_0_8_1_build/objdir_ws6_gtk/js/src'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/shared/bigtmp/moz_0_8_1_build/objdir_ws6_gtk/js'
make: *** [install] Error 2

real    154m35.753s
user    61m4.780s
sys     3m21.760s
-- snip --

Nice... ;-(

I'll attach build logs in a few fects.
richb... can you forward this to the compiler team that they can take a look if
this is either a configuration problem(=stupidity on my side) or a compiler
problem..., please ?

Comment 1

[Roland Mainz]

Attachment: Build logs from failed Mozilla 0.8.1 build using -xipo

Comment 2

[Roland Mainz]

More infos:
% cc -V
cc: Sun WorkShop 6 update 2 C 5.3 EA2 2001/02/24
usage: cc [ options] files.  Use 'cc -flags' for details
% CC -V
CC: Sun WorkShop 6 update 2 C++ 5.3 EA2 2001/02/24
% uname -a
SunOS castor 5.7 Generic_106541-15 sun4u sparc SUNW,Ultra-5_10

Sun Workshop 6 Update 2 EarlyAccess 2 is available from
http://access1.sun.com/fortedevprod/

Comment 3

[cls]

At a glance, it looks like the nspr libs may not be generated correctly.  Can
you try building and running the tests in nsprpub/pr/tests/ ?

Comment 4

[Roland Mainz]

I tried to build&run the tests using the 2001-04-01-08-trunk tarball (which
fails to compile at the same poing and with the same error as 0.8.1 tarball as
described here...).
Build succeded - but running the test is a pain because some of the test don't
finish and hang forever... (what about a stupid script which kills the single
test apps. after two or five mins ?)
After some testing I stopped because it seems that either the test suite does
not work on Solaris or does not work work with -xipo or I am doing something 
wrong.
Current log looks like this (I replaced the "nbconn" and "pipeping" binaries
with 0-size files (e.g. rm xxx; touch xxx) because they sin forever...):
-- snip --
% make runtests 2>&1 | tee mylog

NSPR Test Results - .

BEGIN                   Mon Apr  2 05:07:28 MET DST 2001
NSPR_TEST_LOGFILE       /dev/null

Test                    Result

accept                  Passed
acceptread                      Passed
addrstr                 Passed
affinity                        Passed
alarm                   Passed
anonfm                  Passed
atomic                  Passed
attach                  Passed
bigfile                 Passed
bigfile2                        Passed
bigfile3                        FAILED
cleanup                 Passed
cltsrv                  Passed
concur                  Passed
cvar                    Passed
cvar2                   Passed
dceemu                  Passed
dlltest                 Passed
dtoa                    FAILED
errcodes                        Passed
exit                    Passed
fdcach                  Passed
fileio                  Passed
foreign                 Passed
forktest                        Passed
fsync                   Passed
gethost                 Passed
getproto                        Passed
i2l                     Passed
initclk                 Passed
inrval                  Passed
instrumt                        Passed
intrupt                 Passed
io_timeout                      Passed
ioconthr                        Passed
ipv6                    Passed
join                    Passed
joinkk                  Passed
joinku                  Passed
joinuk                  Passed
joinuu                  Passed
layer                   Passed
lazyinit                        Passed
lltest                  Passed
lock                    Passed
lockfile                        Passed
logger                  Passed
makedir                 FAILED
multiacc                        Passed
multiwait                       Passed
many_cv                 Passed
nameshm1                        Passed
nbconn                  FAILED
nblayer                 Passed
nonblock                        Passed
ntioto                  Passed
ntoh                    Passed
op_2long                        Passed
op_excl                 Passed
op_filnf                        Passed
op_filok                        Passed
op_noacc                        Passed
op_nofil                        Passed
openfile                        FAILED
parent                  Passed
perf                    Passed
pipeping                        FAILED
pipepong                        FAILED
pipeself                        Passed
poll_er                 Passed
poll_nm                 Passed
poll_to                 Passed
pollable                        Passed
prftest                 Passed
prftest1                        Passed
prftest2                        Passed
priotest                        Passed
provider                        Passed
prpoll                  Passed
ranfile                 Passed
randseed                        Passed
rwlocktest                      Passed
sel_spd                 Passed
selct_er                        Passed
selct_nm                        Passed
selct_to                        Passed
select2^CBroken Pipe
-- snip --
I stopped here - test "select2" spinns forever (at least 40 mins) and I was too
tired to continue... ;-((

Question: Is the test suite really _that_ broken or am I doing something wrong
here ?

Comment 5

[Reinout van Schouwen]

I am about to file a bug for the continued absence of a 0.8.1 build for Solaris
on the ftp site. Does this bug block the availability of such a build?

Comment 6

[Roland Mainz]

> I am about to file a bug for the continued absence of a 0.8.1 build for 
> Solaris on the ftp site. 

AFAIK plain 0.8.1 source didn't compile on Solaris...

> Does this bug block the availability of such a build?

AFAIK no. This bug is special to the "-xipo" feature of the Sun Workshop 6
Update 2...

Comment 7

[Reinout van Schouwen]

With moz0.9 around the corner, I won't file a bug for 0.8.1. But if 0.8.1 source
didn't build on Solaris, who can say if 0.9 will? Isn't this something that
should be checked before releasing a milestone?

Comment 8

[Roland Mainz]

More xipo "fun":
I tried to "hack" around the nspr problem by forcing -xipo to be used
everytimes.
This looks better now - but still fails (2001-04-25 CVS snapshot):
-- snip --
% export CC="/opt/SUNWspro/bin/cc -fast -xarch=v7 -xipo"
CXX="/opt/SUNWspro/bin/CC -fast -xarch=v7 -xipo" CFLAGS="-I/usr/include
-I/usr/local/include" CXXFLAGS="-I/usr/include -I/usr/local/include"
%x../../../../../home/mozilla/src/2001-04-25-cvs/mozilla/configure --with-xprint
--enable-mathml --enable-svg --enable-xsl --enable-optimize="-fast -xarch=v7
-xipo" --enable-nspr-autoconf 2>&1 | tee -a buildlog_ws6_gtk_xipo.log
[bla blah...]
/opt/SUNWspro/bin/cc -fast -xarch=v7 -xipo -I/usr/include -I/usr/local/include
-DOSTYPE=\"SunOS5\" -DOSARCH=\"SunOS\" -DMOZ_REFLOW_PERF -DMOZ_REFLOW_PERF_DSP
-DOJI -DEXPORT_JS_API  -DJS_USE_SAFE_ARENA
-I/shared/bigtmp/mozilla/2001-04-25-cvs/objdir_ws6_gtk_xipo/dist/include/nspr 
-o jscpucfg
../../../../../../../home/mozilla/src/2001-04-25-cvs/mozilla/js/src/jscpucfg.c
./jscpucfg > jsautocfg.tmp
./jscpucfg: unknown byte order!
gmake[2]: *** [jsautocfg.h] Error 1
gmake[2]: Leaving directory
`/shared/bigtmp/mozilla/2001-04-25-cvs/objdir_ws6_gtk_xipo/js/src'
gmake[1]: *** [export] Error 2
gmake[1]: Leaving directory
`/shared/bigtmp/mozilla/2001-04-25-cvs/objdir_ws6_gtk_xipo/js'
gmake: *** [export] Error 2

real    14m50.901s
user    6m18.620s
sys     1m17.550s
-- snip --

Uhm... can anyone decrypt that error message, please ?
going to attach build logs...

Comment 9

[Roland Mainz]

Attachment: Build logs compiling 2001-04-25-cvs with WS6U2EA2 -xipo option...

Comment 10

[cls]

Sounds like -xipo is terminally broken.  Looking at js/src/jscpucfg.c, it will
spit out that error message whenever it cannot determine the endianness of the
machine.  Sounds like -xipo is optimizing something away.

Reinout, this problem only applies to Roland's special build flag.  The default
build does not contain this build flag and works fine.

Comment 11

[Roland Mainz]

Sun Workshop 6 Update 2 _FCS_ suffers from the same issue - without
-O/-fast/-xipo !!
Looks like a bug in jscpu.c code.
I filed bug 92134 ("Sun Workshop 6 Update 2 _FCS_ fails to build due "jscpucfg"
error) for that issue and a patch to fix it.

We may close this one as a DUP...

Comment 12

[hacker formerly known as [e-mail]]

.

Comment 13

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 14

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 15

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 16

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 19

[Robert Kaiser]

I don't think this report is very helpful nowadays, as both our code and the compiler world has been progressing a lot. If this still happens with current code and compilers, please file a new bug under the appropriate components (it's probably not a SeaMonkey-specific issue).