Switch to gcc 4.6.3

[GoogleCodeExporter]

For 7400, 7450, G5,
-ftree-vectorize

For G5,
-mcpu=G5 -mno-powerpc64
and remove the stupid kludge we are using currently for 32-bit compiles.

These options are a little risky, so let's test them thoroughly.

Original issue reported on code.google.com by [email protected] on 5 Apr 2011 at 10:44

• Blocking: Profile-guided optimization #6, [meta] Judgment Day #173, atexit handlers crash C++ runtime #169

[GoogleCodeExporter]

Actually, critical; we will ship the test beta with these.

Original comment by [email protected] on 5 Apr 2011 at 10:45

• Added labels: Priority-Critical
• Removed labels: Priority-High

[GoogleCodeExporter]

You also may want to try GCC 4.6 - it has significant improvements in 
compatibility with Mac OS frameworks. Though it does not support Tiger.

GCC 4.2 could also be replaced with llvm-gcc 2.9 - it outperforms GCC 4.2 in 
benchmarks.

Original comment by [email protected] on 11 Apr 2011 at 10:06

[GoogleCodeExporter]

4.6 is out precisely because it doesn't support Tiger. I use Tiger myself, so 
that's pretty much the end of that.

Original comment by [email protected] on 11 Apr 2011 at 12:30

[GoogleCodeExporter]

Between issue 23, issue 28 and issue 50, I think we have a little too much to 
test in the next beta and this could introduce subtle bugs, so I'm going to 
defer this to the one after and mark High.

Original comment by [email protected] on 11 Apr 2011 at 1:23

• Added labels: Priority-High
• Removed labels: Priority-Critical

[GoogleCodeExporter]

implemented for 4.0.2 in 7400, 7450 and G5

Original comment by [email protected] on 12 May 2011 at 5:14

• Changed state: Started

[GoogleCodeExporter]

First build with G5 crashed immediately. Dropped -ftree-vectorize, replaced 
with -fivopts.

Original comment by [email protected] on 12 May 2011 at 12:59

[GoogleCodeExporter]

Absolutely no change in benchmarks. Because this is a potentially risky change 
with little gain, we're deferring until we have to use 4.2 and then we can see 
if -ftree-vectorize works again.

Original comment by [email protected] on 12 May 2011 at 1:23

• Changed title: Compiler options to consider post-gcc 4.2
• Added labels: Priority-Medium
• Removed labels: Milestone-Next4, Priority-High

[GoogleCodeExporter]

I researched a little bit more about the altivec related compiler flags and 
found out the following:
Specifying an Altivec-capable CPU type does not (any longer?) automatically 
enable "-faltivec" (which is more or less equivalent to "-mpim-altivec") but it 
does just enable "-maltivec". "-faltivec" allows for access to Altivec 
functions without the need of a special header file while with "-maltivec" a 
Altivec header file is needed. "-faltivec" seems to be the old-fashioned 
version and Carbon (which comes from classic Mac OS) needs that type. So one 
always needs to pass "-faltivec" to gcc when using Carbon API calls. In any 
other case access to Altivec should be possible without specifying "-faltivec".
But there are some other implications: when specifying a CPU type of ppc7400 
together with "-faltivec" the CPU type is reverted to just ppc. That is not the 
case for cpu types of ppc7450 or ppc970.
That behavior seems to have changed from Tiger gcc-4.0 (Apple build 5370) to 
the more recent versions that come with Xcode 3.

Original comment by [email protected] on 1 Jun 2011 at 10:09

[GoogleCodeExporter]

> when specifying a CPU type of ppc7400 together with "-faltivec" the CPU type 
is reverted to just ppc.

How did you notice this?

This sounds like a bit of a minefield, so maybe we should (while gcc-4.0 is the 
officially supported compiler) leave the mozconfigs alone except for 
--enable-*strip, and make a note in the build instructions.

Original comment by [email protected] on 1 Jun 2011 at 12:49

[GoogleCodeExporter]

