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 classi...@floodgap.com on 5 Apr 2011 at 10:44

• Blocking: #6, #173, #169

[GoogleCodeExporter]

BrowserStreamParent/Child, transform-vmx and jpeg_consume_input all enabled, no 
crashes. So that leaves us with our text translators.

Original comment by classi...@floodgap.com on 29 Nov 2011 at 2:35

[GoogleCodeExporter]

I suspect it's one of those that return a length and/or pointer.

Original comment by Tobias.N...@gmail.com on 29 Nov 2011 at 9:29

[GoogleCodeExporter]

You may be partially right. nsUTF8ToUnicode is definitely a culprit; the 
browser goes haywire. FirstNon8Bit actually works, but all it does is scan 
strings, and I guess that's what makes it safe. I suspect UTF8UtilsVMX will 
also wreck it. It seems like whatever stuff writes to garbage collected objects 
is offending it.

This is all perpendicular to this bug anyway. I may ship 9 beta with them 
temporarily disabled until we can solve it. I think I'll try for Friday and you 
will get changesets then.

Original comment by classi...@floodgap.com on 30 Nov 2011 at 4:16

[GoogleCodeExporter]

Might this have something to do with caching? I think of the difference between 
vec_st() and vec_stl().
Might those functions have to be threadsafe now?

Original comment by Tobias.N...@gmail.com on 30 Nov 2011 at 7:19

[GoogleCodeExporter]

I don't know if that's the actual problem, but I'm sure it will be in the 
future if it isn't already, so we should try to make sure they are threadsafe 
also.

Original comment by classi...@floodgap.com on 30 Nov 2011 at 2:29

[GoogleCodeExporter]

Changesets are up.

Original comment by classi...@floodgap.com on 2 Dec 2011 at 4:42

[GoogleCodeExporter]

Tobias, see my comment in issue 96 -- it might be time for 4.2 if your build 
succeeds where my 4.0.1 build is failing.

Original comment by classi...@floodgap.com on 21 Dec 2011 at 11:17

[GoogleCodeExporter]

Just to not forget it:
In order to build libffi with the most recent versions of ld64 one has to apply 
the patch from https://bugzilla.mozilla.org/show_bug.cgi?id=582690 .

Original comment by Tobias.N...@gmail.com on 21 Dec 2011 at 10:56

[GoogleCodeExporter]

I've been working on getting current WebKit to build on 10.5 PPC.
From that I've learnt that when linking big files (like XUL in debug mode) you 
can get the error message "ld: in {some object file, framework or dynamic 
library}, can't map file, errno=12" which means that the linker run out of 
address space (which is more limited in a 32-bit environment).
What the WebKit team did to get WebKit to link in 32-bit Windows is to compile 
groups of files (for example whole subdirectories) at once by creating 
all-in-one cpp files that just include all the cpp files of a group. Instead of 
compiling all the files of that group individually only that all-in-one file is 
compiled.

(By the way ;-), the results of my WebKit build work you can test here: 
http://code.google.com/p/leopard-webkit/ )

Original comment by Tobias.N...@gmail.com on 22 Jan 2012 at 10:10

[GoogleCodeExporter]

http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/182cfdd
b3ae5767e

Mozilla is forcing the issue in Fx17, so Fx18 looks like the right time to 
switch to gcc 4.6.

Original comment by classi...@floodgap.com on 5 Jul 2012 at 8:15

[GoogleCodeExporter]

