Adriaan van Os wrote:
You were quite right about -fPIC. All the failures, except emil9.pas disappear with -fno-pic. However, many of the other tests fail with -fno-pic, because the option disables dynamic linking on Mac OS X. The PPC back-end has a workaround (-mdynamic-no-pic) but that doesn't seem to work for i686-apple-darwin.
I have just realized that Darwin PIC problem have nothing to do with Linux PIC problems: Darwin does not use the binutils feature (ELF GOT relocations) that Linux uses.
Updating the linker and assembler to odcctools-20050327 had no effect on testsuite results.
So, I must either
- find a backport of i686-apple-darwin PIC fixes
- find a solution for gcc-3.4 bootstrap problems
- wait for gcc-4.0 support.
Still, I am glad with the results so far.
Well, I was able build 3.3.6 based cross-compiler for i686-apple-darwin target, and I can see duplicate labels in the assembler output. It seems that 3.4.3 has changed the parts responsible for generating those labels. I have found that 3.4.[34] contain blatant bug with easy fix:
--- gcc-3.4.4/gcc/config/i386/darwin.h.orig Thu Jun 16 01:10:29 2005 +++ gcc-3.4.4/gcc/config/i386/darwin.h Thu Jun 16 01:10:32 2005 @@ -43,7 +43,7 @@
/* Use the following macro for any Darwin/x86-specific command-line option translation. */ -#define SUBTARGET_OPTION_TRANSLATE_TABLE +#define SUBTARGET_OPTION_TRANSLATE_TABLE { 0, 0 }
#define ASM_SPEC "-arch i386 \ %{Zforce_cpusubtype_ALL:-force_cpusubtype_ALL} \
After that I can build the compiler proper. However I get ICE when building gcc runtime. Trying gpc on knuth3.pas (to get assembler output) give me ICE. Both ICE-s seem related to generting labels needed in PIC code...
So, it seems that nobody tried gcc-3.4.x for i686-darwin for almost a year (ChangeLog entry for SUBTARGET_OPTION_TRANSLATE_TABLE change is from 2004-08-23)
Waldek Hebisch wrote:
Well, I was able build 3.3.6 based cross-compiler for i686-apple-darwin target, and I can see duplicate labels in the assembler output. It seems that 3.4.3 has changed the parts responsible for generating those labels. I have found that 3.4.[34] contain blatant bug with easy fix:
--- gcc-3.4.4/gcc/config/i386/darwin.h.orig Thu Jun 16 01:10:29 2005 +++ gcc-3.4.4/gcc/config/i386/darwin.h Thu Jun 16 01:10:32 2005 @@ -43,7 +43,7 @@
/* Use the following macro for any Darwin/x86-specific command-line option translation. */ -#define SUBTARGET_OPTION_TRANSLATE_TABLE +#define SUBTARGET_OPTION_TRANSLATE_TABLE { 0, 0 }
#define ASM_SPEC "-arch i386 \ %{Zforce_cpusubtype_ALL:-force_cpusubtype_ALL} \
Thanks for looking into this and for the patch. I had already been staring at the #define SUBTARGET_OPTION_TRANSLATE_TABLE.
After that I can build the compiler proper. However I get ICE when building gcc runtime. Trying gpc on knuth3.pas (to get assembler output) give me ICE. Both ICE-s seem related to generting labels needed in PIC code...
Is this related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16649 ? I also found http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16557. I will try the patches included with those bug reports.
So, it seems that nobody tried gcc-3.4.x for i686-darwin for almost a year (ChangeLog entry for SUBTARGET_OPTION_TRANSLATE_TABLE change is from 2004-08-23)
Lars Sonchocky-Helldorf of the GNUStep project tried (I contacted him) and he reported some bugs.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Waldek Hebisch wrote:
After that I can build the compiler proper. However I get ICE when building gcc runtime. Trying gpc on knuth3.pas (to get assembler output) give me ICE. Both ICE-s seem related to generting labels needed in PIC code...
Is this related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16649 ? I also found http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16557. I will try the patches included with those bug reports.
Yes, it is bug 16649. The following patch extracted from the bug report eliminated ICE. I still get duplicate labels, but I had to skip one hunk which did not apply:
--- ./config/i386/i386.c.orig Wed Mar 16 16:23:40 2005 +++ ./config/i386/i386.c Thu Jun 16 13:33:02 2005 @@ -5810,6 +5810,28 @@
return term; } + +/* Allow {LABEL | SYMBOL}_REF - SYMBOL_REF-FOR-PICBASE for Mach-O as + this is used for to form addresses to local data when -fPIC is in + use. */ + +static bool +darwin_local_data_pic (rtx disp) +{ + if (GET_CODE (disp) == MINUS) + { + if (GET_CODE (XEXP (disp, 0)) == LABEL_REF + || GET_CODE (XEXP (disp, 0)) == SYMBOL_REF) + if (GET_CODE (XEXP (disp, 1)) == SYMBOL_REF) + { + const char *sym_name = XSTR (XEXP (disp, 1), 0); + if (! strcmp (sym_name, "<pic base>")) + return true; + } + } + + return false; +} /* Determine if a given RTX is a valid constant. We already know this satisfies CONSTANT_P. */ @@ -5829,6 +5851,9 @@ x = XEXP (x, 0); }
+ if (TARGET_MACHO && darwin_local_data_pic (x)) + return true; + /* Only some unspecs are valid as "constants". */ if (GET_CODE (x) == UNSPEC) switch (XINT (x, 1)) @@ -5980,18 +6005,8 @@ saw_plus = true; }
- /* Allow {LABEL | SYMBOL}_REF - SYMBOL_REF-FOR-PICBASE for Mach-O. */ - if (TARGET_MACHO && GET_CODE (disp) == MINUS) - { - if (GET_CODE (XEXP (disp, 0)) == LABEL_REF - || GET_CODE (XEXP (disp, 0)) == SYMBOL_REF) - if (GET_CODE (XEXP (disp, 1)) == SYMBOL_REF) - { - const char *sym_name = XSTR (XEXP (disp, 1), 0); - if (! strcmp (sym_name, "<pic base>")) - return 1; - } - } + if (TARGET_MACHO && darwin_local_data_pic (disp)) + return 1;
if (GET_CODE (disp) != UNSPEC) return 0;
Waldek Hebisch wrote:
Adriaan van Os wrote:
Waldek Hebisch wrote:
After that I can build the compiler proper. However I get ICE when building gcc runtime. Trying gpc on knuth3.pas (to get assembler output) give me ICE. Both ICE-s seem related to generting labels needed in PIC code...
Is this related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16649 ? I also found http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16557. I will try the patches included with those bug reports.
Yes, it is bug 16649. The following patch extracted from the bug report eliminated ICE. I still get duplicate labels, but I had to skip one hunk which did not apply:
I looks like the missing pieces of the puzzle can be found here http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg01139.html.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Waldek Hebisch wrote:
Yes, it is bug 16649. The following patch extracted from the bug report eliminated ICE. I still get duplicate labels, but I had to skip one hunk which did not apply:
I looks like the missing pieces of the puzzle can be found here http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg01139.html.
As I wrote in the other message, 4.0 still has the same problem. So the above patch is of little help. On the other hand it makes substantial changes to PPC Darwin, which may be dangerous alone (the patch is to 4.0 branch).
I can reproduce the problem with a C program, so I reported it to backend folks:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22099
Waldek Hebisch wrote:
Adriaan van Os wrote:
Waldek Hebisch wrote:
Yes, it is bug 16649. The following patch extracted from the bug report eliminated ICE. I still get duplicate labels, but I had to skip one hunk which did not apply:
I looks like the missing pieces of the puzzle can be found here http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg01139.html.
As I wrote in the other message, 4.0 still has the same problem. So the above patch is of little help. On the other hand it makes substantial changes to PPC Darwin, which may be dangerous alone (the patch is to 4.0 branch).
Yes, you are right (I wrote it before reading your message about the test with gcc-4.0).
I can reproduce the problem with a C program, so I reported it to backend folks:
Thanks for reporting it !
For your information - the bootstrap of gcc-3.4.3 with gpc-20050331 now worked.
Regards,
Adriaan van Os
Waldek Hebisch wrote:
Adriaan van Os wrote:
Waldek Hebisch wrote:
Yes, it is bug 16649. The following patch extracted from the bug report eliminated ICE. I still get duplicate labels, but I had to skip one hunk which did not apply:
I looks like the missing pieces of the puzzle can be found here http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg01139.html.
As I wrote in the other message, 4.0 still has the same problem. So the above patch is of little help. On the other hand it makes substantial changes to PPC Darwin, which may be dangerous alone (the patch is to 4.0 branch).
I can reproduce the problem with a C program, so I reported it to backend folks:
It looks like the Apple gcc back-end folks now finally woke up http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02158.html.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Waldek Hebisch wrote:
Adriaan van Os wrote:
Waldek Hebisch wrote:
Yes, it is bug 16649. The following patch extracted from the bug report eliminated ICE. I still get duplicate labels, but I had to skip one hunk which did not apply:
I looks like the missing pieces of the puzzle can be found here http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg01139.html.
As I wrote in the other message, 4.0 still has the same problem. So the above patch is of little help. On the other hand it makes substantial changes to PPC Darwin, which may be dangerous alone (the patch is to 4.0 branch).
I can reproduce the problem with a C program, so I reported it to backend folks:
It looks like the Apple gcc back-end folks now finally woke up http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02158.html.
Yes, a quick hack to gcc-3.4.4 (included as a separate file), together with the below patch (my apologies), solves the remaining compiler problems for position independent code on i686-apple-darwin
--- gpc-options.h.orig Sat Nov 12 13:29:38 2005 +++ gpc-options.h Fri Dec 2 12:56:51 2005 @@ -85,10 +85,8 @@ "-fno-pedantic", "-ftyped-address", "-fassertions", -#ifdef TARGET_POWERPC #if TARGET_MACHO "-flongjmp-all-nonlocal-labels", -#endif #endif "-Wwarnings", "-Wimplicit-abstract",
[Darwin:gcc/p/test] adriaan% make rm -f *.dat *.o *.s *.i *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.i todo/*.gpi todo/*.gpd todo/core GP= PC="gpc" PFLAGS=" --autobuild -g -O3 -W -Wall -Wno-unused " PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | tee test_log | "./test_sum" -d Test Run By adriaan on 2005-12-02 12:18:53 Native configuration is i686-apple-darwin8 (Darwin.local)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas UNSUPPORTED: fjf165a.pas UNSUPPORTED: gmptest.pas FAIL: systemtest.pas
=== gpc Summary ===
# of tests 4965 # of expected passes 4959 # of unexpected failures 1 # of unsupported tests 5
gpc version 20051104, based on gcc-3.4.4
Regards,
Adriaan van Os
Adriaan van Os wrote:
It looks like the Apple gcc back-end folks now finally woke up http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02158.html.
Yes, a quick hack to gcc-3.4.4 (included as a separate file), together with the below patch (my apologies), solves the remaining compiler problems for position independent code on i686-apple-darwin
Still, another problem, -Os is broken on i686-apple-darwin, but the following patch (taken from http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01656.html) fixes it.
--- gcc-3.4.5/gcc/config/i386/i386.c.orig 2005-12-22 10:49:44.000000000 +0100 +++ gcc-3.4.5/gcc/config/i386/i386.c 2005-12-22 09:16:54.000000000 +0100 @@ -1357,9 +1357,8 @@ The default of 128 bits is for Pentium III's SSE __m128, but we don't want additional code to keep the stack aligned when optimizing for code size. */ - ix86_preferred_stack_boundary = (optimize_size - ? TARGET_64BIT ? 128 : 32 - : 128); + ix86_preferred_stack_boundary = ((TARGET_64BIT || TARGET_MACHO || !optimize_size) + ? 128 : 32); if (ix86_preferred_stack_boundary_string) { i = atoi (ix86_preferred_stack_boundary_string);
That was the last one (I hope).
Regards,
Adriaan van Os
Adriaan van Os wrote:
Waldek Hebisch wrote:
Adriaan van Os wrote:
Waldek Hebisch wrote:
Yes, it is bug 16649. The following patch extracted from the bug report eliminated ICE. I still get duplicate labels, but I had to skip one hunk which did not apply:
I looks like the missing pieces of the puzzle can be found here http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg01139.html.
As I wrote in the other message, 4.0 still has the same problem. So the above patch is of little help. On the other hand it makes substantial changes to PPC Darwin, which may be dangerous alone (the patch is to 4.0 branch).
I can reproduce the problem with a C program, so I reported it to backend folks:
It looks like the Apple gcc back-end folks now finally woke up http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02158.html.
Yes, a quick hack to gcc-3.4.4 (included as a separate file), together with the below patch (my apologies), solves the remaining compiler problems for position independent code on i686-apple-darwin
Fixed now in the gcc sources for gcc-4.2.0 and above, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22099.
Regards,
Adriaan van Os
-
Adriaan van Os -
Waldek Hebisch