I changed the gcc parameters and looked at the architecture of the output file; 
actually I should have said "architecture" instead of "cpu type". From the 
manpage of gcc I get the impression that for gcc the only difference between 
ppc750 and ppc7400 is the switch "-maltivec". Code compiled with that switch 
enabled obviously can't run on G3 CPUs anymore. Hence it gets the architecture 
"ppc7400". That's different with "-faltivec" where gcc isolates all functions 
that access the vector unit so that the code itself can decide whether to use 
an Altivec-optimized code path or not. Hence that code gets the architecture 
"ppc" (but the code in that case can try to access the vector unit on a G3 CPU 
what will lead to an exception). For ppc7450 or ppc970 that's different because 
there are other optimizations apart from "-maltivec" switched on that only work 
with these respective CPU types - while a G5 CPU should always be able to 
execute code of the architecture ppc7450 as well. So switching on "-faltivec" 
together with cpu type of ppc7450 or ppc970 doesn't make the code runnable on 
G3 CPUs as well. Hence the compiled code still gets the architecture ppc7450 or 
ppc970.

About supported compilers:
Is there really still any "support" for gcc-4.0 build 5370?
For me support would be providing later gcc versions built for 10.4 that 
include bug fixes.
Apple doesn't provide any support any more for gcc-4.0 build 5370 in Tiger. 
It's the same way unsupported in Tiger as later versions of gcc-4.0, gcc-4.2, 
llvm-gcc-4.2 or clang.
Support for any compilers in Tiger is in fact up to us. There's almost no one 
else any more - except for Gentoo Prefix. They in fact still do support 
building of all those compilers, ld64 and cctools in Tiger.

Original comment by [email protected] on 1 Jun 2011 at 6:21

[GoogleCodeExporter]

Not supported by Apple -- supported by us. Since gcc-4.0(5370) is the compiler 
that comes with Xcode 2.5, that's the compiler I want to maintain support for 
out of the box. I'd like to support the linker, too, but since that won't work 
we'll support "yours" -- but that means we also have to distribute it, etc. I'd 
like to keep as many tools "standard" as possible until they don't work or 
can't be made to work. There are some compiler bugs in 5370, but the patches 
work around them.

For that reason I'm going to keep the mozconfigs otherwise the same (I did make 
a tweak to DEBUG which will come with the beta changesets) except for the strip 
options. I'm using one such strip build now on the G5 and 50.9MB is quite 
acceptable for size. When gcc-4.2 becomes our minimum required compiler, and I 
imagine it will sooner or later, then we'll revise our command line options.

Obviously gcc-4.2 will remain an option until then, but it will be experimental 
for now, and the required changes will be in the build notes rather than in the 
configs.

Original comment by [email protected] on 2 Jun 2011 at 6:00

[GoogleCodeExporter]

(changing status back to accepted since we're not moving on this yet)

Original comment by [email protected] on 2 Jun 2011 at 6:05

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by [email protected] on 3 Jun 2011 at 10:27

[GoogleCodeExporter]

Did a build with llvm-gcc-4.2 based on llvm 2.9 .
The build did mainly work as well as with gcc but there were a few files which 
couldn't be compiled when generating debug symbols "-g" was turned on. Those 
files I manually compiled deleting "-g" from the command line.

Why do we build with debug symbols even the optimized builds?
Shouldn't it only be activated when using the method described on the following 
web page? https://developer.mozilla.org/en/Building_Firefox_with_Debug_Symbols

With the resulting Aurora.app I ran dromaeo and it gave 39 runs/s on the G4 1,5 
GHz vs. 53 runs/s with the same application compiled with gcc.

Did you notice that libffi isn't compiled with the compiler specified by 
"CC"/"CXX" but with just "usr/bin/gcc"?

Original comment by [email protected] on 5 Jun 2011 at 8:38

[GoogleCodeExporter]

We build with debug symbols on even in opt builds because we don't have a crash 
reporter system, and this gives me a chance to get debug information off other 
people's systems.

Nice spot on the libffi, although I imagine that's a Mozilla bug.

That's rather disappointing that llvm does significantly worse, but I bet 
people really aren't working on PPC optimization in it. IBM does and did donate 
quite a bit of code to gcc.

Original comment by [email protected] on 5 Jun 2011 at 9:18

[GoogleCodeExporter]

A question: on the topic of GCC 4.2. For those who have a Power Mac G5 with the 
dual-core PowerPC 970FX (G5) cpu, are you:

1) auto-parallelizing (-ftree-parallelize-loops)?

2) using all cores (-fopenmp or -openmp)?

Just curious.

Original comment by [email protected] on 11 Jun 2011 at 12:08

[GoogleCodeExporter]

Those are certainly ones to consider when we have to make the jump, but I have 
not tried them personally. Perhaps Tobias has.

Original comment by [email protected] on 11 Jun 2011 at 3:04