On the AuroraFox download page 
(http://code.google.com/p/aurorafox/downloads/list) I upload my recent 
mercurial patch queue which contains one patch with the changes necessary for 
building with gcc 4.6 (fixes_for_building_with_gcc-4.6.patch).

Original comment by Tobias.N...@gmail.com on 19 Jul 2012 at 10:16

[GoogleCodeExporter]

I tried building 4.6.3 on the G5 and it fails verification between stage 2 and 
stage 3. What gcc are you using, 4.6.1?

I want to install separate bintools so that 4.0.1 will still be available as a 
fallback strategy, and 17ESR will still be built with 4.0.1, which is why I'm 
dealing with this now.

Alternatively, there is 4.5.4 (Mozilla's minimum for 18 will be 4.4).

Original comment by classi...@floodgap.com on 19 Jul 2012 at 1:35

[GoogleCodeExporter]

I'm using gcc 4.6.3 from macports here on 10.5 . Macports installs its own 
versions of ld64 and otools for building it. It will never overwrite the Apple 
provided versions of anything. And the paths to its bintools are hard coded 
into gcc's binaries, so as long as you don't touch them the toolchain will work 
as always.

For building on 10.4 I used the Apple version of gcc 4.2 to build gcc 4.6.1 .

Didn't you use macports to build gcc 4.6.3?
In the portfile there is the following specific to 10.4:
It passes the flag "--with-dwarf2" when configuring and there's a link to a 
corresponding mozilla bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248

gcc 4.6.x are the only versions that will work since Objective-C/C++ support 
was introduced with 4.6 .

Original comment by Tobias.N...@gmail.com on 19 Jul 2012 at 10:35

[GoogleCodeExporter]

It actually was a gcc bug not a mozilla one.

Until version 4.5 gcc didn't support the Apple Objective-C runtime library. 4.6 
introduced support for it and also implemented most of Objective-C 2.0 (which 
isn't supported by the 10.4 Objective-C runtime library).

Original comment by Tobias.N...@gmail.com on 19 Jul 2012 at 10:46

[GoogleCodeExporter]

That's handy. I'd still like to try to build 4.6.3 myself just to ensure that 
it works okay in case at some point in the future MacPorts screws up 10.4 and 
we have to distribute a binary /opt for builders.

Original comment by classi...@floodgap.com on 20 Jul 2012 at 11:37

[GoogleCodeExporter]

Well, then I suggest you take a look at the Portfile 
(https://trac.macports.org/browser/trunk/dports/lang/gcc46/Portfile).

Original comment by Tobias.N...@gmail.com on 20 Jul 2012 at 11:57

[GoogleCodeExporter]

gcc 4.6.3 is up and appears to work (tested it building DOSBox). I built new 
basic cctools to /opt/cctools-806/, and compiled /opt/gcc46/. This works.

However, it links to its own new libc. How are you getting around this to link 
to the system libc/libc++?

Original comment by classi...@floodgap.com on 22 Jul 2012 at 1:55

[GoogleCodeExporter]

(Above you mentioned you had done so:

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).

Do you still have those?)

Original comment by classi...@floodgap.com on 22 Jul 2012 at 1:59

[GoogleCodeExporter]

Original comment by classi...@floodgap.com on 22 Jul 2012 at 1:59

• Changed title: Switch to gcc 4.6.3
• Added labels: Milestone-Judgment-Day, Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by classi...@floodgap.com on 22 Jul 2012 at 2:04

• Now blocking: #173

[GoogleCodeExporter]

To make gcc build and link against the system libstdc++ you have to do what 
Apple does in their "build_gcc" script for gcc 4.2:
Remove the subdirectory "libstdc++-v3"
Configure gcc, setting the following parameters:
"--with-gxx-include-dir=/usr/include/c++/4.0.0"
"--with-build-sysroot=/Developer/SDKs/MacOSX10.4u.sdk"
After building you have may have to modify some header files (or at least I had 
to do so after building using a modified Apple "build_gcc" from their gcc-4.2 
sources). You'd have to compare the headers from my 
"gcc461-powerpc-darwin8.tar.gz" in the directories 
"usr/lib/gcc/powerpc-apple-darwin8/4.6.1/include" and 
"usr/lib/gcc/powerpc-apple-darwin8/4.6.1/include-fixed" with the corresponding 
ones from your build. But maybe you won't have to do so when building the 
default way.

BUT - as you will have to ship gcc-4.6's "libgcc_s.1.dylib" either way inside 
the TFF application bundle, I recommend doing the same for gcc-4.6's 
libstdc++.dylib . That's the way I'm doing it for the Aurora releases. You'd 
have to use "install_name_tool" to change the linked library paths (for that 
purpose there's a very simple shell script in the AuroraFox changesets).

Original comment by to...@jesus.de on 22 Jul 2012 at 9:03

[GoogleCodeExporter]

Once again forgot to switch to my own google account...

Original comment by Tobias.N...@gmail.com on 22 Jul 2012 at 9:06

[GoogleCodeExporter]

If the configure settings don't change the need to ship the 4.6 libgcc, then 
I'd rather just build with 4.6's includes, unless you know this doesn't work 
(and then modify your post-build script for Tiger as necessary to change the 
executable lib paths for js and firefox).

Original comment by classi...@floodgap.com on 22 Jul 2012 at 3:24

[GoogleCodeExporter]

Might be possible to avoid shipping libgcc dylib:

Read the section about "-shared-libgcc" and "-static-libgcc":
https://developer.apple.com/library/mac/#documentation/DeveloperTools/gcc-4.2.1/
gcc/Link-Options.html

So I understand that one can use "-static-libgcc" (while linking with gcc 
instead of g++) safely if everything is (or rather can be) compiled with 
"-fno-exceptions" or if exceptions are guaranteed to not be thrown in one and 
catched in another shared library.

To try that with mozilla one would have to change configure.in to set (for 
Darwin) MKSHLIB to the same as MKCSHLIB plus "-static-libgcc".

Original comment by Tobias.N...@gmail.com on 22 Jul 2012 at 8:13

[GoogleCodeExporter]

That would probably be preferable, but on the other hand, shipping an updated 
libgcc wouldn't be a bad thing ... it may actually fix some weird bugs like the 
atexit() problem.

Original comment by classi...@floodgap.com on 23 Jul 2012 at 12:20

[GoogleCodeExporter]

FWIW, I'm using gcc 4.6.3 build in Gentoo Prefix on 10.5 - seems to work fine

Original comment by annu...@gmail.com on 9 Aug 2012 at 8:34

[GoogleCodeExporter]

We need to revert https://bugzilla.mozilla.org/show_bug.cgi?id=787931 and 
possibly https://bugzilla.mozilla.org/show_bug.cgi?id=784029 for 18. Mozilla 
will not allow gcc on OS X with Fx18, and this appears to be because the new 
10.6+ widget code uses blocks. However, issue 89 will cover that.

Original comment by classi...@floodgap.com on 24 Sep 2012 at 4:35

[GoogleCodeExporter]

You might want to try blocks runtime from LLVM's compiler-rt

Original comment by annu...@gmail.com on 24 Sep 2012 at 8:12

[GoogleCodeExporter]

Sounds great, except that LLVM on PPC is a mess and won't be ready for this.

Original comment by classi...@floodgap.com on 24 Sep 2012 at 1:30

[GoogleCodeExporter]

(and, for that matter, the blocks code in question is regarding certain widget 
methods that don't even exist on 10.4, so the compiler isn't the only problem)

Original comment by classi...@floodgap.com on 24 Sep 2012 at 1:31

[GoogleCodeExporter]

As for "LLVM on PPC is a mess": code of BlocksRuntime seems to be pretty 
portable (arch/OS/compiler independent). There's PLBlocks SDK using this code 
under the hood and supporting gcc 4.2 / PPC.

Original comment by annu...@gmail.com on 24 Sep 2012 at 1:40

[GoogleCodeExporter]

Got Aurora 17 built with gcc 4.7.2 . And it also seems to be working well so 
far. Two files needed an explicit include of unistd.h .

Original comment by Tobias.N...@gmail.com on 7 Oct 2012 at 7:17

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

In my copious spare time, of course.

Original comment by classi...@floodgap.com on 10 Oct 2012 at 12:41

[GoogleCodeExporter]

In order to build Aurora 18 with gcc 4.7 there were some more changes needed - 
quite some more than for gcc 4.6 .

Original comment by Tobias.N...@gmail.com on 12 Oct 2012 at 3:47

[GoogleCodeExporter]

I'm planning to stick with 4.6.3 at least for the foreseeable future, but I 
haven't tried making a 10.4Fx build with it yet. I will probably do so when I 
get the 17 beta out.

Original comment by classi...@floodgap.com on 12 Oct 2012 at 5:26

[GoogleCodeExporter]

>Annulen, could/would you do an Aurora 10.5 LLVM build?

What do you mean under LLVM build? If you mean clang build, it's still needs 
fixes to work properly on PPC.

Original comment by annu...@gmail.com on 22 Oct 2012 at 7:33

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

What's the point to use llvm-gcc if gcc is working? It certainly
optimizes worse than gcc, especially if we take version from Xcode 3.1
(LLVM 2.6 IIRC). In LLVM trunk there were some improvements converning
PowerPC, but llvm-gcc was deprecated long ago.

2012/10/23, tenfourfox@googlecode.com <tenfourfox@googlecode.com>:

Original comment by annu...@gmail.com on 23 Oct 2012 at 7:42

[GoogleCodeExporter]

Annulen, fair enough. How are your JS skills? I ask because the AirPlay Enabler 
is still yet to see an inaugural release. Basically the QTE can be used as a 
model just remove the QuickTime bit and replace it with the AirPlay code 
(basically a context menu post request). Other major bottlenecks that remain 
are LLInt and V8. Feel free to contact me directly if any of these suit you and 
you need further info.

Original comment by spm...@gmail.com on 23 Oct 2012 at 5:25

[GoogleCodeExporter]

As for llvm-gcc please see comment 14.

Original comment by Tobias.N...@gmail.com on 23 Oct 2012 at 5:52

[GoogleCodeExporter]

When switching on objc-direct-dispatch in gcc 4.6 and later the linker will 
find the undefined symbols _objc_msgSend_Fast and maybe _objc_assign_ivar_Fast 
(when objc-gc is turned on). The attached piece of assembly provides those 
symbols. They are really just local branches to fixed addresses (in the comm 
page). In Apple's gcc those branch instructions directly replaced those 
function calls. So providing those symbols this way you get an overhead of one 
additional branch compared to Apple's original implementation. I also wonder if 
direct dispatching is really worth much (at least in 10.5 - I don't know 
whether it's the same in 10.4), as from what I saw by stepping through the 
instructions using gdb you only save a couple of instructions (inside dyld) by 
using direct dispatching.

Original comment by Tobias.N...@gmail.com on 28 Nov 2012 at 9:22

Attachments:

• objc_msgSend_Fast.s

[GoogleCodeExporter]

There's actually a very nice way of getting the missing direct dispatch 
function automatically linked in. You just have to add the object file 
(resulting from the assembler code posted before) to the static libgcc the 
compiler uses. In the case of MacPorts gcc 4.7 the static libgcc is installed 
in "/opt/local/lib/gcc47/gcc/ppc-apple-darwin9/4.7.2/libgcc.a".
Using a command similar to "ar -r -s libgcc.a objc_msgSend_Fast.o" you'll get 
that object file added and automatically used by gcc to satisfy the missing 
symbols during linking.

Original comment by Tobias.N...@gmail.com on 30 Nov 2012 at 12:30

[GoogleCodeExporter]

Well, to actually activate the faster dispatching you have to add 
"-fobjc-direct-dispatch" to the OS_COMPILE_CM(M)FLAGS and HOST_CM(M)FLAGS in 
"config/config.mk" and "js/src/config/config.mk"

Original comment by Tobias.N...@gmail.com on 30 Nov 2012 at 12:33

[GoogleCodeExporter]

Aurora 19 built with direct dispatching is stable.

Original comment by Tobias.N...@gmail.com on 30 Nov 2012 at 5:45

[GoogleCodeExporter]

I'm going to hold off on that until we see what the other builders are doing. 
fangism is still trucking on the Fink port and it would be nice if it could be 
built with the Fink gcc or the MacPorts gcc even though I will still make the 
gcc 4.6.3 and bintools I am using available. This way it's still a little more 
portable even though I agree dispatching is desirable.

After some cussing and hacking on the configure scripts, gcc 4.6.3 links and 
built JavaScript, and all tests pass, so I'm going to let it spin overnight and 
see how far it gets.

Original comment by classi...@floodgap.com on 3 Dec 2012 at 5:35

• Changed state: Started

[GoogleCodeExporter]

I think I'll file my suggestion in a bug to the gcc developers. Maybe they'll 
include it in their standard libgcc - maybe even for the next gcc4.6, if 
there'll be an update at all.

Original comment by Tobias.N...@gmail.com on 3 Dec 2012 at 10:08

[GoogleCodeExporter]

XPCOM does not want to build. While jsapi.h built with no comments as JS, I get

In file included from ../../dist/include/xptcall.h:21:0,
                 from /Volumes/BruceDeuce/src/mozilla-19a/xpcom/build/../glue/nsXPTCUtils.h:8,
                 from ../../dist/include/mozilla/XPCOM.h:177,
                 from /Volumes/BruceDeuce/src/mozilla-19a/xpcom/build/nsXPComInit.cpp:9:
../../dist/include/jsapi.h:927:70: error: template argument 1 is invalid
../../dist/include/jsapi.h:927:72: error: expected '{' before '>' token
../../dist/include/jsapi.h:927:72: error: expected unqualified-id before '>' 
token
In file included from ../../dist/include/jsapi.h:28:0,
                 from ../../dist/include/xptcall.h:21,
                 from /Volumes/BruceDeuce/src/mozilla-19a/xpcom/build/../glue/nsXPTCUtils.h:8,
                 from ../../dist/include/mozilla/XPCOM.h:177,
                 from /Volumes/BruceDeuce/src/mozilla-19a/xpcom/build/nsXPComInit.cpp:9:
../../dist/include/gc/Root.h: In instantiation of 'JS::Handle<JS::Value>':
../../dist/include/jsapi.h:1386:37:   instantiated from here
../../dist/include/gc/Root.h:112:7: error: invalid use of incomplete type 
'class js::HandleBase<JS::Value>'
../../dist/include/jsapi.h:927:7: error: declaration of 'class 
js::HandleBase<JS::Value>'

Before I go trying to hack this and make a bigger mess, did you have to do 
anything? What compiler options are enabled? I have

export CC="/opt/gcc46/bin/gcc -flax-vector-conversions"
export CXX="/opt/gcc46/bin/g++ -flax-vector-conversions -fpermissive"
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff-dbg
mk_add_options MOZ_MAKE_FLAGS="-s -j2"
mk_add_options AUTOCONF=autoconf213
etc.

Original comment by classi...@floodgap.com on 3 Dec 2012 at 4:50

[GoogleCodeExporter]

I already responded by E-Mail but apparently it didn't work.

My mozconfigs look like this:
export CC="/opt/local/bin/gcc-mp-4.7 -mcpu=7400 -mtune=G5"
export CXX="/opt/local/bin/g++-mp-4.7 -mcpu=7400 -mtune=G5"
ac_add_options --disable-tests
ac_add_options --enable-optimize
ac_add_options --target=powerpc-apple-darwin9
ac_add_options --enable-macos-target=10.5
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk
ac_add_options --enable-debug-symbols=-gdwarf-2
ac_add_options --with-system-jpeg
ac_add_options --enable-jemalloc
ac_add_options --enable-shared-js
ac_add_options --enable-gstreamer

I don't need "lax-vector-conversions" anymore since I "corrected" those parts. 
I only have "permissive" set in the accessibility Makefile.

I had a problem with jsapi.h when I switched from gcc 4.6 to 4.7 . But as I did 
that switch at the same as switching to a new Aurora version I don't know 
whether this was because of the mozilla sources or because of the compiler 
switch.
But it seems to be exactly your problem:

diff -r 3783afecd20a js/src/jsapi.h
--- a/js/src/jsapi.h    Wed Oct 10 19:52:08 2012 +0200
+++ b/js/src/jsapi.h    Mon Oct 22 21:54:19 2012 +0200
@@ -916,11 +916,11 @@
 * and value-extracting operations.
 */
template <>
-class HandleBase<JS::Value> : public ValueOperations<Handle<JS::Value> >
+class HandleBase<JS::Value> : public ValueOperations<JS::Handle<JS::Value> >
{
-    friend class ValueOperations<Handle<JS::Value> >;
+    friend class ValueOperations<JS::Handle<JS::Value> >;
    const JS::Value * extract() const {
-        return static_cast<const Handle<JS::Value>*>(this)->address();
+        return static_cast<const JS::Handle<JS::Value>*>(this)->address();
    }
};

The original patch is included in "fixes_for_building_with_gcc-4.7.patch" in 
the AuroraFox changesets.

Original comment by Tobias.N...@gmail.com on 3 Dec 2012 at 6:06