I have put a new gpc snapshot at:
http://www.math.uni.wroc.pl/~hebisch/gpc-20070904.tar.bz2
This snaphshot contains mostly bugfixes. Main feature is that gcc-4.1.x support is now integrated.
NOTE: there is a change of licence: this snapshot uses GPL version 3.
For new features see:
http://www.math.uni.wroc.pl/~hebisch/gpc/NEWS-20070904
and for fixed bugs:
http://www.math.uni.wroc.pl/~hebisch/gpc/Fixed-20070904
In message E1ISSLp-0005n3-00@hera.math.uni.wroc.pl, Waldek Hebisch hebisch@math.uni.wroc.pl writes
I have put a new gpc snapshot at:
Waldek
Thank you for your efforts.
Waldek Hebisch wrote:
I have put a new gpc snapshot at:
http://www.math.uni.wroc.pl/~hebisch/gpc-20070904.tar.bz2
This snaphshot contains mostly bugfixes. Main feature is that gcc-4.1.x support is now integrated.
Thanks for the snapshot !
NOTE: there is a change of licence: this snapshot uses GPL version 3.
For new features see:
http://www.math.uni.wroc.pl/~hebisch/gpc/NEWS-20070904
and for fixed bugs:
On darwin-i386, additional patches are needed to fix problems in the gcc-back-end. See the attached diff for gcc-4.1.2.
The snapshot builds without problems on i386-darwin with gcc-4.1.2.
[p17:~/gpc/gpc-20070904/gcc-4.1.2-test] adriaan% gpc -v Using built-in specs. Configured with: ../gcc-4.1.2/configure --enable-languages=pascal,c --enable-threads=posix --target=i386-apple-darwin8 --host=i386-apple-darwin8 --build=i386-apple-darwin8 --prefix=/Developer/Pascal/gpc412d1 --with-arch=pentium-m --with-tune=prescott Thread model: posix gpc version 20070904, based on gcc-4.1.2
The testsuite results are as follows:
[p17:~/gpc/gpc-20070904/gcc-4.1.2-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 2007-09-04 16:14:45 Native configuration is i386-apple-darwin8 (p17)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas FAIL: fjf1102.pas UNSUPPORTED: fjf165a.pas FAIL: fjf322.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf587b.pas UNSUPPORTED: gmptest.pas FAIL: prep2p.pas FAIL: systemtest.pas
=== gpc Summary ===
# of tests 5111 # of expected passes 5099 # of unexpected failures 7 # of unsupported tests 5
gpc version 20070904, based on gcc-4.1.2
When compared to http://www.gnu-pascal.de/crystal/gpc/en/mail13558.html?pos=41521099#41521099 this fixes
FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: fjf998r.pas FAIL: nicola4c.pas
Regards,
Adriaan van Os
On Sep 4, 2007, at 8:09 AM, Adriaan van Os wrote:
Waldek Hebisch wrote:
I have put a new gpc snapshot at: http://www.math.uni.wroc.pl/~hebisch/gpc-20070904.tar.bz2 This snaphshot contains mostly bugfixes. Main feature is that gcc-4.1.x support is now integrated.
[snip]
On darwin-i386, additional patches are needed to fix problems in the gcc-back-end. See the attached diff for gcc-4.1.2.
The snapshot builds without problems on i386-darwin with gcc-4.1.2.
Using Adriaan's attached diff for the additional patching, the snapshot also builds without problems on powerpc-apple-darwin8 with gcc-4.1.2.
gale-paepers-power-mac-g5:~/GPC_Build/GPCBuild412 grp$ gpc -v Using built-in specs. Configured with: ../gcc-4.1.2/configure --enable-languages=pascal,c -- enable-threads=posix --target=powerpc-apple-darwin8 --host=powerpc- apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/ Pascal/gpc412d1 Thread model: posix gpc version 20070904, based on gcc-4.1.2
The testsuite results are as follows:
The powerpc-apple-darwin8 testsuite results were similar to the results Adriaan got with his i386-darwin build with the exception of two additional unsupported tests and one additional test failure:
gale-paepers-power-mac-g5:~/GPC_Build/gpc-20070904/p/test grp$ 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 grp on 2007-09-05 12:59:04 Native configuration is powerpc-apple-darwin8 (gale-paepers-power-mac- g5.local)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas UNSUPPORTED: asmtest.pas FAIL: fjf1102.pas UNSUPPORTED: fjf165a.pas FAIL: fjf322.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf998r.pas UNSUPPORTED: gmptest.pas UNSUPPORTED: longr2.pas FAIL: prep2p.pas FAIL: systemtest.pas
=== gpc Summary ===
# of tests 5111 # of expected passes 5096 # of unexpected failures 8 # of unsupported tests 7
gpc version 20070904, based on gcc-4.1.2
When compared to <http://www.gnu-pascal.de/crystal/gpc/en/ mail13558.html?pos=41521099#41521099> this fixes
[snip]
FAIL: fjf998r.pas
That test is still failing with a powerpc-apple-darwin8 build.
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
Using Adriaan's attached diff for the additional patching, the snapshot also builds without problems on powerpc-apple-darwin8 with gcc-4.1.2.
Interestingly, thanks to the PowerPC emulator built-into Mac OS X on Intel Macs, we can also test the PowerPC cross-compiler hosted there.
[p17:~/gpc/gpc-20070904/gcc-4.1.2-test] adriaan% uname -a Darwin p17 8.6.2 Darwin Kernel Version 8.6.2: Thu Apr 13 18:48:29 PDT 2006; root:xnu-792.9.59.obj~1/RELEASE_I386 i386 i386
/Developer/Pascal/gpc421d1/bin/powerpc-apple-darwin8-gpc version 20070904, based on gcc-4.1.2 [p17:~/gpc/gpc-20070904/gcc-4.1.2-test] adriaan% /Developer/Pascal/gpc421d1/bin/powerpc-apple-darwin8-gpc -v Using built-in specs. Configured with: ../gcc-4.1.2/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin8 --host=i386-apple-darwin8 --build=i386-apple-darwin8 --prefix=/Developer/Pascal/gpc421d1 --with-ld=/usr/bin/ld --with-as=/usr/bin/as Thread model: posix gpc version 20070904, based on gcc-4.1.2
[p17:~/gpc/gpc-20070904/gcc-4.1.2-test] adriaan% make PC=/Developer/Pascal/gpc421d1/bin/powerpc-apple-darwin8-gpc 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="/Developer/Pascal/gpc421d1/bin/powerpc-apple-darwin8-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 2007-09-06 10:54:21 Native configuration is powerpc-apple-darwin8 (p17)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas FAIL: asmtest.pas FAIL: fjf1102.pas UNSUPPORTED: fjf165a.pas FAIL: fjf322.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf998r.pas UNSUPPORTED: gmptest.pas FAIL: gpcutiltest.pas UNSUPPORTED: longr2.pas FAIL: prep2p.pas FAIL: systemtest.pas
=== gpc Summary ===
# of tests 5111 # of expected passes 5095 # of unexpected failures 10 # of unsupported tests 6
Apparently, asmtest.pas and gpcutiltest.pas are getting confused by this setup.
FAIL: asmtest.pas ./asmtest.pas: In procedure `I_am_happy_because': ./asmtest.pas:50: error: impossible constraint in 'asm' failed
FAIL: gpcutiltest.pas Error in Str2Real #2
Regards,
Adriaan van Os
Adriaan van Os wrote:
Interestingly, thanks to the PowerPC emulator built-into Mac OS X on Intel Macs, we can also test the PowerPC cross-compiler hosted there.
[p17:~/gpc/gpc-20070904/gcc-4.1.2-test] adriaan% uname -a Darwin p17 8.6.2 Darwin Kernel Version 8.6.2: Thu Apr 13 18:48:29 PDT 2006; root:xnu-792.9.59.obj~1/RELEASE_I386 i386 i386
/Developer/Pascal/gpc421d1/bin/powerpc-apple-darwin8-gpc version 20070904, based on gcc-4.1.2 [p17:~/gpc/gpc-20070904/gcc-4.1.2-test] adriaan% /Developer/Pascal/gpc421d1/bin/powerpc-apple-darwin8-gpc -v Using built-in specs. Configured with: ../gcc-4.1.2/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin8 --host=i386-apple-darwin8 --build=i386-apple-darwin8 --prefix=/Developer/Pascal/gpc421d1 --with-ld=/usr/bin/ld --with-as=/usr/bin/as
I was less successful building the "other" cross-compiler using
configure --enable-languages=pascal --enable-threads=posix --target=i386-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc412n --with-sysroot=/Developer/SDKs/MacOSX10.4u.sdk/ --with-arch=pentium-m --with-tune=prescott --with-ld=/usr/bin/ld --with-as=/usr/bin/as
The make stops with the following error message ../.././xgpc -B../.././ -c -g -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/Users/peterschorn/projects/gpc4/gcc-4.1.2/gcc/p/rts --automake -DRTS_RELEASE_STRING="'`cat /Users/peterschorn/projects/gpc4/gcc-4.1.2/gcc/p/rts/rts-version`'" -DGCC_VERSION="''" "/Users/peterschorn/projects/gpc4/gcc-4.1.2/gcc/p/rts/rtsc.pas" /Users/peterschorn/projects/gpc4/gcc-4.1.2/gcc/p/rts/rtsc.pas:430: internal compiler error: in store_node_fields, at p/module.c:2372 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. make[3]: *** [rtsc.o] Error 1 make[2]: *** [pascal.rts] Error 2 make[1]: *** [all-gcc] Error 2 make: *** [all] Error 2
Am I using some wrong parameters in the configure parameters or am I missing something else?
Best regards, Peter
Peter Schorn wrote:
Adriaan van Os wrote:
I was less successful building the "other" cross-compiler using
configure --enable-languages=pascal --enable-threads=posix --target=i386-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc412n --with-sysroot=/Developer/SDKs/MacOSX10.4u.sdk/ --with-arch=pentium-m --with-tune=prescott --with-ld=/usr/bin/ld --with-as=/usr/bin/as
The make stops with the following error message ../.././xgpc -B../.././ -c -g -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/Users/peterschorn/projects/gpc4/gcc-4.1.2/gcc/p/rts --automake -DRTS_RELEASE_STRING="'`cat /Users/peterschorn/projects/gpc4/gcc-4.1.2/gcc/p/rts/rts-version`'" -DGCC_VERSION="''" "/Users/peterschorn/projects/gpc4/gcc-4.1.2/gcc/p/rts/rtsc.pas" /Users/peterschorn/projects/gpc4/gcc-4.1.2/gcc/p/rts/rtsc.pas:430: internal compiler error: in store_node_fields, at p/module.c:2372 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. make[3]: *** [rtsc.o] Error 1 make[2]: *** [pascal.rts] Error 2 make[1]: *** [all-gcc] Error 2 make: *** [all] Error 2
Am I using some wrong parameters in the configure parameters or am I missing something else?
Looks like a compiler bug, not a build or configuration error on your side. Hoewever, it may help (or not) to use the C compiler that was built with the native Pascal compiler. Try to add CC=/Developer/Pascal/gpc412n/bin/gcc to the make command.
Regards,
Adriaan van Os
On Sep 6, 2007, at 3:32 PM, Adriaan van Os wrote:
Peter Schorn wrote:
Adriaan van Os wrote: I was less successful building the "other" cross-compiler using configure --enable-languages=pascal --enable-threads=posix -- target=i386-apple-darwin8 --host=powerpc-apple-darwin8 -- build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc412n -- with-sysroot=/Developer/SDKs/MacOSX10.4u.sdk/ --with-arch=pentium- m --with-tune=prescott --with-ld=/usr/bin/ld --with-as=/usr/bin/as The make stops with the following error message ../.././xgpc -B../.././ -c -g -I. -W -Wall -Wmissing-prototypes - Wmissing-declarations -g -O2 --unit-path=/Users/peterschorn/ projects/gpc4/gcc-4.1.2/gcc/p/rts --automake - DRTS_RELEASE_STRING="'`cat /Users/peterschorn/projects/gpc4/ gcc-4.1.2/gcc/p/rts/rts-version`'" -DGCC_VERSION="''" "/Users/ peterschorn/projects/gpc4/gcc-4.1.2/gcc/p/rts/rtsc.pas" /Users/peterschorn/projects/gpc4/gcc-4.1.2/gcc/p/rts/rtsc.pas:430: internal compiler error: in store_node_fields, at p/module.c:2372 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. make[3]: *** [rtsc.o] Error 1 make[2]: *** [pascal.rts] Error 2 make[1]: *** [all-gcc] Error 2 make: *** [all] Error 2 Am I using some wrong parameters in the configure parameters or am I missing something else?
Looks like a compiler bug, not a build or configuration error on your side. Hoewever, it may help (or not) to use the C compiler that was built with the native Pascal compiler. Try to add CC=/ Developer/Pascal/gpc412n/bin/gcc to the make command.
No joy, Adriaan.
Using the following modified lines from your build-on PPC command file:
cd build-cross ../gcc-4.1.2/configure --enable-languages=pascal,c --enable- threads=posix --target=i386-apple-darwin8 --host=powerpc-apple- darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/ gpc412d1 --with-sysroot=/Developer/SDKs/MacOSX10.4u.sdk/ --with- arch=pentium-m --with-tune=prescott --with-as=/usr/bin/as --with-ld=/ usr/bin/ld make RANLIB_FOR_TARGET=ranlib AR_FOR_TARGET=ar NM_FOR_TARGET=nm STRIP_FOR_TARGET=strip LIPO_FOR_TARGET=lipo CC=/Developer/Pascal/ gpc412d1/bin/gcc sudo make RANLIB_FOR_TARGET=ranlib AR_FOR_TARGET=ar NM_FOR_TARGET=nm STRIP_FOR_TARGET=strip LIPO_FOR_TARGET=lipo CC=/ Developer/Pascal/gpc412d1/bin/gcc install
I get pretty much the same error as Peter Schorn got in trying to build a PPC hosted i386 cross compiler:
/Users/grp/GPC_Build/GPCBuild412/build-cross/./gcc/xgcc -B/Users/grp/ GPC_Build/GPCBuild412/build-cross/./gcc/ -B/Developer/Pascal/gpc412d1/ i386-apple-darwin8/bin/ -B/Developer/Pascal/gpc412d1/i386-apple- darwin8/lib/ -isystem /Developer/Pascal/gpc412d1/i386-apple-darwin8/ include -isystem /Developer/Pascal/gpc412d1/i386-apple-darwin8/sys- include -c -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations - g -O2 -Wpointer-arith -Wwrite-strings "/Users/grp/GPC_Build/ GPCBuild412/gcc-4.1.2/gcc/p/rts/rts.c" ../.././xgpc -B../.././ -c -g -I. -W -Wall -Wmissing-prototypes - Wmissing-declarations -g -O2 --unit-path=/Users/grp/GPC_Build/ GPCBuild412/gcc-4.1.2/gcc/p/rts --automake - DRTS_RELEASE_STRING="'`cat /Users/grp/GPC_Build/GPCBuild412/gcc-4.1.2/ gcc/p/rts/rts-version`'" -DGCC_VERSION="''" "/Users/grp/GPC_Build/ GPCBuild412/gcc-4.1.2/gcc/p/rts/rtsc.pas" /Users/grp/GPC_Build/GPCBuild412/gcc-4.1.2/gcc/p/rts/rtsc.pas:430: internal compiler error: in store_node_fields, at p/module.c:2372 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. make[3]: *** [rtsc.o] Error 1 make[2]: *** [pascal.rts] Error 2 make[1]: *** [all-gcc] Error 2 make: *** [all] Error 2
In looking over all the compile commands output, it doesn't look like the "CC=/Developer/Pascal/gpc412d1/bin/gcc" parameter ends up forcing that gcc to be used for all the compiling in building xgcc and xgpc. For the boatload of compile commands, there doesn't seem to be any rhyme or reason as to which C compiler is used. Sometimes, it is:
gcc -c ...
other times, it is:
/Developer/Pascal/gpc412d1/bin/gcc -c ...
If I've got the right compile line, module.c where the internal compiler error is coming from was compiled with Apple's gcc and not the /Developer/Pascal/gpc412d1/bin/gcc that was just build. The complete compile line:
gcc -o p/module.o -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings - Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -Ip - I../../gcc-4.1.2/gcc -I../../gcc-4.1.2/gcc/p -I../../gcc-4.1.2/gcc/../ include -I./../intl -I../../gcc-4.1.2/gcc/../libcpp/include -W - Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes - pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition - Wmissing-format-attribute -Wno-traditional -I. -Ip -I../../gcc-4.1.2/ gcc -I../../gcc-4.1.2/gcc/p -I../../gcc-4.1.2/gcc/../include -I./../ intl -I../../gcc-4.1.2/gcc/../libcpp/include -DGPC -DGPC_UNITS_DIR= "/Developer/Pascal/gpc412d1/lib/gcc/i386-apple-darwin8/4.1.2/units" -I../../gcc-4.1.2/gcc/p -DTARGET_NAME="i386-apple-darwin8" ../../ gcc-4.1.2/gcc/p/module.c
If it would help in figuring out what the problem is, I've saved to a file all the command output generated from the start to the end where the make error occurs. It is about 500K so it is too large to attach to this posting, but if it would help, I can send it in private e-mail.
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
In looking over all the compile commands output, it doesn't look like the "CC=/Developer/Pascal/gpc412d1/bin/gcc" parameter ends up forcing that gcc to be used for all the compiling in building xgcc and xgpc. For the boatload of compile commands, there doesn't seem to be any rhyme or reason as to which C compiler is used. Sometimes, it is:
gcc -c ...
other times, it is:
/Developer/Pascal/gpc412d1/bin/gcc -c ...
What if you do something like this
sudo mv /usr/bin/gcc /usr/bin/gcc-apple sudo ln -sf /Developer/Pascal/gpc412d1/bin/gcc /usr/bin/gcc
.. cross-compile build ..
sudo rm /usr/bin/gcc sudo mv /usr/bin/gcc-apple /usr/bin/gcc
Regards,
Adriaan van Os
On Sep 7, 2007, at 12:06 AM, Adriaan van Os wrote:
Gale Paeper wrote:
In looking over all the compile commands output, it doesn't look like the "CC=/Developer/Pascal/gpc412d1/bin/gcc" parameter ends up forcing that gcc to be used for all the compiling in building xgcc and xgpc. For the boatload of compile commands, there doesn't seem to be any rhyme or reason as to which C compiler is used. Sometimes, it is: gcc -c ... other times, it is: /Developer/Pascal/gpc412d1/bin/gcc -c ...
What if you do something like this
sudo mv /usr/bin/gcc /usr/bin/gcc-apple sudo ln -sf /Developer/Pascal/gpc412d1/bin/gcc /usr/bin/gcc
.. cross-compile build ..
sudo rm /usr/bin/gcc sudo mv /usr/bin/gcc-apple /usr/bin/gcc
That did it, Adriaan.
Doesn't seem quite right though to have to hack the system compiler to get the desired build compiler used.
I note that Apple's gcc installed with Xcode 2.4.1 Developer Tools is version 4.0.1 (Apple Computer, Inc. build 5367).
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
On Sep 7, 2007, at 12:06 AM, Adriaan van Os wrote:
Gale Paeper wrote:
In looking over all the compile commands output, it doesn't look like the "CC=/Developer/Pascal/gpc412d1/bin/gcc" parameter ends up forcing that gcc to be used for all the compiling in building xgcc and xgpc. For the boatload of compile commands, there doesn't seem to be any rhyme or reason as to which C compiler is used. Sometimes, it is: gcc -c ... other times, it is: /Developer/Pascal/gpc412d1/bin/gcc -c ...
What if you do something like this
sudo mv /usr/bin/gcc /usr/bin/gcc-apple sudo ln -sf /Developer/Pascal/gpc412d1/bin/gcc /usr/bin/gcc
.. cross-compile build ..
sudo rm /usr/bin/gcc sudo mv /usr/bin/gcc-apple /usr/bin/gcc
That did it, Adriaan.
Doesn't seem quite right though to have to hack the system compiler to get the desired build compiler used.
Maybe putting CC= ... in front of 'configure' does the job also.
Adriaan
On Sep 7, 2007, at 1:49 AM, Adriaan van Os wrote:
Gale Paeper wrote:
On Sep 7, 2007, at 12:06 AM, Adriaan van Os wrote:
Gale Paeper wrote:
In looking over all the compile commands output, it doesn't look like the "CC=/Developer/Pascal/gpc412d1/bin/gcc" parameter ends up forcing that gcc to be used for all the compiling in building xgcc and xgpc. For the boatload of compile commands, there doesn't seem to be any rhyme or reason as to which C compiler is used. Sometimes, it is: gcc -c ... other times, it is: /Developer/Pascal/gpc412d1/bin/gcc -c ...
What if you do something like this
sudo mv /usr/bin/gcc /usr/bin/gcc-apple sudo ln -sf /Developer/Pascal/gpc412d1/bin/gcc /usr/bin/gcc
.. cross-compile build ..
sudo rm /usr/bin/gcc sudo mv /usr/bin/gcc-apple /usr/bin/gcc
That did it, Adriaan. Doesn't seem quite right though to have to hack the system compiler to get the desired build compiler used.
Maybe putting CC= ... in front of 'configure' does the job also.
Since your Mac OS X build-on script command files are set up to run in a tcsh shell, you need to use the command form of:
setenv CC /Developer/Pascal/gpc412d1/bin/gcc
With that command just before the cross compiler configure command, the /Developer/Pascal/gpc412d1/bin/gcc compiler is always used in building the cross compiler and the build succeeds without error.
I'm not familiar with how a tcsh shell handles environment variables set in a shell command file so I'm not sure how benign that command actually is in a global, system wide context. As far as I can tell, the effect of setting of CC seems to go away when the tcsh shell process executing the shell command file terminates.
I note the gcc configuration documentation, <http://gcc.gnu.org/ install/configure.html>, states "setting cc in your environment" is one way to specify the c compiler to be used for compiling so it is probably the way to go to workaround the present PowerPC hosted cross compiler build error problem.
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
Maybe putting CC= ... in front of 'configure' does the job also.
Since your Mac OS X build-on script command files are set up to run in a tcsh shell, you need to use the command form of:
setenv CC /Developer/Pascal/gpc412d1/bin/gcc
With that command just before the cross compiler configure command, the /Developer/Pascal/gpc412d1/bin/gcc compiler is always used in building the cross compiler and the build succeeds without error.
I'm not familiar with how a tcsh shell handles environment variables set in a shell command file so I'm not sure how benign that command actually is in a global, system wide context. As far as I can tell, the effect of setting of CC seems to go away when the tcsh shell process executing the shell command file terminates.
I note the gcc configuration documentation, http://gcc.gnu.org/install/configure.html, states "setting cc in your environment" is one way to specify the c compiler to be used for compiling so it is probably the way to go to workaround the present PowerPC hosted cross compiler build error problem.
Yes, that seems to be the best way to work around the build/apple-gcc problem.
Regards,
Adriaan van Os
Will there be binaries or some easy way (e.g. through macports) of building them for Mac OS X? Maybe there are instructions somewhere (and how to apply the patches)?
Thanks!
Nestor Aguilera
=======================================================================
On 4 Sep, 2007, at 12:09, Adriaan van Os wrote:
Waldek Hebisch wrote:
I have put a new gpc snapshot at: http://www.math.uni.wroc.pl/~hebisch/gpc-20070904.tar.bz2 This snaphshot contains mostly bugfixes. Main feature is that gcc-4.1.x support is now integrated.
Thanks for the snapshot !
NOTE: there is a change of licence: this snapshot uses GPL version 3. For new features see: http://www.math.uni.wroc.pl/~hebisch/gpc/NEWS-20070904 and for fixed bugs: http://www.math.uni.wroc.pl/~hebisch/gpc/Fixed-20070904
On darwin-i386, additional patches are needed to fix problems in the gcc-back-end. See the attached diff for gcc-4.1.2.
The snapshot builds without problems on i386-darwin with gcc-4.1.2.
[...]
Nestor Aguilera wrote:
Will there be binaries or some easy way (e.g. through macports) of building them for Mac OS X? Maybe there are instructions somewhere (and how to apply the patches)?
Yes, Gale Paeper and I are working on updated compiler binaries for Mac OS X and also on a Finder-double-clickable build script.
Regards,
Adriaan van Os
On 6 Sep, 2007, at 11:26, Adriaan van Os wrote:
Nestor Aguilera wrote:
Will there be binaries or some easy way (e.g. through macports) of building them for Mac OS X? Maybe there are instructions somewhere (and how to apply the patches)?
Yes, Gale Paeper and I are working on updated compiler binaries for Mac OS X and also on a Finder-double-clickable build script.
Thank you very much to both of you!
Nestor Aguilera
Adriaan van Os wrote:
Waldek Hebisch wrote:
I have put a new gpc snapshot at:
http://www.math.uni.wroc.pl/~hebisch/gpc-20070904.tar.bz2
This snaphshot contains mostly bugfixes. Main feature is that gcc-4.1.x support is now integrated.
Thanks for the snapshot !
NOTE: there is a change of licence: this snapshot uses GPL version 3.
For new features see:
http://www.math.uni.wroc.pl/~hebisch/gpc/NEWS-20070904
and for fixed bugs:
On darwin-i386, additional patches are needed to fix problems in the gcc-back-end. See the attached diff for gcc-4.1.2.
The snapshot builds without problems on i386-darwin with gcc-4.1.2.
However, after patching the Pascal front-end, I ran into
../../gcc-4.1.2/gcc/p/script/keywords2texi ../../gcc-4.1.2/gcc/p/predef.def ../../gcc-4.1.2/gcc/p/doc/generated/keyword.texi cd ../../gcc-4.1.2/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="" SHELL="/bin/sh" CFLAGS="-g -O2 " PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" DESTDIR="../.." AR="ar" RANLIB="ranlib -c" RANLIB_TEST="" generated-files version=`cat ./rts-version`; cd .; ./make-gpc-pas $version > "gpc.pas" || { rm -f "gpc.pas"; false; } /bin/sh: line 1: ./make-gpc-pas: Permission denied make[3]: *** [gpc.pas] Error 1 make[2]: *** [../../gcc-4.1.2/gcc/p/rts/gpc.pas] Error 2 make[1]: *** [all-gcc] Error 2 make: *** [all] Error 2
This is solved by setting executable rights
[p17:gcc/p/rts] adriaan% chmod +x make-gpc-pas
Supposedly the same has to be done for make-acconfig-h.m4 and make-rtsc-pas.
Regards,
Adriaan van Os
Waldek Hebisch a écrit:
I have put a new gpc snapshot at:
http://www.math.uni.wroc.pl/~hebisch/gpc-20070904.tar.bz2
This snaphshot contains mostly bugfixes. Main feature is that gcc-4.1.x support is now integrated.
Very good. Compiled with gcc-4.1.2 under DJGPP it gives ---------------------------------------------------------------------- === gpc tests ===
Running target any Running testsuite ...
FAIL: fjf1102.pas UNSUPPORTED: fjf165a.pas FAIL: fjf322.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf587b.pas UNSUPPORTED: longr2.pas FAIL: y2k.pas
=== gpc Summary ===
# of tests 5111 # of expected passes 5103 # of unexpected failures 6 # of unsupported tests 2
c:/djgpp/b/gnu/build.gcc/gcc/xgpc version 20070904, based on gcc-4.1.2 ----------------------------------------------------------------------- In fact only 5 failures since y2k has no meaning as usual.
In detail
TEST fjf1102.pas: failed 000
TEST fjf322.pas: 'result_0.lengthc:/djgpp/b/gnu/gcc-4.12/gcc/p/test/fjf322.pas: In function `o': gpc1.exe: warnings being treated as errors c:/djgpp/b/gnu/gcc-4.12/gcc/p/test/fjf322.pas:8: warning: ' is used uninitialized in this function failed
TEST fjf403b.pas: failed: failed
TEST fjf563e.pas: failed: failed
TEST fjf587b.pas: 'concat_0._p_Schema_[3]{lb: 1 sz: 1}c:/djgpp/b/gnu/gcc-4.12/gcc/p/test/fjf587b.pas: In procedure `Foo': gpc1.exe: warnings being treated as errors c:/djgpp/b/gnu/gcc-4.12/gcc/p/test/fjf587b.pas:5: warning: ' is used uninitialized in this function failed
So good that I put it in the "good" directory, not the "experimental"
http://www.gnu-pascal.de/contrib/maurice/gpc-20070904-gcc-412.i586-pc-msdosd...
unless you don't agree ?
Maurice
Maurice Lombardi wrote:
=== gpc Summary ===# of tests 5111 # of expected passes 5103 # of unexpected failures 6 # of unsupported tests 2
c:/djgpp/b/gnu/build.gcc/gcc/xgpc version 20070904, based on gcc-4.1.2
In fact only 5 failures since y2k has no meaning as usual.
<snip>
So good that I put it in the "good" directory, not the "experimental"
http://www.gnu-pascal.de/contrib/maurice/gpc-20070904-gcc-412.i586-pc-msdosd...
unless you don't agree ?
Yes, I think we should not mark 4.1 based version as "experimental". There are some regressions compared to gpc based on 3.4.6 but they are minor.
Waldek Hebisch wrote:
Yes, I think we should not mark 4.1 based version as "experimental". There are some regressions compared to gpc based on 3.4.6 but they are minor.
The failure of prep2.pas on Mac OS X can lead to nasty problems in software that depends on the missing defines. So, for Darwin, I am checking in the following diff (although it may be wrong for cross-compilers)
diff -ur gcc-4.1.2-orig/gcc/p/gpcpp.c gcc-4.1.2/gcc/p/gpcpp.c --- gcc-4.1.2-orig/gcc/p/gpcpp.c 2007-09-04 08:22:53.000000000 +0200 +++ gcc-4.1.2/gcc/p/gpcpp.c 2007-09-18 10:36:57.000000000 +0200 @@ -1187,6 +1187,14 @@ strcat (strcpy (tmp_buf, "__GPC_RELEASE__="), GPC_VERSION_STRING); make_definition (tmp_buf, 1);
+#ifdef __APPLE__ + make_definition ("__APPLE__", 1); +#endif + +#ifdef __MACH__ + make_definition ("__MACH__", 1); +#endif + /* Now handle the command line options. */ /* Do -U's and -D's in the order they were seen. */ for (i = 1; i < argc; i++)
I can't speak for the other platforms. From http://www.gnu-pascal.de/crystal/gpc/en/mail14109.html it looks like prep2.pas didn't fail on DJGPP ?
Regards,
Adriaan van Os
Adriaan van Os wrote:
Waldek Hebisch wrote:
Yes, I think we should not mark 4.1 based version as "experimental". There are some regressions compared to gpc based on 3.4.6 but they are minor.
The failure of prep2.pas on Mac OS X can lead to nasty problems in software that depends on the missing defines. So, for Darwin, I am checking in the following diff (although it may be wrong for cross-compilers)
diff -ur gcc-4.1.2-orig/gcc/p/gpcpp.c gcc-4.1.2/gcc/p/gpcpp.c --- gcc-4.1.2-orig/gcc/p/gpcpp.c 2007-09-04 08:22:53.000000000 +0200 +++ gcc-4.1.2/gcc/p/gpcpp.c 2007-09-18 10:36:57.000000000 +0200 @@ -1187,6 +1187,14 @@ strcat (strcpy (tmp_buf, "__GPC_RELEASE__="), GPC_VERSION_STRING); make_definition (tmp_buf, 1);
+#ifdef __APPLE__
- make_definition ("__APPLE__", 1);
+#endif
+#ifdef __MACH__
- make_definition ("__MACH__", 1);
+#endif
- /* Now handle the command line options. */ /* Do -U's and -D's in the order they were seen. */ for (i = 1; i < argc; i++)
Hmm, that solves only tiny part of the problem. Technically, to know about Darwin/PPC builtins gpc needs information provided by darwin_cpp_builtins and rs6000_cpu_cpp_builtins. Proper solution would be to put definitions of both functions in files visible by the front end -- either change them to macros and move to header file (as done by most target files) or maybe put them in some "target independed" file guarded by preprocessor conditions.
Simple practical way is to link offending files into gpc. I tried the patch below some time ago and it seemed to work, but since the patch may potentially break working targets I was not included in the official version.
The part below is copied (via cut&paste) from an e-mail, so it probably has incorrect tabs (and files changed anyway)...
---------------------------------------------------------------------
GPC has the same problem with 3.4.0 for ppc-linux target. We may also try to link in C_TARGET_OBJS. If I define `cpp_define' and add dummy definitions of `c_lex' and `cpp_assert' then gpc1 for ppc-linux seem to work. Unfortunatly linking C_TARGET_OBJS may break some other targets. But ia64 (the only other Debian target for which C_TARGET_OBJS is non-empty) seem to work. However, if we put C_TARGET_OBJS in a library and link it to that library we should be completly safe.
Crude patch below:
--- ../tst25/gpc-20040516/p/Make-lang.in 2004-05-18 20:01:22.000000000 +0200 +++ gpc-20040516/p/Make-lang.in 2004-05-20 20:19:42.000000000 +0200 @@ -587,7 +587,7 @@ p/typecheck.o p/types.o p/convert.o p/dbxout.o p/dwarf2out.o \ p/expr.o p/fold-const.o p/function.o p/integrate.o p/optabs.o \ p/stor-layout.o p/toplev.o p/tree.o p/stmt.o p/emit-rtl.o \ - p/version.o + p/version.o $(C_TARGET_OBJS)
# Exclude patched files from language-independent object file list. # Not necessary for gcc-3 since for a library (libbackend.a), the linker does this automatically. --- ../tst25/gpc-20040516/p/lang.c 2004-05-19 01:12:12.000000000 +0200 +++ gpc-20040516/p/lang.c 2004-05-20 20:40:07.000000000 +0200 @@ -402,6 +402,29 @@ fprintf (stderr, "-D%s -D__%s -D__%s__ ", s, s, s); }
+int +c_lex (t) + tree * t; +{ + return 0; +} + +void +cpp_define (r, s) + void * r; + const char * s; +{ + builtin_define_std (s); +} + +void +cpp_assert (pfile, str) + void *pfile; + const char *str; +{ +} + + #define preprocessing_asm_p() 0 #define preprocessing_trad_p() 0 #define c_language (-1) @@ -554,9 +577,12 @@ /* @@ Backend bug: TARGET_OS_CPP_BUILTINS on some targets uses it though it's a C specific flag. */ #define flag_iso 1 - - TARGET_CPU_CPP_BUILTINS (); - TARGET_OS_CPP_BUILTINS (); + { + extern void rs6000_cpu_cpp_builtins PARAMS ((void *)); + void * pfile = 0; + TARGET_CPU_CPP_BUILTINS (); + TARGET_OS_CPP_BUILTINS (); + } #endif /* The following is no joke! The difference between what the preprocessor and the compiler think of BYTES_BIG_ENDIAN is
Waldek Hebisch a écrit:
I have put a new gpc snapshot at:
When recompiling my programs with djgpp built snapshot, both with gcc 3.4.4 and gcc 4.1.2 backends (both uploaded) I have found two new bugs (not present with gpc 20060325 /gcc 3.4.4)
Reducing to smallest possible test programs they are
1/ ======================================================
Problem with recursive definition or operators
Occurs for both backends
Two programs display the bug
---------------------------------------------------------
program powrecur;
var r: real;
operator power(r: real; n:integer) y: real; begin if n < 0 then y := 1 / (r power (0-n)) else y := r pow n end;
begin r := 10; if abs ( r power(-2) - r pow (-2) ) < epsreal then write('OK') else write('failed') end.
--------------------------------------------------------------
program minrecur;
var i,j: integer;
operator minus (a,b: integer) = y: integer; begin if b < 0 then y := -( (0-a) minus (0-b) ) else y := a - b end;
begin i := -10; j := -10; if i minus j = 0 then write('OK') else write('failed') end.
---------------------------------------------------------------
They give similar error messages
minrecur.pas: In operator `minus (integer, integer)': minrecur.pas:7: error: invalid use of operator `minus'
Notice that (0-n) (0-a) (0-b) instead of (-n) (-a) (-b) where necessary in the previous (20060325) snapshot, which compiles these programs (ang gives good results with more complicated arguments).
Work around is easy, but a fix would be better.
2/ ============================================================
Occurs only with 4.1.2 backend.
The test program is composed of two files
--------------------------------------------------------------
program strg;
uses ustrg;
begin if n = Un then write('OK') else write('failed'); end.
---------------------------------------------------
unit ustrg;
INTERFACE
function str2int(const s: string) = i : integer;
var Un : integer = str2int('1'); n : integer;
IMPLEMENTATION
function str2int(const s: string) = i : integer; begin ReadStr(s,i) end;
begin n := str2int('1'); end.
-------------------------------------------------
The error message is
c:\lombardi\djgpp\o/ustrg.o: In function `_p__M5_Ustrg_init': ustrg.pas:11: undefined reference to `__p__M5_Ustrg_S1_tmp_string_0' ustrg.pas:18: undefined reference to `__p__M5_Ustrg_S1_tmp_string_0' ustrg.pas:18: undefined reference to `__p__M5_Ustrg_S1_tmp_string_0' ustrg.pas:11: undefined reference to `__p__M5_Ustrg_S1_tmp_string_0' ustrg.pas:11: undefined reference to `__p__M5_Ustrg_S2_nonconstant_expr_1' collect2: ld returned 1 exit status
-------------------------------------------------------------
it seems to occur only with this dual initialisation: one directly in the interface one in the initialization part of the unit. and only with strings changing to a given fixed length string or to a local made (instead of internal) function WriteStr changes nothing
Hope this helps
Maurice
Waldek Hebisch wrote:
I have put a new gpc snapshot at:
[p17:~/gpc/testgpc/adriaan] adriaan% cat cast.pas program Cast;
var theItem: PtrInt;
procedure DisposeP( var thePtr: Pointer); begin if thePtr <> nil then begin Dispose( thePtr); thePtr:= nil end end;
begin theItem:= 0; DisposeP( Pointer( theItem)) end.
[p17:~/gpc/testgpc/adriaan] adriaan% gp cast.pas /Users/adriaan/gnu/gpc/testgpc/adriaan/cast.pas: In main program: /Users/adriaan/gnu/gpc/testgpc/adriaan/cast.pas:17: error: reference expected, value given in argument 1 /Users/adriaan/gnu/gpc/testgpc/adriaan/cast.pas:6: error: routine declaration
This compiled previously without errors with the gpc-20051116 snapshot.
Regards,
Adriaan van Os
Waldek Hebisch wrote:
I have put a new gpc snapshot at:
Does someone have a generated gpc.pdf file available ?
Regards,
Adriaan van Os
Adriaan van Os a écrit:
Waldek Hebisch wrote:
I have put a new gpc snapshot at:
Does someone have a generated gpc.pdf file available ?
For your convenience, I put it temporarily at
http://www.gnu-pascal.de/contrib/maurice/gpc-20070904.pdf
Maurice
Maurice Lombardi wrote:
Does someone have a generated gpc.pdf file available ?
For your convenience, I put it temporarily at
Thanks !
Regards,
Adriaan van Os
The testsuite results are as follows:
When producing Dwarf-2 debug-info, there are a number of additional failures
[p17:~/gpc/gpc-20070904/gcc-4.1.2-test] adriaan% make EXTRA_PFLAGS=-gdwarf-2 ... FAIL: aturbo3test.pas FAIL: crttest.pas FAIL: dialec3.pas FAIL: dialec5.pas FAIL: dialec6.pas FAIL: dialec7.pas ...
The backtrace is typically
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0000000c
Thread 0 Crashed: 0 cc1 0x00312eea decl_assembler_name + 16 (tree.c:257) 1 cc1 0x0036f529 machopic_output_function_base_name + 28 (darwin.c:251) 2 cc1 0x00170ba2 output_addr_const + 733 (final.c:3240) 3 cc1 0x00170b7c output_addr_const + 695 (final.c:3315) 4 cc1 0x00170a89 output_addr_const + 452 (final.c:3339) 5 cc1 0x00126242 dw2_asm_output_addr_rtx + 41 (dwarf2asm.c:220) 6 cc1 0x0012844b output_loc_sequence + 495 (dwarf2out.c:3230) 7 cc1 0x0013150f output_die + 678 (dwarf2out.c:7036) 8 cc1 0x00131411 output_die + 424 (dwarf2out.c:7159) 9 cc1 0x00131411 output_die + 424 (dwarf2out.c:7159) 10 cc1 0x00131411 output_die + 424 (dwarf2out.c:7159) 11 cc1 0x00131c71 output_comp_unit + 306 (dwarf2out.c:7230) 12 cc1 0x0013d09e dwarf2out_finish + 1120 (dwarf2out.c:14269) 13 cc1 0x00312212 toplev_main + 1947 (toplev.c:1030) 14 cc1 0x00001eda _start + 216 15 cc1 0x00001e01 start + 41
Thread 0 crashed with i386 Thread State: eax: 0x00000000 ebx: 0x00312ee7 ecx:0xa000bd00 edx: 0x4281fa7c edi: 0x00a07200 esi: 0x00000000 ebp:0xbfffd658 esp: 0xbfffd640 ss: 0x0000002f efl: 0x00010282 eip:0x00312eea cs: 0x00000027 ds: 0x0000002f es: 0x0000002f fs:0x00000000 gs: 0x00000037
But maybe the failures are Darwin-specific.
Regards,
Adriaan van Os
Adriaan van Os wrote:
When producing Dwarf-2 debug-info, there are a number of additional failures
[p17:~/gpc/gpc-20070904/gcc-4.1.2-test] adriaan% make EXTRA_PFLAGS=-gdwarf-2 ... FAIL: aturbo3test.pas FAIL: crttest.pas FAIL: dialec3.pas FAIL: dialec5.pas FAIL: dialec6.pas FAIL: dialec7.pas ...
The backtrace is typically
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0000000c
Thread 0 Crashed: 0 cc1 0x00312eea decl_assembler_name + 16 (tree.c:257) 1 cc1 0x0036f529 machopic_output_function_base_name + 28 (darwin.c:251) 2 cc1 0x00170ba2 output_addr_const + 733 (final.c:3240) 3 cc1 0x00170b7c output_addr_const + 695 (final.c:3315) 4 cc1 0x00170a89 output_addr_const + 452 (final.c:3339) 5 cc1 0x00126242 dw2_asm_output_addr_rtx + 41 (dwarf2asm.c:220) 6 cc1 0x0012844b output_loc_sequence + 495 (dwarf2out.c:3230) 7 cc1 0x0013150f output_die + 678 (dwarf2out.c:7036) 8 cc1 0x00131411 output_die + 424 (dwarf2out.c:7159) 9 cc1 0x00131411 output_die + 424 (dwarf2out.c:7159) 10 cc1 0x00131411 output_die + 424 (dwarf2out.c:7159) 11 cc1 0x00131c71 output_comp_unit + 306 (dwarf2out.c:7230) 12 cc1 0x0013d09e dwarf2out_finish + 1120 (dwarf2out.c:14269) 13 cc1 0x00312212 toplev_main + 1947 (toplev.c:1030) 14 cc1 0x00001eda _start + 216 15 cc1 0x00001e01 start + 41
Thread 0 crashed with i386 Thread State: eax: 0x00000000 ebx: 0x00312ee7 ecx:0xa000bd00 edx: 0x4281fa7c edi: 0x00a07200 esi: 0x00000000 ebp:0xbfffd658 esp: 0xbfffd640 ss: 0x0000002f efl: 0x00010282 eip:0x00312eea cs: 0x00000027 ds: 0x0000002f es: 0x0000002f fs:0x00000000 gs: 0x00000037
But maybe the failures are Darwin-specific.
It seems that machopic_output_function_base_name tries to use
DECL_ASSEMBLER_NAME (current_function_decl)
however, at this time we are outside any function, so current_function_decl is NULL, and we get null pointer exception. Looking at output_addr_const I see that it uses assemble_name function which (via assemble_name_raw) uses ASM_OUTPUT_LABELREF. This macro calls machopic_output_function_base_name if the name is "<pic base>".
ATM I have no idea how this name could appear in expression outside a function, but clearly the details are Darwin specific.
Waldek Hebisch wrote:
It seems that machopic_output_function_base_name tries to use
DECL_ASSEMBLER_NAME (current_function_decl)
however, at this time we are outside any function, so current_function_decl is NULL, and we get null pointer exception. Looking at output_addr_const I see that it uses assemble_name function which (via assemble_name_raw) uses ASM_OUTPUT_LABELREF. This macro calls machopic_output_function_base_name if the name is "<pic base>".
ATM I have no idea how this name could appear in expression outside a function, but clearly the details are Darwin specific.
Unfortunately, upon trying out dwarf-2 with the new compiler on OS X, Gale Paper noticed that it didn't work at all. Some time ago, it did work and better than with stabs http://www.gnu-pascal.de/crystal/gpc/en/mail13505.html. I found the reason to be Apple removed support for __DWARFA segments in GDB, implementing a new scheme http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01092.html. The patches needed can not be easily back-ported to gcc-4.1.2, because assembler handling of sections has been reworked from gcc-4.1 to gcc-4.2 http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01848.html.
So, although I am very grateful for the gcc-4.1 integration, I am looking forward for gcc-4.2 support.
Regards,
Adriaan van Os
I am using the new gpc snapshot on OSX 10.4.10 (PPC) and compile the following program:
program prog;
procedure dcp; type pv = record x, y: Extended; v: array[1..2] of Boolean; end; var sp: pv; z: Boolean;
procedure d(p: pv); begin writeln('access z before'); if z then writeln('z is true'); end;
begin { dcp } z := True; d(sp); end;
begin dcp; end.
petersch% /Developer/Pascal/gpc412/bin/gpc -o prog prog.pas petersch% prog access z before Bus error
Note that the program works ok with gpc 20060325, based on gcc-3.4.5. The program also works with the latest compiler when making variable z global.
Any ideas?
Peter
Peter Schorn wrote:
I am using the new gpc snapshot on OSX 10.4.10 (PPC) and compile the following program:
program prog;
procedure dcp; type pv = record x, y: Extended; v: array[1..2] of Boolean; end; var sp: pv; z: Boolean;
procedure d(p: pv); begin writeln('access z before'); if z then writeln('z is true'); end;
begin { dcp } z := True; d(sp); end;
begin dcp; end.
petersch% /Developer/Pascal/gpc412/bin/gpc -o prog prog.pas petersch% prog access z before Bus error
Note that the program works ok with gpc 20060325, based on gcc-3.4.5. The program also works with the latest compiler when making variable z global.
On an Intel Mac, I get
[p17:~/gpc/testgpc/adriaan] adriaan% gpc schorn1.pas schorn1.pas: In procedure `d': schorn1.pas:18: error: unable to find a register to spill in class 'CREG' schorn1.pas:18: error: this is the insn: (insn 8 7 9 0 (parallel [ (set (reg:SI 0 ax [73]) (const_int 0 [0x0])) (set (reg/f:SI 5 di [70]) (plus:SI (ashift:SI (reg:SI 0 ax [73]) (const_int 2 [0x2])) (reg/f:SI 5 di [70]))) (set (reg/f:SI 4 si [71]) (plus:SI (ashift:SI (reg:SI 0 ax [73]) (const_int 2 [0x2])) (reg/f:SI 4 si [71]))) (set (mem/s/c:BLK (reg/f:SI 5 di [70]) [0 P+0 S48 A128]) (mem/s/c:BLK (reg/f:SI 4 si [71]) [0 P+0 S48 A32])) (use (reg:SI 0 ax [73])) (use (reg:SI 19 dirflag)) ]) 518 {*rep_movsi} (nil) (expr_list:REG_UNUSED (reg/f:SI 4 si [71]) (expr_list:REG_UNUSED (reg/f:SI 5 di [70]) (expr_list:REG_UNUSED (reg:SI 0 ax [73]) (expr_list:REG_DEAD (reg:SI 19 dirflag) (expr_list:REG_UNUSED (reg/f:SI 4 si [71]) (expr_list:REG_UNUSED (reg/f:SI 5 di [70]) (expr_list:REG_UNUSED (reg:SI 0 ax [73]) (nil))))))))) schorn1.pas:18: confused by earlier errors, bailing out
[p17:~/gpc/testgpc/adriaan] adriaan% gpc -v Using built-in specs. Configured with: ../gcc-4.1.2/configure --enable-languages=pascal,c --enable-threads=posix --target=i386-apple-darwin8 --host=i386-apple-darwin8 --build=i386-apple-darwin8 --prefix=/Developer/Pascal/gpc412d2 --with-arch=pentium-m --with-tune=prescott Thread model: posix gpc version 20070904, based on gcc-4.1.2
[p17:~/gpc/testgpc/adriaan] adriaan% uname -a Darwin p17 8.6.2 Darwin Kernel Version 8.6.2: Thu Apr 13 18:48:29 PDT 2006; root:xnu-792.9.59.obj~1/RELEASE_I386 i386 i386
Did you patch the compiler with my diff for OS X or not ? Did you test on a powerpc or Intel Mac ? How was the compiler configured and built ?
Regards,
Adriaan van Os
Adriaan van Os wrote:
Peter Schorn wrote:
I am using the new gpc snapshot on OSX 10.4.10 (PPC) and compile the following program:
Did you patch the compiler with my diff for OS X or not ? Did you test on a powerpc or Intel Mac ? How was the compiler configured and built ?
I now see that you mentioned that it was powerpc. I can reproduce the bus error on i386-apple-darwin with -Os
[p17:~/gpc/testgpc/adriaan] adriaan% gpc -Os -g schorn1.pas [p17:~/gpc/testgpc/adriaan] adriaan% ./a.out access z before Bus error [p17:~/gpc/testgpc/adriaan] adriaan% gdb a.out GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:50:43 GMT 2006) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries .. done
(gdb) run Starting program: /Users/adriaan/gnu/gpc/testgpc/adriaan/a.out Reading symbols for shared libraries . done access z before
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 D.919 (P={X = <invalid float value>, Y = <invalid float value>, V = {true, false}}) at schorn1.pas:16 16 if z then (gdb) bt full #0 D.919 (P={X = <invalid float value>, Y = <invalid float value>, V = {true, false}}) at schorn1.pas:16 P = { X = <invalid float value>, Y = <invalid float value>, V = {true, false} } #1 0x00001c43 in _p__M0_S0_Dcp () at schorn1.pas:21 Sp = { X = <invalid float value>, Y = <invalid float value>, V = {true, false} } #2 0x00001c8a in main (argc=-1073748152, argv=0x1b52, envp=0xbfffe7f4) at schorn1.pas:1 No locals.
I suppose this is a back-end bug, reproducible on other platforms.
Regards,
Adriaan van Os
Adriaan van Os wroteL
Adriaan van Os wrote:
Peter Schorn wrote:
I am using the new gpc snapshot on OSX 10.4.10 (PPC) and compile the following program:
Did you patch the compiler with my diff for OS X or not ? Did you test on a powerpc or Intel Mac ? How was the compiler configured and built ?
I now see that you mentioned that it was powerpc. I can reproduce the bus error on i386-apple-darwin with -Os
[p17:~/gpc/testgpc/adriaan] adriaan% gpc -Os -g schorn1.pas [p17:~/gpc/testgpc/adriaan] adriaan% ./a.out access z before Bus error [p17:~/gpc/testgpc/adriaan] adriaan% gdb a.out GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:50:43 GMT 2006) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries .. done
(gdb) run Starting program: /Users/adriaan/gnu/gpc/testgpc/adriaan/a.out Reading symbols for shared libraries . done access z before
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 D.919 (P={X = <invalid float value>, Y = <invalid float value>, V = {true, false}}) at schorn1.pas:16 16 if z then (gdb) bt full #0 D.919 (P={X = <invalid float value>, Y = <invalid float value>, V = {true, false}}) at schorn1.pas:16 P = { X = <invalid float value>, Y = <invalid float value>, V = {true, false} } #1 0x00001c43 in _p__M0_S0_Dcp () at schorn1.pas:21 Sp = { X = <invalid float value>, Y = <invalid float value>, V = {true, false} } #2 0x00001c8a in main (argc=-1073748152, argv=0x1b52, envp=0xbfffe7f4) at schorn1.pas:1 No locals.
I suppose this is a back-end bug, reproducible on other platforms.
I can not reproduce this on Amd64 Linux (tried verious option incuding -fPIC). I will try i386 Linux, but it looks that the program uses features that Apple decided to implement in its own way.
On Wed, 19 Sep 2007, Waldek Hebisch wrote:
Adriaan van Os wroteL
Adriaan van Os wrote:
Peter Schorn wrote:
I am using the new gpc snapshot on OSX 10.4.10 (PPC) and compile the following program:
Did you patch the compiler with my diff for OS X or not ? Did you test on a powerpc or Intel Mac ? How was the compiler configured and built ?
I now see that you mentioned that it was powerpc. I can reproduce the bus error on i386-apple-darwin with -Os
[p17:~/gpc/testgpc/adriaan] adriaan% gpc -Os -g schorn1.pas [p17:~/gpc/testgpc/adriaan] adriaan% ./a.out access z before Bus error [p17:~/gpc/testgpc/adriaan] adriaan% gdb a.out GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:50:43 GMT 2006) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries .. done
(gdb) run Starting program: /Users/adriaan/gnu/gpc/testgpc/adriaan/a.out Reading symbols for shared libraries . done access z before
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 D.919 (P={X = <invalid float value>, Y = <invalid float value>, V = {true, false}}) at schorn1.pas:16 16 if z then (gdb) bt full #0 D.919 (P={X = <invalid float value>, Y = <invalid float value>, V = {true, false}}) at schorn1.pas:16 P = { X = <invalid float value>, Y = <invalid float value>, V = {true, false} } #1 0x00001c43 in _p__M0_S0_Dcp () at schorn1.pas:21 Sp = { X = <invalid float value>, Y = <invalid float value>, V = {true, false} } #2 0x00001c8a in main (argc=-1073748152, argv=0x1b52, envp=0xbfffe7f4) at schorn1.pas:1 No locals.
I suppose this is a back-end bug, reproducible on other platforms.
I can not reproduce this on Amd64 Linux (tried verious option incuding -fPIC). I will try i386 Linux, but it looks that the program uses features that Apple decided to implement in its own way.
On linux i686, compiles & runs ok. output:
access z before z is true
gpc version:
Using built-in specs. Configured with: ../gcc-4.1.2/configure --prefix=/usr --enable-shared --enable-languages=c,c++,pascal --enable-threads=posix --enable-__cxa_atexit Thread model: posix gpc version 20070904, based on gcc-4.1.2
hope this helps russ
Russell Whitaker wrote:
I suppose this is a back-end bug, reproducible on other platforms.
I can not reproduce this on Amd64 Linux (tried verious option incuding -fPIC). I will try i386 Linux, but it looks that the program uses features that Apple decided to implement in its own way.
On linux i686, compiles & runs ok.
Thanks for trying this out on other platforms. Looking into this further, the cause seems to be a curious miscalculation of record sizes.
program prog;
type pv1 = record x, y: Extended; v: array[1..2] of Boolean; end; pv2 = packed record x, y: Extended; v: array[1..2] of Boolean; end; pv3 = record x, y: Extended; end; pv4 = packed record x, y: Extended; end; pv5 = record v: array[1..2] of Boolean; end; pv6 = packed record v: array[1..2] of Boolean; end;
procedure dcp; var sp: pv1; z: Boolean;
procedure d(p: pv1); begin writeln('access z before'); if z then writeln('z is true'); end;
begin { dcp } z := True; d(sp); end;
begin writeln( 'sizeof(pv1) = ', sizeof( pv1)); writeln( 'sizeof(pv2) = ', sizeof( pv2)); writeln( 'sizeof(pv3) = ', sizeof( pv3)); writeln( 'sizeof(pv4) = ', sizeof( pv4)); writeln( 'sizeof(pv5) = ', sizeof( pv5)); writeln( 'sizeof(pv6) = ', sizeof( pv6)); dcp; end.
[p17:~/gpc/testgpc/adriaan] adriaan% gpc schorn2.pas -Os [p17:~/gpc/testgpc/adriaan] adriaan% ./a.out sizeof(pv1) = 48 sizeof(pv2) = 34 sizeof(pv3) = 32 sizeof(pv4) = 32 sizeof(pv5) = 2 sizeof(pv6) = 2 access z before Bus error
Any hint where about to look in the back-end sources ?
Regards,
Adriaan van Os
Adriaan van Os wrote:
Russell Whitaker wrote:
I suppose this is a back-end bug, reproducible on other platforms.
I can not reproduce this on Amd64 Linux (tried verious option incuding -fPIC). I will try i386 Linux, but it looks that the program uses features that Apple decided to implement in its own way.
On linux i686, compiles & runs ok.
Thanks for trying this out on other platforms. Looking into this further, the cause seems to be a curious miscalculation of record sizes.
The temporary workaround seems to be to pass --maximum-field-alignment=n, where n is anything except the default n=0.
[p17:~/gpc/testgpc/adriaan] adriaan% gpc schorn1.pas --maximum-field-alignment=1 [p17:~/gpc/testgpc/adriaan] adriaan% ./a.out access z before z is true [p17:~/gpc/testgpc/adriaan] adriaan% gpc schorn1.pas --maximum-field-alignment=2 [p17:~/gpc/testgpc/adriaan] adriaan% ./a.out access z before z is true [p17:~/gpc/testgpc/adriaan] adriaan% gpc schorn1.pas --maximum-field-alignment=4 [p17:~/gpc/testgpc/adriaan] adriaan% ./a.out access z before z is true [p17:~/gpc/testgpc/adriaan] adriaan% gpc schorn1.pas --maximum-field-alignment=8 [p17:~/gpc/testgpc/adriaan] adriaan% ./a.out access z before z is true [p17:~/gpc/testgpc/adriaan] adriaan% gpc schorn1.pas --maximum-field-alignment=16 [p17:~/gpc/testgpc/adriaan] adriaan% ./a.out access z before z is true [p17:~/gpc/testgpc/adriaan] adriaan% gpc schorn1.pas --maximum-field-alignment=0 schorn1.pas: In procedure `d': schorn1.pas:18: error: unable to find a register to spill in class 'CREG' schorn1.pas:18: error: this is the insn: (insn 8 7 9 0 (parallel [ (set (reg:SI 0 ax [73]) (const_int 0 [0x0])) (set (reg/f:SI 5 di [70]) (plus:SI (ashift:SI (reg:SI 0 ax [73]) (const_int 2 [0x2])) (reg/f:SI 5 di [70]))) (set (reg/f:SI 4 si [71]) (plus:SI (ashift:SI (reg:SI 0 ax [73]) (const_int 2 [0x2])) (reg/f:SI 4 si [71]))) (set (mem/s/c:BLK (reg/f:SI 5 di [70]) [0 P+0 S48 A128]) (mem/s/c:BLK (reg/f:SI 4 si [71]) [0 P+0 S48 A32])) (use (reg:SI 0 ax [73])) (use (reg:SI 19 dirflag)) ]) 518 {*rep_movsi} (nil) (expr_list:REG_UNUSED (reg/f:SI 4 si [71]) (expr_list:REG_UNUSED (reg/f:SI 5 di [70]) (expr_list:REG_UNUSED (reg:SI 0 ax [73]) (expr_list:REG_DEAD (reg:SI 19 dirflag) (expr_list:REG_UNUSED (reg/f:SI 4 si [71]) (expr_list:REG_UNUSED (reg/f:SI 5 di [70]) (expr_list:REG_UNUSED (reg:SI 0 ax [73]) (nil))))))))) schorn1.pas:18: confused by earlier errors, bailing out
Regards,
Adriaan van Os
Adriaan van Os wrote:
Looking into this further, the cause seems to be a curious miscalculation of record sizes.
program prog;
type pv1 = record x, y: Extended; v: array[1..2] of Boolean; end; pv2 = packed record x, y: Extended; v: array[1..2] of Boolean; end; pv3 = record x, y: Extended; end; pv4 = packed record x, y: Extended; end; pv5 = record v: array[1..2] of Boolean; end; pv6 = packed record v: array[1..2] of Boolean; end;
<snip>
sizeof(pv1) = 48 sizeof(pv2) = 34 sizeof(pv3) = 32 sizeof(pv4) = 32 sizeof(pv5) = 2 sizeof(pv6) = 2
Why do you think that sizes are miscalculated? On my Linux box I get the same result and explanation is simple: to get correct alignment Extended uses 16 bytes (only 10 are really used, the rest is just padding). That explains size of pv3 and pv4. pv1 must be aligned to 16 bytes, so we must round up the size to 48 bytes. pv2 is packed, so final padding is skipped, and we get 34.
So, it looks OK (assuming that C compiler on Mac OSX gives you 16 as the size for 'long double').
Waldek Hebisch wrote:
Adriaan van Os wrote:
Looking into this further, the cause seems to be a curious miscalculation of record sizes.
Why do you think that sizes are miscalculated? On my Linux box I get the same result and explanation is simple: to get correct alignment Extended uses 16 bytes (only 10 are really used, the rest is just padding). That explains size of pv3 and pv4. pv1 must be aligned to 16 bytes, so we must round up the size to 48 bytes. pv2 is packed, so final padding is skipped, and we get 34.
So, it looks OK (assuming that C compiler on Mac OSX gives you 16 as the size for 'long double').
Yes, you are right, it has nothing to do with record sizes as such. I thought so, because putting "packed" in front of the record type, solved the problem. However, it does have to do with alignments (see my follow-up email on the issue). When --maximum-field-alignment=0 (the default), then within procedure 'd', the addresses of sp and z are wrong. With any other value for --maximum-field-alignment, the program compiles and runs OK.
Regards,
Adriaan van Os
program prog;
procedure dcp; type pv = record x, y: extended; v: array[1..2] of Boolean; end; var sp: pv; z: Boolean;
procedure d(p: pv); begin writeln( 'in d: @sp = ', PtrWord( @sp)); writeln( 'in d: @z = ', PtrWord( @z)); writeln('access z before'); if z then writeln('z is true'); end;
begin { dcp } writeln( 'in dcp: @sp = ', PtrWord( @sp)); writeln( 'in dcp: @z = ', PtrWord( @z)); z := True; d(sp); end;
begin dcp; end. [p17:~/gpc/testgpc/adriaan] adriaan% gpc schorn1b.pas -Os [p17:~/gpc/testgpc/adriaan] adriaan% ./a.out in dcp: @sp = 3221219184 in dcp: @z = 3221219232 in d: @sp = 0 in d: @z = 48 access z before Bus error
-
Adriaan van Os -
Gale Paeper -
Martin Liddle -
Maurice Lombardi -
Nestor Aguilera -
Peter Schorn -
Russell Whitaker -
Waldek Hebisch