[GoogleCodeExporter]

As I don't have any multi-cpu Mac I can't test a build with that options.
But I could very easily provide the tarball containing the gcc-4.2 installation 
I built.
As I built it the Apple way it doesn't overwrite any files of the already 
installed compilers; Apple modifies the install locations of gcc components to 
make coexistence of various compiler versions possible.
So there shouldn't be any risk in installing that tarball.

Original comment by [email protected] on 11 Jun 2011 at 8:00

[GoogleCodeExporter]

I recently built gcc-4.6 on my 10.4 installation. There weren't any problems 
during compilation and linking!
Building pure C applications works without problems.
In order to get C++ applications to be built against the (quite old) version of 
libstdc++ I needed to modifiy some system headers but gcc provides an easy 
method to do so without touching the original headers (fixincludes).
Compiling Objective-C/C++ also seems to work which is needed for interfaces the 
Mac OS system frameworks. Compatibility with Mac OS frameworks is a new feature 
in gcc-4.6 and is officially supported only for 10.5 and 10.6.
So finally I could get XUL compiled - but linking failed in the first attempt. 
There is a linker (ld64 97.17) warning for which there is already a proposed 
gcc fix available that I expect to appear in a future release of gcc. I applied 
that patch to my gcc sources built it again but didn't have the time yet to 
rebuild whole XUL. Just recompiling the files the linker warns about didn't 
help.
I also noticed that in gcc-4.6 "-ftree-vectorize" is automatically switched on 
by "-O3" so that's expected to work in that version.

Original comment by [email protected] on 11 Jun 2011 at 8:16

[GoogleCodeExporter]

Managed to build XUL with gcc-4.6 - and it seems to work!

Found out that "ftree-vectorize" has to be turned off at least for (some?) 
ObjC++ files (maybe also ObjC files). Turning on "ftree-vectorize" for those 
files results in linker errors. So for gcc-4.6 one has to downgrade 
optimization level to 2. One can still manually turn on the other options O3 
turns on.

For my first working XUL I compiled all ObjC++ files with O2 and all options 
that O3 turns on except for ftree-vectorize. All other files were built with 
O3. A first test of JavaScript performance gave no improvements over a gcc-4.2 
compiled XUL on my 500 MHz G4 7400.

Original comment by [email protected] on 11 Jun 2011 at 7:38

[GoogleCodeExporter]

Nice! I'm not too worried about there being no performance improvement; I just 
didn't want there to be a significant *drop*. So it's good to know that the 
option is there if Mozilla stops supporting 4.0/4.2.

Original comment by [email protected] on 11 Jun 2011 at 9:25

[GoogleCodeExporter]

Thanks for the feedback. When you finally decide to use GCC 4.2 or 4.6, it 
would be interesting to see if taking advantage of parallel-processing compiler 
options making any difference in performance. I've read that on devices that 
have dual-core A9 ARM chips (like Tegra 2) and use Android OS (2.3 or higher) 
can do this: they use one core for the browser and other core for the Flash, 
for example. I wonder if this can be achieved on TenFourFox. It probably is 
more complicated in reality. Autovectorization is really only part of the 
equation: is the compiler you currently use making use of all VMX/Altivec cores 
on the multicore/multiprocessors on G5 macs without the use of OpenMP or the 
autoparallelization flags? This allow you to squeeze out the very last drop of 
performance. 

Original comment by [email protected] on 11 Jun 2011 at 11:07

[GoogleCodeExporter]

Well THAT's impressive!

I compiled whole TenFourFox 5 (based on that first preliminar patchset) with 
gcc-4.6. For JavaScript and NSPR I set the optimization level to O3 (that means 
"tree-vectorize" on) and the rest was built with O2 and every options O3 
includes except for "tree-vectorize". I chose JavaScript (including libffi) and 
NSPR for autovectorization because they are configured independently of the 
rest.

And JavaScript performance (dromaeo) on the G4 1,5 GHz improved to 59,5 runs/s. 
That's 10% faster! And the build was optimized for G4 7400 and not 7450 what 
could result in additional improvements.

Maybe autovectorization for just NSPR and JavaScript also works with gcc-4.0 ?!

Additional improvements could be achieved by using LTO but I read that for 
linking XUL with LTO switched on needs 8GB of RAM and my best machine has just 
1.25GB.

Original comment by [email protected] on 12 Jun 2011 at 10:46

[GoogleCodeExporter]

