We want this largely so that we can then turn on -O2, which isn't possible with our current compilers (egcs 1.1.2). There are a number of issues which need to be solved before this can happens; those bugs will be marked as blocking this one.

.

FYI gcc-3.2 has a (Yet Another) ABI change, making c++ code compiled with it incompatible on earliere gcc compilers.

It's important to note that I don't think there are any major Linux vendors who are going to end up shipping gcc 3.1 or gcc 3.0. Did anyone ship 3.0?

Mandrake 9.0 beta ships with gcc 3.1 and all system compiled with it. So Mandrake 9 will ship with probably with gcc 3.2 as it will contains c++ abi fixes and probably Suse & Redhat will follow.

The last Red Hat beta from a few days ago is shipping with a 3.2 pre-release with the ABI changes and most of the C++ changes.

Mandrake 9.0 beta 2 has already switched to gcc 3.2 pre-release and final Mdk 9.0 will ship with gcc 3.2 final.. All linux distros (and even FreeBSD) have agreed to use gcc 3.2 to ensure C++ ABI is conformed to the V3 multi-vendor standard.

Well some distros like my Slackware Linux wont upgrade to gcc 3.2 unless Linus says "Gcc 3.2 is kernel compiler now" . So I think its a better idea to provide gcc 2.95.3 compiled mozillas.

I don't think this legitimately depends on 107976. Just make sure "gcc" points to gcc 3.2 and you don't need support for overriding the compiler coreconf uses.

Beware http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=168134 which reports a Mozilla ICE w/ gcc 3.2.

Besides the fact that the compiler used in that bug is not gcc-3.2... (hint: debian calls the executable g++-3.2)

g++ is a part of gcc. But, yes, it is a snapshot... and apparently newer snapshots fixed it. So that is no longer a problem.

Debian's default compiler for all its binaries is gcc-3.2. gcc-2.95 is quickly becoming obsolete. Besides there's the issue of the loose of performance (the GCC team claims gcc-3.2 produces 10% faster code, can we add another 10% of not being able to use full optimization?). Sorry for the spam. =)

FreeBSD-CURRENT's default compiler is: $ gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20021119 (release) and Mozilla works great (built from scratch)

Debian sid now contains Mozilla 1.2.1 compiled with gcc/g++ 3.2.

FWIW, the brad tinderbox Z value went down 311K (over two steps, for some odd reason - possibly the compiler was updated half way through) when it was upgraded to 3.3 (well, the debian 3.3 prerelease) It also now produces 40000 warnings, but thats using a non-default warning flag warning about a gcc ABI bug, and theres a bug on that to work arround the issue. Random loser was js_interpret @+3.8K; random winner was nsIndexedToHTML::OnStartRequest @-0.9K. js_Interpret looks like loop unrolling of some sort, or possibly inlining; there are a lot of changes and its hard to work out what is happening. The nsIndexedToHTML change is coming from lots of little places, it appears. It also looks like the compiler is skipping some virtual call overhead; I see: - movl _ZTV24nsASingleFragmentCString@GOT(%ebx), %ecx - addl $8, %ecx - movl %eax, -1064(%ebp) - movl %eax, -88(%ebp) + leal -104(%ebp), %eax + movl _ZTV18nsDependentCString@GOT(%ebx), %esi + addl $8, %esi + movl %eax, -1172(%ebp) I can't seem to match that chunk to a source code line to see exactly what is happening, though.

Java plugin 1.4.2 will work correctly with Mozilla, for more information see this Java bugParade bug: <http://developer.java.sun.com/developer/bugParade/bugs/4687814.html> Choice quote from that bug: "FRI JUN 07 12:48 P.M. 2002 steven_m_katz No it is a Mozilla issue in that Mozilla's answer to compatability of the plugin interface has always been, "Those interfaces arn't final until the product ships and we can and do change them at will". They are perfectly within their right to say this, but it makes support of Mozilla impossible given the long lead times inherent in the release of the JRE/plugin. Maybe that situation will change now that 1.0 has shipped. To further complicate matters, Netscape shipped product based on these changable interfaces. Since the two browsers are not compatable and we don't have the resources to support each version of Netscape and every version of pre-release Mozilla, we had to make a choice. That choice was to support the released product (ie Netscape). The most current verison of Mozilla's plugin interface is definitly a step in the right direction. It eliminates the use of static C++ symbols which should make the choice of compiler a non-issue. So what Sun is saying when it says they don't support Mozilla is: "We expect the two browsers, Netscape and Mozilla, to provide bug for bug compatable plugin interfaces. To the extent that they don't we will choses to support Netscape." I urge the user community to push both Netscape and Mozilla to keep their plugin intefaces in sync."

But the comment quoted in comment #16 was entered on June 7, 2002--over a year ago. The "evaluation" section of the Java bug has the following annotation, entered in March 2003: We need to build two version of OJI plugin due to SuSe8.1 release which ships the 3.2 compiled Mozilla. Didn't Red Hat and Sun recently enter a partnership whereby Red Hat will distribute Sun's JDK? If so, this problem must be on Sun's radar screen.

Thought I'd point out that sometime recently, this sort of happened (though this is just one build, and not sure it pertains to all the builds we spin). I just downloaded Mozilla build 2003062805 and my about:buildconfig says: Build platform target i686-pc-linux-gnu Build tools Compiler Version Compiler flags gcc gcc version 3.2.3 -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -pedantic -Wno-long-long -g -pthread -pipe c++ gcc version 3.2.3 -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -pedantic -Wno-long-long -g -fshort-wchar -pthread -pipe -I/usr/X11R6/include Configure arguments --disable-tests --enable-extensions=default,irc --without-system-nspr --without-system-jpeg --without-system-zlib --without-system-png --without-system-mng --disable-debug --enable-optimize --disable-elf-dynstr-gc --enable-crypto

The default builds have indeed changed, thanks to leaf's hard work. This means we can now switch them to -O2. Woot!

Fixed.