Nice work. It might indeed. I'll schedule that for 6, though, since we're too 
far into 5 (I want to do only one more beta cycle, and issue 68 is higher 
priority).

Original comment by [email protected] on 12 Jun 2011 at 11:00

[GoogleCodeExporter]

Did one final try adding link time optimization to the gcc flags for NSPR and 
JavaScript.
JavaScript performance in dromaeo however wasn't affected.

So now after all my tests of different toolchain versions I ended up having 
tarballs of gcc-4.0.1, gcc-4.2.1, gcc-4.6.0, llvm-gcc-4.2 (LLVM 2.9), 
clang-2.9, ld64-97.17, cctools-800, cctools-782 (needed for compatibility with 
LTO in gcc-4.6) ready for installation on stock Mac OS X 10.4.
I wonder whether I could/should provide those packages for download in some 
place...

Original comment by [email protected] on 13 Jun 2011 at 7:51

[GoogleCodeExporter]

And there is no more crash on exit! So this solves issue 169, as predicted. 
Beer for Tobias!

Original comment by [email protected] on 14 Dec 2012 at 2:24

[GoogleCodeExporter]

Original comment by [email protected] on 14 Dec 2012 at 2:27

• Now blocking: atexit handlers crash C++ runtime #169

[GoogleCodeExporter]

`/opt/local/bin/gcc-mp-4.6 -print-prog-name=ld` -v
@(#)PROGRAM:ld  PROJECT:ld64-97.18

Original comment by [email protected] on 14 Dec 2012 at 3:27

[GoogleCodeExporter]

SeaMonkey PPC lives !

patched and built ld64 using Tobias' fix and am typing this from 2.15b4.

Thanks much guys


ps I've been using gcc version 4.7.2 (MacPorts gcc47 4.7.2_2) - works great

Original comment by hiker.x.biker on 14 Dec 2012 at 2:34

[GoogleCodeExporter]

Other than a mistake I made fixing gfxMacPlatformFontList.mm, no major issues. 
Up and running, 4.6.3, 97.18.

Original comment by [email protected] on 15 Dec 2012 at 4:23

[GoogleCodeExporter]

Opt builds don't yet work, though. For the G5 I have, currently,
export CC="/opt/local/bin/gcc-mp-4.6 -flax-vector-conversions -O3 -mcpu=7450 
-mtune=G5 -falign-loops=16 -falign-functions=16 -falign-labels=16 
-falign-jumps=16 -mmfcrf -mpowerpc-gpopt -read_only_relocs suppress 
-force_cpusubtype_ALL -mdynamic-no-pic -D_PPC970_ -mmacosx-version-min=10.4"
export CXX="/opt/local/bin/g++-mp-4.6 -flax-vector-conversions -fpermissive -O3 
-mcpu=7450 -mtune=G5 -falign-loops=16 -falign-functions=16 -falign-labels=16 
-falign-jumps=16 -mmfcrf -mpowerpc-gpopt -read_only_relocs suppress 
-force_cpusubtype_ALL -mdynamic-no-pic -D_PPC970_ -mmacosx-version-min=10.4"

However, it's not linking double_conversion.o into mozlibglue, so JS can't 
build (but there is a double_conversion.o). This obviously worked fine in debug 
mode. What are your opt compiler strings?

Original comment by [email protected] on 19 Dec 2012 at 12:20

[GoogleCodeExporter]

There's just "-mcpu=7400 -mtune=G5" added to the compiler arguments.
But in order to build 32 bit objects for a G5 (as is done for WebKit and 
AuroraFox libmozjs.dylib) you have to pass "-mcpu=970 -m32". Otherwise (like 
you've probably noticed) gcc will think you'd want 64 bit objects as the 970 is 
a 64 bit CPU.
Do you really need "-force_cpusubtype_ALL"? I'd think that in case you don't do 
runtime CPU feature detection that can just cause problems because it's not 
correct. Was this necessary to have the old linker link the ppc970 objects with 
ppc libraries/objects?
I'd also recommend to leave "-mmfcrf -mpowerpc-gpopt" out as this is already 
done by "-mcpu=970".

Original comment by [email protected] on 19 Dec 2012 at 12:41

[GoogleCodeExporter]

I think the -m32 is the part I'm missing. I need (or at least I did with 4.0.1) 
the -force_cpusubtype_ALL because the assembler compiled the VPX AltiVec 
objects as generic "ppc" -- I'll see if that's still the case with the new 
bintools as. I'll try that later tonight (checking E-mail between meetings).

Original comment by [email protected] on 19 Dec 2012 at 2:30

[GoogleCodeExporter]

libmozglue should have all the mfbt stuff in it (it does in DEBUG) and it 
doesn't even with -m32. So something else is afoot. It's clearly related to the 
compiler arguments, but even simply -flax-vector-conversions -fpermissive -O3 
-mcpu=7450 -mtune=G5 won't do it.

Original comment by [email protected] on 19 Dec 2012 at 7:04

[GoogleCodeExporter]

It's one of the options, not the compile string. I'm just going to start 
cutting them out one by one until it works.

Original comment by [email protected] on 19 Dec 2012 at 7:24

[GoogleCodeExporter]

It's the -enable-strip/-enable-install-strip options. I guess strip is a little 
overzealous on the new object files this generates. Without those, all the 
symbols now appear correctly in libmozglue.

Original comment by [email protected] on 19 Dec 2012 at 7:47

[GoogleCodeExporter]

I didn't ever build Aurora with strip options so I didn't know this.
In order to specify the output architecture of objects the assembly must 
contain a machine directive, for just Altivec this would be ".machine ppc7400" 
and for the G5 ".machine ppc970" obviously.
For example TrampolinePPCOSX.S (note that it must be 'S', not 's', in order to 
have gcc automatically run the preprocessor on the file) in Aurora contains the 
following lines at the top (gcc has to be run with "-mcpu=970" in order to have 
_ARCH_PWR4, defined which I use instead of _PPC970_):

#if defined(_ARCH_PWR4)
#warning building optimized for G5/POWER4
.machine ppc970
#endif

But I only need this in order to be able to build a multi-arch (ppc7400/ppc970) 
static js library, because libtool isn't aware of the concept of arches and 
subarches (and lipo is only partially and needs this workaround). This isn't 
necessary for building multi-arch executables or dylibs.

Original comment by [email protected] on 19 Dec 2012 at 9:28

[GoogleCodeExporter]

I had "-force_cpusubtype_ALL" added to the libvpx Makefile only but now I 
removed that and added ".machine ppc7400" to all Altivec assembler source files.
Not generally passing "-force_cpusubtype_ALL" has the big advantage that the OS 
wouldn't allow to start a version of TenFourFox that isn't compatible with the 
CPU.

Original comment by [email protected] on 20 Dec 2012 at 8:54

[GoogleCodeExporter]

True, except that the 970 version I build is -mcpu=7450 -mtune=G5 anyway.

Original comment by [email protected] on 20 Dec 2012 at 4:13

[GoogleCodeExporter]

Doesn't Tiger support the subarch ppc970?

Original comment by [email protected] on 20 Dec 2012 at 4:52

[GoogleCodeExporter]

Yes, but making an -mcpu=G5 build was notoriously unstable. Might have been gcc 
4.0.1, though.

In any case, G5 opt build is now working. Last step before I close is to build 
a portable opt build and/or write a builder script to copy libraries and change 
the dyld executable path.

Original comment by [email protected] on 21 Dec 2012 at 4:51

[GoogleCodeExporter]

WebKit built with gcc 4.2 and -mcpu=G5 does indeed work as well as the G5 
optimized libmozjs dylib which is built with gcc 4.7 and -mcpu=970 -m32.
I noticed that gcc 4.6 (maybe FSF gcc in general) and later define _ARCH_PPC64 
when building with just -mcpu=970 and concluded that there must  be something 
wrong as I wanted 32 bit G5 optimized. As I wanted to be sure and didn't have a 
G5 machine to test on I chose to add -m32.
Now -m32 and -m64 are supposed to select Darwin or Darwin64 ABI. Turns out -m32 
does something more in also disabling the use of 64 bit instructions/GPRs, what 
can be controlled directly by setting -m(no-)powerpc64. I compiled a simple 
test program that does 64 bit integer division using different compiler 
switches. The settings "-mcpu=970" and "-mcpu=7450 -mpowerpc64" result in a 
binary that does native 64 bit integer division even in the 32 bit Darwin ABI, 
with the architecture of the output file being set to ppc970 in both cases. 
Passing "-m32" reverts "-mpowerpc64" when passed last (don't know if gcc is 
really supposed to behave like this).
The conclusion is that _ARCH_PPC64 does just mean that the use of 64 bit 
instructions/GPRs is enabled and has nothing to do with the ABI.

Original comment by [email protected] on 21 Dec 2012 at 7:58

[GoogleCodeExporter]

Given the not too scarce use of uint64_t in the js library and the whole 
codebase building with -mpowerpc64 or -mcpu=970  should result in some speed 
improvement on G5s. I'll compare JavaScript performance.

Original comment by [email protected] on 21 Dec 2012 at 11:19

[GoogleCodeExporter]

Now I know why I had to add -m32; either gcc produces wrong mach-o objects or 
ld64 links them wrong and dyld returns "unknown local relocation type" when 
trying to load the ppc970 dylib.

Original comment by [email protected] on 22 Dec 2012 at 1:41

[GoogleCodeExporter]

So are you saying -mcpu=G5 -m32 -mpowerpc64 ?

Incidentally, as a followup to strip, I noticed that the new libxul created by 
this is almost 70MB in the G5 version (!). However, it *can't* be stripped; 
10.4 strip actually barfs on it and refuses to alter the file. So that's that.

Original comment by [email protected] on 22 Dec 2012 at 9:15

[GoogleCodeExporter]

-mcpu=G5 implicates -mpowerpc64 which is reverted by -m32 . So "-mcpu=G5 -m32 
-mpowerpc64" should be the same as just -mpcu=G5. Although I didn't test it 
"-mcpu=G5 -mno-powerpc64" should be equal to "-mcpu=G5 -m32".

You need to use later cctools (equal to binutils), for example from the 
MacPorts port cctools.

Original comment by [email protected] on 22 Dec 2012 at 9:53

[GoogleCodeExporter]

-mcpu=G5 doesn't enable Darwin64 ABI as I first assumed. So -m32 isn't 
necessary even with -mcpu=G5.
WebKit built with gcc-4.2 and -mcpu=G5 (without adding -m32) does work, so I 
don't know where the acutal problem is that I get when building libmozjs.dylib 
as fat binary. Might be related to libxpcom. Additionally it does only work 
when ppc970 comes before ppc7400.

Original comment by [email protected] on 22 Dec 2012 at 10:07

[GoogleCodeExporter]

I already tried that. /opt/local/bin/strip actually makes a defective XUL 
(rather than just giving up):

XPCOMGlueLoad error 4:0 for file 
/Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFox.app/Contents/MacO
S/libxpcom.dylib:
Symbol not found: _CC_MD5_Final
  Referenced from: /Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFox.app/Contents/MacOS/XUL
  Expected in: /Volumes/BruceDeuce/src/mozilla-19a/obj-ff-dbg/dist/TenFourFox.app/Contents/MacOS/XUL

Couldn't load XRE functions.

This is probably due to the phony CommonCrypto stubs I put in to get Chromium 
IPC to work on 10.4.

Original comment by [email protected] on 22 Dec 2012 at 10:29

[GoogleCodeExporter]

The mozilla sources pass "-x -S" as parameters to strip. Are you using the same?

Original comment by [email protected] on 22 Dec 2012 at 10:49

[GoogleCodeExporter]

D'oh.

Original comment by [email protected] on 22 Dec 2012 at 10:55

[GoogleCodeExporter]

Regarding the mcpu=G5 or mcpu=970 problems I found some other people have also 
had problems with that in the past and finally this: 
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01061.html
So that might eventually get fixed.

Original comment by [email protected] on 28 Dec 2012 at 1:21

[GoogleCodeExporter]

In order to have it documented in this context:
By merging the changes from gcc 4.2.2 until 4.2.4 into Apple's gcc 4.2 (based 
on 4.2.1) the two compiler issues I had with Leopard WebKit can be solved. One 
was that ftree-vrp caused wrong code in a certain loop constellation and the 
other was mcpu=970 (or mcpu=G5), which includes mpowerpc64 caused wrong 
behaviour on some websites. So now using MacPorts gcc 4.2.4 Apple build 5666.3 
I don't have any remaining issues with that compiler.

Regarding the problem that dyld has with loading the mcpu=G5 (respectively 
mpowerpc64) built libmozjs.dylib I found out that by compiling without 
optimization (-O0) that issue is gone. However I was unable to determine which 
optimization exactly caused this problem, as it persists even when I turn off 
all switchable optimizations and optimization passes. So that is actually a 
very different problem from the ones I had with Leopard WebKit.

Original comment by [email protected] on 1 Jan 2013 at 4:00