I have put a new gpc snapshot at:
http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20051116.tar.bz2
This snapshot has integrated preprocessor. This should solve problems with (lack of) predefined symbols when using 3.3.x and 3.4.x backends. The preprocessor is just integrated -- inside it is the same preprocessor as before. There is new `--preprocessed' option, but the change is intended to be as compatible as possible. Still, the code to handle command line changed, so there may be some unintended change. Also, there is no gpcpp executable anymore (use gpc -E as preprocessor).
There are also minor fixes, see:
http://www.math.uni.wroc.pl/~hebisch/gpc/NEWS-20051116
and
http://www.math.uni.wroc.pl/~hebisch/gpc/Fixed-20051116
Waldek Hebisch wrote:
I have put a new gpc snapshot at:
http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20051116.tar.bz2
Thanks for the snapshot. The testsuite results on powerpc-apple-darwin7 are
[G5: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-11-16 14:06:00 Native configuration is powerpc-apple-darwin7 (G5.local)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas UNSUPPORTED: asmtest.pas UNSUPPORTED: fjf165a.pas FAIL: fjf998r.pas UNSUPPORTED: gmptest.pas UNSUPPORTED: longr2.pas FAIL: prep2p.pas FAIL: systemtest.pas
=== gpc Summary ===
# of tests 4969 # of expected passes 4959 # of unexpected failures 3 # of unsupported tests 7
gpc version 20051116, based on gcc-3.4.4
where prep2p.pas fails with
FAIL: prep2p.pas 0a1,2
_ARCH_PPC _BIG_ENDIAN
1a4
__BIG_ENDIAN__
failed
This snapshot has integrated preprocessor. This should solve problems with (lack of) predefined symbols when using 3.3.x and 3.4.x backends.
I can confirm that it does, which is quite useful when working e.g. with cross-compilers.
The preprocessor is just integrated -- inside it is the same preprocessor as before. There is new `--preprocessed' option, but the change is intended to be as compatible as possible. Still, the code to handle command line changed, so there may be some unintended change. Also, there is no gpcpp executable anymore (use gpc -E as preprocessor).
It appears that an old (http://www.gnu-pascal.de/crystal/gpc/en/mail11093.html) or similar problem has reappeared, but this thime with gp
[G5:gpc/testgpc/adriaan] adriaan% gpc --gnu-pascal -O1 -Wuninitialized hello.pas
[G5:gpc/testgpc/adriaan] adriaan% gp --gnu-pascal -O1 -Wuninitialized hello.pas gpc1: warning: -Wuninitialized is not supported without -O
[G5:gpc/testgpc/adriaan] adriaan% gp --gnu-pascal -O1 -Wuninitialized hello.pas -v gpc -dumpmachine gpc -dumpversion gpc -print-file-name=units gpc --print-needed-options -x Preprocessed-Pascal /var/tmp/GPaaa17630 /Users/adriaan/gnu/gpc/testgpc/adriaan/hello.pas: recompiling because of compiler version mismatch gpc --gnu-pascal -O1 -Wuninitialized -I /Users/adriaan/gnu/gpc/testgpc/adriaan/ -I /Users/adriaan/gnu/gpc/testgpc/adriaan/ -I . -I /Developer/Pascal/gpc344d6/lib/gcc/powerpc-apple-darwin7/3.4.4/units -I /Users/adriaan/gnu/gpc/testgpc/adriaan/ --unit-path=/Users/adriaan/gnu/gpc/testgpc/adriaan/ -E -H /Users/adriaan/gnu/gpc/testgpc/adriaan/hello.pas gpc1: warning: -Wuninitialized is not supported without -O
This seems to be caused by the -E flag
[G5:gpc/testgpc/adriaan] adriaan% gpc --gnu-pascal -O1 -Wuninitialized hello.pas -E gpc1: warning: -Wuninitialized is not supported without -O # 1 "hello.pas"
program Hello (Output);
begin WriteLn ('Hello, world.') end.
- `--longjmp-all-nonlocal-labels' is on by default on Darwin/PPC
Thanks,
Adriaan van Os
On Wed, 16 Nov 2005, Waldek Hebisch wrote:
I have put a new gpc snapshot at:
http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20051116.tar.bz2
...
Results here, note the glibc complaint:
Test Run By russ on 2005-11-16 11:37:24 Native configuration is i686-pc-linux-gnu (bigred)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: aregextest.pas *** glibc detected *** double free or corruption (!prev): 0x08466c68 *** FAIL: prep1a.pas
=== gpc Summary ===
# of tests 4969 # of expected passes 4967 # of unexpected failures 1 # of unsupported tests 1
gpc version 20051116, based on gcc-3.4.4
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: ../gcc-3.4.4/configure --enable-languages=c,c++,pascal --enable-shared --enable-threads=posix --enable-__cxa_atexit Thread model: posix gpc version 20051116, based on gcc-3.4.4
Hope this helps, Russ
Adriaan van Os wrote:
Waldek Hebisch wrote:
I have put a new gpc snapshot at:
http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20051116.tar.bz2
Thanks for the snapshot. The testsuite results on powerpc-apple-darwin7 are
<snip>
where prep2p.pas fails with
FAIL: prep2p.pas 0a1,2
_ARCH_PPC _BIG_ENDIAN
1a4
__BIG_ENDIAN__
failed
prep2p tests if Pascal has the same predefined symbols as C. Unfortunatly, PPC backend exports puts some predefines in C only files. We can try to link in needed files, but then we risk problems in future versions on on other targets. So ATM prep2p is expected to fail on PPC.
Also, there is no gpcpp executable anymore (use gpc -E as preprocessor).
It appears that an old (http://www.gnu-pascal.de/crystal/gpc/en/mail11093.html) or similar problem has reappeared, but this thime with gp
<snip>
This seems to be caused by the -E flag
[G5:gpc/testgpc/adriaan] adriaan% gpc --gnu-pascal -O1 -Wuninitialized hello.pas -E gpc1: warning: -Wuninitialized is not supported without -O
The patch below should fix this (I forgot to pass -O when using -E)
--- gpc/p/lang-specs.h.bb 2005-11-17 01:19:05.394171816 +0100 +++ gpc-20051116/p/lang-specs.h 2005-11-17 01:31:32.740557896 +0100 @@ -62,11 +62,11 @@ %{!fsyntax-only:%(invoke_as)} }}}", 0}, #endif "gpc1 %{E:-E %{!M:%(cpp_unique_options) %1 %{m*} %{f*&W*&pedantic*} %{w} " - "%(cpp_debug_options)}}" + "%(cpp_debug_options) %{O*}}}" "%{M:%(cpp_unique_options) %1 %{m*} %{f*&W*&pedantic*} %{w}" - "%(cpp_debug_options)}" + "%(cpp_debug_options) %{O*}}" "%{!E:%{!M:%{save-temps:-E %(cpp_unique_options) %1 %{m*} " - "%{f*&W*&pedantic*} %{w} -o %b.i \n\ + "%{f*&W*&pedantic*} %{w} %{O*} -o %b.i \n\ gpc1 -fpreprocessed %b.i} %{!save-temps:%(cpp_unique_options)} \ %(cc1_options)\ %{!famtmpfile*:%eInternal GPC problem: internal option `--amtmpfile' not given}\
On 16 Nov 2005 at 8:59, Waldek Hebisch wrote:
I have put a new gpc snapshot at:
http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20051116.tar.bz2
Results from Mingw:
1. gcc-3.2.3 backend - two failures: TEST fjf1044s.pas: ./fjf1044s.pas: In procedure `p': ./fjf1044s.pas:36: Internal compiler error in expand_call, at calls.c:3078 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. failed
TEST prep1a.pas: f:/mingw/lib/libmingw32.a(main.o)(.text+0x106):main.c: undefined reference to `WinMain@16' failed compile: prep1a.pas
I am not sure why this prep1a should lead to a reference to "WinMain@16"
2. gcc-3.3.5 backend - several failures - see attached log
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.
---- File information ----------- File: gpc-20051116-mingw-3.3.5.log.gz Date: 17 Nov 2005, 9:10 Size: 18824 bytes. Type: Unknown
Prof A Olowofoyeku (The African Chief) a écrit:
On 16 Nov 2005 at 8:59, Waldek Hebisch wrote:
I have put a new gpc snapshot at:
http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20051116.tar.bz2
Results from Mingw:
- gcc-3.2.3 backend - two failures:
TEST fjf1044s.pas: ./fjf1044s.pas: In procedure `p': ./fjf1044s.pas:36: Internal compiler error in expand_call, at calls.c:3078 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. failed
TEST prep1a.pas: f:/mingw/lib/libmingw32.a(main.o)(.text+0x106):main.c: undefined reference to `WinMain@16' failed compile: prep1a.pas
I am not sure why this prep1a should lead to a reference to "WinMain@16"
- gcc-3.3.5 backend - several failures - see attached log
Very similar for DJGPP. Seems to be related to Windows/DOS target peculiarities
Only one failure with gcc-3.2.3 fjf1044s.pas with same error mesage as above
Many failures with gcc-3.3.5 most of them with the same message:
FAIL: adam3i.pas c:/djgpp/b/gnu/build.gcc/gcc/p/test/a.out: error when trying to erase internal file `f' (Permission denied (EACCES)) (error #474 at 18f5)
see attached log
Maurice
Prof A Olowofoyeku wrote:
- gcc-3.3.5 backend - several failures - see attached log
Most (if not all) seem to be related to predefines. Gpc had a workaround which should be not needed with integrated preprocessor, so I have disable it.
If yo change 0 to 1 in the snippet below (from lang.c line 448):
static void do_def (const char *s) { make_definition (s, 1); #if 0 if (co->print_needed_options) fprintf (stderr, "-D%s ", s); #endif }
the workaround will be active again.
Waldek Hebisch wrote:
It appears that an old (http://www.gnu-pascal.de/crystal/gpc/en/mail11093.html) or similar problem has reappeared, but this thime with gp
<snip>
This seems to be caused by the -E flag
[G5:gpc/testgpc/adriaan] adriaan% gpc --gnu-pascal -O1 -Wuninitialized hello.pas -E gpc1: warning: -Wuninitialized is not supported without -O
The patch below should fix this (I forgot to pass -O when using -E)
--- gpc/p/lang-specs.h.bb 2005-11-17 01:19:05.394171816 +0100 +++ gpc-20051116/p/lang-specs.h 2005-11-17 01:31:32.740557896 +0100 @@ -62,11 +62,11 @@ %{!fsyntax-only:%(invoke_as)} }}}", 0}, #endif "gpc1 %{E:-E %{!M:%(cpp_unique_options) %1 %{m*} %{f*&W*&pedantic*} %{w} "
- "%(cpp_debug_options)}}"
- "%(cpp_debug_options) %{O*}}}" "%{M:%(cpp_unique_options) %1 %{m*} %{f*&W*&pedantic*} %{w}"
- "%(cpp_debug_options)}"
- "%(cpp_debug_options) %{O*}}" "%{!E:%{!M:%{save-temps:-E %(cpp_unique_options) %1 %{m*} "
- "%{f*&W*&pedantic*} %{w} -o %b.i \n\
- "%{f*&W*&pedantic*} %{w} %{O*} -o %b.i \n\ gpc1 -fpreprocessed %b.i} %{!save-temps:%(cpp_unique_options)} \ %(cc1_options)\ %{!famtmpfile*:%eInternal GPC problem: internal option
`--amtmpfile' not given}\
Fixes the problem, thanks.
Regards,
Adriaan van Os
Maurice Lombardi wrote:
Prof A Olowofoyeku (The African Chief) a écrit:
- gcc-3.3.5 backend - several failures - see attached log
Very similar for DJGPP. Seems to be related to Windows/DOS target peculiarities
Only one failure with gcc-3.2.3 fjf1044s.pas with same error mesage as above
Many failures with gcc-3.3.5 most of them with the same message:
FAIL: adam3i.pas c:/djgpp/b/gnu/build.gcc/gcc/p/test/a.out: error when trying to erase internal file `f' (Permission denied (EACCES)) (error #474 at 18f5)
see attached log
It seems that the message comes from RTS procedure Unlink (in files.pas 758) The culprit may be OSDosFlag (if it is false). In turn OSDosFlag depends on __OS_DOS__ beeing defined. __OS_DOS__ was defined in gpcpp by a special hack, which got broken by integrated preprocessor. The following should fix the problem (note that you need to rebuild the RTS for the change to be effective):
diff -up gpc-20051116/p/gpcpp.c gpc/p/gpcpp.c --- gpc-20051116/p/gpcpp.c 2005-11-13 16:23:34.000000000 +0100 +++ gpc/p/gpcpp.c 2005-11-17 22:23:21.121088472 +0100 @@ -1257,11 +1257,13 @@ gpcpp_process_options (int argc, char ** int c; char *p = pend_defs[i]; make_definition (p, pend_defs_case_sensitive[i]); +#ifndef GCC_3_3 if ((!strncmp (p, "MSDOS", c = 5) || !strncmp (p, "_WIN32", c = 6) || !strncmp (p, "__EMX__", c = 7)) && (p[c] == 0 || p[c] == '=')) make_definition ("__OS_DOS__=1", 1); +#endif } }
diff -up gpc-20051116/p/lang.c gpc/p/lang.c --- gpc-20051116/p/lang.c 2005-11-16 05:48:36.000000000 +0100 +++ gpc/p/lang.c 2005-11-17 22:23:53.523162608 +0100 @@ -447,7 +447,15 @@ static void builtin_define_std (const ch static void do_def (const char *s) { + int c; make_definition (s, 1); +#ifdef GCC_3_3 + if ((!strncmp (s, "MSDOS", c = 5) || + !strncmp (s, "_WIN32", c = 6) || + !strncmp (s, "__EMX__", c = 7)) + && (s[c] == 0 || s[c] == '=')) + make_definition ("__OS_DOS__=1", 1); +#endif #if 0 if (co->print_needed_options) fprintf (stderr, "-D%s ", s);
Russell Whitaker wrote:
Results here, note the glibc complaint:
Test Run By russ on 2005-11-16 11:37:24 Native configuration is i686-pc-linux-gnu (bigred)
=== gpc tests ===Running target any Running testsuite ...
UNSUPPORTED: aregextest.pas *** glibc detected *** double free or corruption (!prev): 0x08466c68 *** FAIL: prep1a.pas
Thanks for info. The following should fix this:
--- gpc/p/lang.c.bb2 2005-11-18 03:45:51.039453752 +0100 +++ gpc/p/lang.c 2005-11-18 03:46:02.528707120 +0100 @@ -664,7 +664,6 @@ call_gpcpp (const char * filename, FILE if (!co->print_deps) gpcpp_writeout (gpcpp_out_fname, gpcpp_out_stream);
- fclose (gpcpp_out_stream); exit (EXIT_SUCCESS); }
On 11/17/05, Waldek Hebisch hebisch@math.uni.wroc.pl wrote:
Russell Whitaker wrote:
Results here, note the glibc complaint:
Test Run By russ on 2005-11-16 11:37:24 Native configuration is i686-pc-linux-gnu (bigred)
=== gpc tests ===Running target any Running testsuite ...
UNSUPPORTED: aregextest.pas *** glibc detected *** double free or corruption (!prev): 0x08466c68 *** FAIL: prep1a.pas
Thanks for info. The following should fix this:
--- gpc/p/lang.c.bb2 2005-11-18 03:45:51.039453752 +0100 +++ gpc/p/lang.c 2005-11-18 03:46:02.528707120 +0100 @@ -664,7 +664,6 @@ call_gpcpp (const char * filename, FILE if (!co->print_deps) gpcpp_writeout (gpcpp_out_fname, gpcpp_out_stream);
- fclose (gpcpp_out_stream);
Should the fclose be moved into the if stmt?
exit (EXIT_SUCCESS); }
-- Waldek Hebisch hebisch@math.uni.wroc.pl
-- Thanks, Jim http://phython.blogspot.com
On Wed, 16 Nov 2005, Adriaan van Os wrote:
begin WriteLn ('Hello, world.') end.
- `--longjmp-all-nonlocal-labels' is on by default on Darwin/PPC
Thanks,
Adriaan van Os
Hello, Adriaan,
Are there some special instructions/requirements to make GPC work on Mac OS X (Darwin) box?
I remember ``make bootstrap'' was required, but last time I tried it was not sufficient for a successful build. Any patch needed?
Thanks, Mirsad
Mirsad Todorovac wrote:
Hello, Adriaan,
Are there some special instructions/requirements to make GPC work on Mac OS X (Darwin) box?
I remember ``make bootstrap'' was required, but last time I tried it was not sufficient for a successful build. Any patch needed?
If you download the sources from my website http://www.microbizz.nl/gpc.html, you will find full building instructions and needed patches for Mac OS X 10.3 and 10.4 included in http://www.microbizz.nl/gpc344d2.src.tar.bz2.
Regards,
Adriaan van Os
Mirsad Todorovac wrote:
Hello, Adriaan,
Are there some special instructions/requirements to make GPC work on Mac OS X (Darwin) box?
I remember ``make bootstrap'' was required, but last time I tried it was not sufficient for a successful build. Any patch needed?
If you download the sources from my website http://www.microbizz.nl/gpc.html, you will find full building instructions and needed patches for Mac OS X 10.3 and 10.4 included in http://www.microbizz.nl/gpc344d2.src.tar.bz2.
Clarification - the building instructions there should also apply to the gpc-20051116 snapshot. If that doesn't work, try "make CC=/Developer/Pascal/gpc344d2/bin/gcc" using the FSF-gcc compiler for the build. I don't trust the Apple system compiler. When I tried to build a cross-compiler lately on powerpc-apple-darwin8 for i686-apple-darwin8, the rts didn't build because gpc produced bad .gpi files. The problem was solved by using the FSF-gcc compiler for the build !
Patches - for gpc-20051116 to build, you only need the "Tiger" patch (but only on Mac OS X 10.4) and of course the diffs that Waldek has posted on this list to fix reported problems.
--- gcc/config/darwin.h.orig 2005-05-18 13:56:37.000000000 -0400 +++ gcc/config/darwin.h 2005-05-18 13:57:48.000000000 -0400 @@ -275,7 +275,8 @@ /* Machine dependent libraries. */
#undef LIB_SPEC -#define LIB_SPEC "%{!static:-lSystem}" +#define LIB_SPEC "%{!static:-lSystemStubs -lSystem}" +
Regards,
Adriaan van Os
James A. Morrison wrote:
On 11/17/05, Waldek Hebisch hebisch@math.uni.wroc.pl wrote:
--- gpc/p/lang.c.bb2 2005-11-18 03:45:51.039453752 +0100 +++ gpc/p/lang.c 2005-11-18 03:46:02.528707120 +0100 @@ -664,7 +664,6 @@ call_gpcpp (const char * filename, FILE if (!co->print_deps) gpcpp_writeout (gpcpp_out_fname, gpcpp_out_stream);
- fclose (gpcpp_out_stream);
Should the fclose be moved into the if stmt?
exit (EXIT_SUCCESS); }
Yes, the following is better:
--- gpc/p/lang.c.bb2 2005-11-18 03:45:51.000000000 +0100 +++ gpc/p/lang.c 2005-11-18 15:29:10.730506856 +0100 @@ -663,8 +663,9 @@ call_gpcpp (const char * filename, FILE fclose (fi); if (!co->print_deps) gpcpp_writeout (gpcpp_out_fname, gpcpp_out_stream); + else + fclose (gpcpp_out_stream);
- fclose (gpcpp_out_stream); exit (EXIT_SUCCESS); }
On Fri, 18 Nov 2005, Adriaan van Os wrote:
Mirsad Todorovac wrote:
Hello, Adriaan,
Are there some special instructions/requirements to make GPC work on Mac OS X (Darwin) box?
I remember ``make bootstrap'' was required, but last time I tried it was not sufficient for a successful build. Any patch needed?
If you download the sources from my website http://www.microbizz.nl/gpc.html, you will find full building instructions and needed patches for Mac OS X 10.3 and 10.4 included in http://www.microbizz.nl/gpc344d2.src.tar.bz2.
Thank you, I will try that.
Regards, Mirsad T.
Waldek Hebisch a écrit:
Maurice Lombardi wrote:
Prof A Olowofoyeku (The African Chief) a écrit:
- gcc-3.3.5 backend - several failures - see attached log
Very similar for DJGPP. Seems to be related to Windows/DOS target peculiarities
Only one failure with gcc-3.2.3 fjf1044s.pas with same error mesage as above
Many failures with gcc-3.3.5 most of them with the same message:
FAIL: adam3i.pas c:/djgpp/b/gnu/build.gcc/gcc/p/test/a.out: error when trying to erase internal file `f' (Permission denied (EACCES)) (error #474 at 18f5)
see attached log
It seems that the message comes from RTS procedure Unlink (in files.pas 758) The culprit may be OSDosFlag (if it is false). In turn OSDosFlag depends on __OS_DOS__ beeing defined. __OS_DOS__ was defined in gpcpp by a special hack, which got broken by integrated preprocessor. The following should fix the problem (note that you need to rebuild the RTS for the change to be effective):
diff -up gpc-20051116/p/gpcpp.c gpc/p/gpcpp.c --- gpc-20051116/p/gpcpp.c 2005-11-13 16:23:34.000000000 +0100 +++ gpc/p/gpcpp.c 2005-11-17 22:23:21.121088472 +0100 @@ -1257,11 +1257,13 @@ gpcpp_process_options (int argc, char ** int c; char *p = pend_defs[i]; make_definition (p, pend_defs_case_sensitive[i]); +#ifndef GCC_3_3 if ((!strncmp (p, "MSDOS", c = 5) || !strncmp (p, "_WIN32", c = 6) || !strncmp (p, "__EMX__", c = 7)) && (p[c] == 0 || p[c] == '=')) make_definition ("__OS_DOS__=1", 1); +#endif } }
diff -up gpc-20051116/p/lang.c gpc/p/lang.c --- gpc-20051116/p/lang.c 2005-11-16 05:48:36.000000000 +0100 +++ gpc/p/lang.c 2005-11-17 22:23:53.523162608 +0100 @@ -447,7 +447,15 @@ static void builtin_define_std (const ch static void do_def (const char *s) {
- int c; make_definition (s, 1);
+#ifdef GCC_3_3
- if ((!strncmp (s, "MSDOS", c = 5) ||
!strncmp (s, "_WIN32", c = 6) ||!strncmp (s, "__EMX__", c = 7))&& (s[c] == 0 || s[c] == '='))- make_definition ("__OS_DOS__=1", 1);
+#endif #if 0 if (co->print_needed_options) fprintf (stderr, "-D%s ", s);
With this patch and the one on lang-specs.h DJGPP compiles with gcc-3.4.4 backend and gives NO error on the test suite:
Test Run By dosuser on 2005-11-18 12:24:11 Native configuration is djgpp (KNAUTIE)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: fjf165a.pas UNSUPPORTED: longr2.pas
=== gpc Summary ===
# of tests 4969 # of expected passes 4967 # of unsupported tests 2
/djgpp/b/gnu/build.gcc/gcc/xgpc version 20051116, based on gcc-3.4.4
I have also checked that some of my programs which need CPP_PREDEFINES run OK now.
No more need to stick with gcc-3.2.3 now.
I have thus uploaded it in the usual place
http://gnu-pascal.de/contrib/maurice/gpc-20051116-gcc-344.i586-pc-msdosdjgpp...
Very good job !!!
Maurice
On 17 Nov 2005 at 16:20, Waldek Hebisch wrote:
Prof A Olowofoyeku wrote:
- gcc-3.3.5 backend - several failures - see attached log
Most (if not all) seem to be related to predefines. Gpc had a workaround which should be not needed with integrated preprocessor, so I have disable it.
If yo change 0 to 1 in the snippet below (from lang.c line 448):
static void do_def (const char *s) { make_definition (s, 1); #if 0 if (co->print_needed_options) fprintf (stderr, "-D%s ", s); #endif }
the workaround will be active again.
Fixes the problem. After running the testsuite again, there are only 3 failures:
TEST avo7.pas: ./avo7.pas:5: warning: identifiers should not start with an underscore failed
TEST prep1a.pas: f:/mingw/lib/libmingw32.a(main.o)(.text+0x106):main.c: undefined reference to `WinMain@16' collect2: ld returned 1 exit status failed compile: prep1a.pas
TEST prep2p.pas: 13a14,16
_cdecl _fastcall _stdcall
failed
Each of these compiles and runs correctly if compiled directly - e.g. "gpc prep1a.pas" works.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
On 17 Nov 2005 at 21:55, Waldek Hebisch wrote:
Maurice Lombardi wrote:
Prof A Olowofoyeku (The African Chief) a écrit:
- gcc-3.3.5 backend - several failures - see attached log
Very similar for DJGPP. Seems to be related to Windows/DOS target peculiarities
Only one failure with gcc-3.2.3 fjf1044s.pas with same error mesage as above
Many failures with gcc-3.3.5 most of them with the same message:
FAIL: adam3i.pas c:/djgpp/b/gnu/build.gcc/gcc/p/test/a.out: error when trying to erase internal file `f' (Permission denied (EACCES)) (error #474 at 18f5)
see attached log
It seems that the message comes from RTS procedure Unlink (in files.pas 758) The culprit may be OSDosFlag (if it is false). In turn OSDosFlag depends on __OS_DOS__ beeing defined. __OS_DOS__ was defined in gpcpp by a special hack, which got broken by integrated preprocessor. The following should fix the problem (note that you need to rebuild the RTS for the change to be effective):
[....]
These patches solve the problem.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
On Fri, 18 Nov 2005, Waldek Hebisch wrote: [..]
Yes, the following is better:
--- gpc/p/lang.c.bb2 2005-11-18 03:45:51.000000000 +0100 +++ gpc/p/lang.c 2005-11-18 15:29:10.730506856 +0100 @@ -663,8 +663,9 @@ call_gpcpp (const char * filename, FILE fclose (fi); if (!co->print_deps) gpcpp_writeout (gpcpp_out_fname, gpcpp_out_stream);
- else
- fclose (gpcpp_out_stream);
- fclose (gpcpp_out_stream); exit (EXIT_SUCCESS);
}
For some reason or another patch here didn't like the 3rd line so added the "else" with an editor.
results:
# of tests 4969 # of expected passes 4968 # of unsuported tests 1
Good job. Russ
--- gpc/p/lang.c.bb2 2005-11-18 03:45:51.000000000 +0100 +++ gpc/p/lang.c 2005-11-18 15:29:10.730506856 +0100 @@ -663,8 +663,9 @@ call_gpcpp (const char * filename, FILE fclose (fi); if (!co->print_deps) gpcpp_writeout (gpcpp_out_fname, gpcpp_out_stream);
- else
- fclose (gpcpp_out_stream);
- fclose (gpcpp_out_stream); exit (EXIT_SUCCESS);
}
It looks like the semicolon needs to be removed from the line preceding the added else to me... Peter.
Peter N Lewis wrote:
--- gpc/p/lang.c.bb2 2005-11-18 03:45:51.000000000 +0100 +++ gpc/p/lang.c 2005-11-18 15:29:10.730506856 +0100 @@ -663,8 +663,9 @@ call_gpcpp (const char * filename, FILE fclose (fi); if (!co->print_deps) gpcpp_writeout (gpcpp_out_fname, gpcpp_out_stream);
- else
- fclose (gpcpp_out_stream);
- fclose (gpcpp_out_stream); exit (EXIT_SUCCESS);
}
It looks like the semicolon needs to be removed from the line preceding the added else to me...
Nope, that is C code ...
Frank
Hi
With gcc-3.3.5 backend under Mingw, I get the following:
TEST fjf1044s.pas: ./fjf1044s.pas: In procedure `p': ./fjf1044s.pas:36: internal compiler error: in expand_call, at gcc/calls.c:3110 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. failed
TEST prep1a.pas: $1=gpc -D__BITS_LITTLE_ENDIAN__=1 - D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 - D__NEED_NO_ALIGNMENT__=1 -D__OPTIMIZE__ -Di386 -D__i386 -D__i386__ - D__tune_i386__ -D_WIN32 -DWIN32 -D__WIN32 -D__WIN32__ -DWINNT -D__WINNT -D__WINNT__ -D_X86_=1 -D__stdcall=__attribute__((__stdcall__)) - D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) - D__MSVCRT__ -D__MINGW32__ --unit-path=f:\mingw\bin..\lib\gcc- lib\mingw32\3.3.5\units -I f:\mingw\bin..\lib\gcc- lib\mingw32\3.3.5\units --autobuild -g -O3 -W -Wall -Wno-unused -o a.exe --unit-path=. --unit-path=./../rts --unit-path=./../units -I . -I ./../units --executable-path=. $2=./prep1a.pas failed 1: .\prep1a.inc TEST prep2p.pas: 11a12,13
_cdecl _stdcall
failed
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Waldek Hebisch dixit:
I have put a new gpc snapshot at:
http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20051116.tar.bz2
The weird BSD guys strike again.
I have today merged gcc-3.4-20051115 and gpc-20051116 (with both Message-ID: E1EcXkX-0004mi-00@hera.math.uni.wroc.pl and Message-ID: E1Ed6ro-00056J-00@hera.math.uni.wroc.pl applied) into our gcc branch, which also uses Hiroaki Etoh's SSP (ProPolice) stack protector, and maintains an (otherwise unsup- ported, but I might port that to gcc 4.2 or so) new platform, namely, my operating system MirOS BSD.
I have encountered a couple of errors during the build, which are shown below, as are the patches (didn't touch the RTS though because I was not sure what that warning wants to say me, instead I added -Wno-error for now). Please check my diffs against errors...
I did, though, do this (first) build with gcc-3.4-20050823 and gpc-20050217. Maybe things will solve itself later...
I will also show a testsuite run when I'm through building gcc with itself again twice.
Okay, this is not stock gcc, but maybe you're interested in success stories... especially since this might be the only gpc+ProPolice variant out there (if enabling SSP makes sense at all, don't know but I think Pascal has its own...).
Errors: | .../gcc/p/declarations.c: In function `declare_types': | .../gcc/p/declarations.c:3125: warning: suggest parentheses around && within || | .../gcc/p/declarations.c:3133: warning: suggest explicit braces to avoid ambiguous `else' | .../gcc/p/expressions.c: In function `build_range_check': | .../gcc/p/expressions.c:238: warning: unused variable `side_effects'
| In file included from .../gcc/p/gpc-lex.c:50: | <stdin>:114: warning: no previous prototype for 'yyxrealloc'
Yeah, this is generated. Probably a problem in the template. I didn't regenerate it with our lex(1).
| In file included from .../gcc/p/predef.c:31: | .../gcc/p/rts/constants.def:1:1: C++ style comments are not allowed in ISO C90 | .../gcc/p/rts/constants.def:1:1: (this will be reported only once per input file)
Handled with -std=gnu99
| .../gcc/p/predef.c: In function `build_new_dispose': | .../gcc/p/predef.c:2919: warning: 't' might be used uninitialized in this function | In file included from .../gcc/p/statements.c:33: | .../gcc/p/rts/constants.def:1:1: C++ style comments are not allowed in ISO C90 | .../gcc/p/rts/constants.def:1:1: (this will be reported only once per input file)
see above
| .../gcc/dbxout.c: In function `dbxout_type_methods': | .../gcc/dbxout.c:1011: warning: unused variable `type_encoding' | .../gcc/p/rts/string1.pas: In function `Integer2StringBaseExt': | .../gcc/p/rts/string1.pas:827: warning: Comparison always yields `False' due to limited range of data type. | .../gcc/p/rts/string1.pas:827: warning: Operand with side-effects is not evaluated. | .../gcc/p/rts/string1.pas:829: warning: Comparison always yields `False' due to limited range of data type. | .../gcc/p/rts/string1.pas:829: warning: Operand with side-effects is not evaluated.
Diff (might not apply cleanly against stock gpc): Index: dbxout.c =================================================================== RCS file: /cvs/gcc/gcc/dbxout.c,v retrieving revision 1.3 diff -u -p -r1.3 dbxout.c --- dbxout.c 20 Nov 2005 13:21:51 -0000 1.3 +++ dbxout.c 20 Nov 2005 17:47:04 -0000 @@ -1008,7 +1008,9 @@ dbxout_type_methods (tree type) { /* C++: put out the method names and their parameter lists */ tree methods = TYPE_METHODS (type); +#ifndef GPC tree type_encoding; +#endif tree fndecl; tree last; #ifndef GPC Index: p/Make-lang.in =================================================================== RCS file: /cvs/gcc/gcc/p/Make-lang.in,v retrieving revision 1.13 diff -u -p -r1.13 Make-lang.in --- p/Make-lang.in 20 Nov 2005 12:28:11 -0000 1.13 +++ p/Make-lang.in 20 Nov 2005 17:47:06 -0000 @@ -319,10 +319,10 @@ p/parse.o: $(srcdir)/p/parse.c $(P_H) $(CC) -o $@ -c $(ALL_GPC_FLAGS) $(BIG_SWITCHFLAG) $<
p/predef.o: p/predef.c $(P_H) $(RTSSRCDIR)/constants.def - $(CC) -o $@ -c $(ALL_GPC_FLAGS) $< + $(CC) -o $@ -c $(ALL_GPC_FLAGS) -std=gnu99 $<
p/statements.o: p/statements.c $(P_H) $(RTSSRCDIR)/constants.def $(RTS_VERSION_FILENAME) - $(CC) -o $@ -c $(ALL_GPC_FLAGS) -DRTS_VERSION_CHECK=""_p_GPC_RTS_VERSION_`cat $(RTSSRCDIR)/rts-version`"" $< + $(CC) -o $@ -c $(ALL_GPC_FLAGS) -std=gnu99 -DRTS_VERSION_CHECK=""_p_GPC_RTS_VERSION_`cat $(RTSSRCDIR)/rts-version`"" $<
p/typecheck.o: p/typecheck.c $(P_H) $(CC) -o $@ -c $(ALL_GPC_FLAGS) $< Index: p/declarations.c =================================================================== RCS file: /cvs/gcc/gcc/p/declarations.c,v retrieving revision 1.1.111.2 diff -u -p -r1.1.111.2 declarations.c --- p/declarations.c 20 Nov 2005 12:18:40 -0000 1.1.111.2 +++ p/declarations.c 20 Nov 2005 17:47:07 -0000 @@ -3120,9 +3120,9 @@ declare_types (void) /* Resolve forward types */ for (scan = current_type_list; scan; scan = TREE_CHAIN (scan)) if (TREE_PURPOSE (scan) && (TREE_CODE (TREE_TYPE (TREE_PURPOSE (scan))) == LANG_TYPE - || TREE_CODE (TREE_TYPE (TREE_PURPOSE (scan))) == POINTER_TYPE + || (TREE_CODE (TREE_TYPE (TREE_PURPOSE (scan))) == POINTER_TYPE && PASCAL_TYPE_CLASS (TREE_TYPE (TREE_PURPOSE (scan))) - && TREE_CODE (TREE_TYPE (TREE_TYPE (TREE_PURPOSE (scan)))) == LANG_TYPE)) + && TREE_CODE (TREE_TYPE (TREE_TYPE (TREE_PURPOSE (scan)))) == LANG_TYPE))) { tree otype = TREE_TYPE (TREE_PURPOSE (scan)); tree decl = lookup_name (TREE_VALUE (scan)), type; @@ -3130,7 +3130,7 @@ declare_types (void) if (decl && TREE_CODE (decl) == TYPE_DECL) { type = TREE_TYPE (decl); - if (is_class) + if (is_class) { if (TREE_CODE (type) == POINTER_TYPE && PASCAL_TYPE_CLASS (type)) { type = TREE_TYPE (type); @@ -3150,6 +3150,7 @@ declare_types (void) IDENTIFIER_NAME (TREE_VALUE (scan))); type = void_type_node; } + } } else if (is_class) { Index: p/expressions.c =================================================================== RCS file: /cvs/gcc/gcc/p/expressions.c,v retrieving revision 1.1.111.2 diff -u -p -r1.1.111.2 expressions.c --- p/expressions.c 20 Nov 2005 12:18:40 -0000 1.1.111.2 +++ p/expressions.c 20 Nov 2005 17:47:07 -0000 @@ -235,7 +235,7 @@ build_range_check(tree min, tree max, tr NULL_TREE), expr), expr)); return t; #else - int side_effects = TREE_SIDE_EFFECTS (expr); + int side_effects __attribute__((unused)) = TREE_SIDE_EFFECTS (expr); tree cond, tv, t; tree tmpvar = make_new_variable ("range_check", TREE_TYPE (expr)); tv = build (MODIFY_EXPR, TREE_TYPE (expr), tmpvar, expr); Index: p/pascal-lex.c =================================================================== RCS file: /cvs/gcc/gcc/p/pascal-lex.c,v retrieving revision 1.2 diff -u -p -r1.2 pascal-lex.c --- p/pascal-lex.c 20 Nov 2005 13:45:42 -0000 1.2 +++ p/pascal-lex.c 20 Nov 2005 17:47:07 -0000 @@ -635,6 +635,7 @@ yyalloc (yy_size_t size) #endif
#ifndef yyxrealloc +void *yyxrealloc (void *p, yy_size_t size); void * yyxrealloc (void *p, yy_size_t size) { Index: p/predef.c =================================================================== RCS file: /cvs/gcc/gcc/p/predef.c,v retrieving revision 1.1.111.2 diff -u -p -r1.1.111.2 predef.c --- p/predef.c 20 Nov 2005 12:18:42 -0000 1.1.111.2 +++ p/predef.c 20 Nov 2005 17:47:07 -0000 @@ -2916,7 +2916,7 @@ build_new_dispose (int r_num, tree arg1, /* Objects, the interesting case */ if (is_object) { - tree t; + tree t = NULL_TREE /* please gcc */; if (r_num == p_New) { if (PASCAL_TYPE_CLASS (TREE_TYPE (arg1))) Index: p/rts/Makefile.in =================================================================== RCS file: /cvs/gcc/gcc/p/rts/Makefile.in,v retrieving revision 1.5 diff -u -p -r1.5 Makefile.in --- p/rts/Makefile.in 20 Nov 2005 12:28:14 -0000 1.5 +++ p/rts/Makefile.in 20 Nov 2005 17:47:07 -0000 @@ -59,7 +59,7 @@ PFLAGS1=--unit-path=$(VPATH) --automake RTS_WARN=-W -Wall -Wmissing-prototypes -Wmissing-declarations RTS_CFLAGS=-I. $(RTS_WARN) $(CFLAGS) $(RTSFLAGS)# -DDEBUG RTS_PFLAGS=$(subst -Wformat,,$(RTS_CFLAGS)) $(PFLAGS) $(PFLAGS1) `cat needed-options` \ - -DRTS_RELEASE_STRING="'$(rts_version)'" -DGCC_VERSION="'$(GCC_VERSION)'" + -DRTS_RELEASE_STRING="'$(rts_version)'" -DGCC_VERSION="'$(GCC_VERSION)'" -Wno-error
PAS_SRC=rtsc.pas string1.pas error.pas heap.pas string2.pas time.pas random.pas \ fname.pas files.pas getopt.pas sets.pas math.pas endian.pas move.pas init.pas
bye, //mirabile
Dixi:
I will also show a testsuite run when I'm through building gcc with itself again twice.
Looks much better than in Message-ID: Pine.BSO.4.61L.0503290052520.22448@odem.66h.42h.de
I've since addressed the -ftrampolines issue (they are now always enabled in Pascal, maybe I should issue warnings? but their output might disturb the testsuite) but left the ProPolice stack protector active (until further input from you guys whether it's necessary).
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 tg on 2005-11-20 21:43:01 Native configuration is i386-ecce-mirbsd8 (odem.66h.42h.de)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas UNSUPPORTED: fjf165a.pas UNSUPPORTED: gmptest.pas FAIL: gpctest.pas UNSUPPORTED: longr2.pas FAIL: mir047h.pas
=== gpc Summary ===
# of tests 4969 # of expected passes 4961 # of unexpected failures 2 # of unsupported tests 6
gpc version 20051116, based on gcc-3.4.5 20051115 (propolice; MirOS 083A)
What fails?
| TEST mir047h.pas: O[1] Segmentation fault ./"${A_OUT}" "${1}"
Uh, no idea. syslogd(8) says: Nov 20 22:02:16 odem /bsd: signal 11 received by (a.out:28823) UID(2999) EUID(2999), parent (sh:26332) UID(2999) EUID(2999)
Not a ProPolice abort, they look different.
| TEST gpctest.pas: 86400 | 0 | 943841988 | True | True | 1999 1999 | 11 11 | 29 29 | 1 1 | 2 2 | 19 19 | 26 48
22 seconds strike again: leap seconds, I suppose. Didn't we talk about it earlier this year?
| 0 0 | Error in UnixTimeToTimeStamp
bye, //mirabile
Dixi:
I have today merged gcc-3.4-20051115 and gpc-20051116 (with both Message-ID: E1EcXkX-0004mi-00@hera.math.uni.wroc.pl and Message-ID: E1Ed6ro-00056J-00@hera.math.uni.wroc.pl applied) into our gcc branch, which also uses Hiroaki Etoh's SSP
[...]
I've hacked a bit on the infrastructure, and after building our gcc with Apple's gcc, I could rebuild it with itself then Pascal didn't ICE building the RTS (figured that out before Adriaan's answer made it to my INBOX, but thanks nonetheless). These are the results:
Test Run By tglaser on 2005-11-22 22:20:52 Native configuration is powerpc-apple-darwin8.2.0 (g4.gecko.ig3.net)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas UNSUPPORTED: asmtest.pas UNSUPPORTED: fjf165a.pas FAIL: fjf998r.pas UNSUPPORTED: gmptest.pas UNSUPPORTED: longr2.pas FAIL: mir047h.pas FAIL: prep2p.pas FAIL: systemtest.pas [...] gpc version 20051116, based on gcc-3.4.5 20051115 (propolice; MirOS 083A)
Snippets:
| TEST fjf998q.pas: OK | TEST fjf998r.pas: failed: | TEST fjf998s.pas: OK
uh?
| TEST mir047h.pas: OK | ./test_run: line 345: 10690 Bus error ./"$A_OUT" "$1" | TEST mir048a.pas: OK
Looks familiar - the same problem shows up on i386-ecce-mirbsd8. May be a stack protector issue?
| TEST prep2p.pas: 0a1,2 | > _ARCH_PPC | > _BIG_ENDIAN | 1a4 | > __BIG_ENDIAN__ | failed
I think you already know this.
| TEST systemtest.pas: a.out(2075) malloc: *** vm_allocate(size=2147483648) failed (error code=3) | a.out(2075) malloc: *** error: can't allocate region | a.out(2075) malloc: *** set a breakpoint in szone_error to debug | a.out(2075) malloc: *** vm_allocate(size=2147483648) failed (error code=3) | a.out(2075) malloc: *** error: can't allocate region | a.out(2075) malloc: *** set a breakpoint in szone_error to debug | OK
No idea, I don't know anything about Macintoshes (that's just a shell account I have at a friend's box).
I'll now look whether just doing a make bootstrap is enough to circumvent the Apple GCC brokenness.
//mirabile
i386-ecce-mirbsd8:
| TEST mir047h.pas: O[1] Segmentation fault ./"${A_OUT}" "${1}"
Uh, no idea. syslogd(8) says: Nov 20 22:02:16 odem /bsd: signal 11 received by (a.out:28823) UID(2999) EUID(2999), parent (sh:26332) UID(2999) EUID(2999)
Not a ProPolice abort, they look different.
powerpc-apple-darwin8.2.0: | TEST mir047h.pas: OK | ./test_run: line 345: 10690 Bus error ./"$A_OUT" "$1"
I get the same output when running with -fno-stack-protector, so it (ought to) be something else indeed.
bye, //mirabile
PS: Just for clarification, this is our local (MirOS) version of GCC, based upon FSF's gcc 3.4.5(prerelease), ProPolice, GPC diffs, our own diffs, and support for a new platform (MirOS BSD). Feel free to blame these problems on me (or the OpenBSD guys).
Thorsten Glaser wrote:
uh?
| TEST mir047h.pas: OK | ./test_run: line 345: 10690 Bus error ./"$A_OUT" "$1" | TEST mir048a.pas: OK
Looks familiar - the same problem shows up on i386-ecce-mirbsd8. May be a stack protector issue?
Probably, this one is new to me (doesn't happen with fsf-gcc).
| TEST prep2p.pas: 0a1,2 | > _ARCH_PPC | > _BIG_ENDIAN | 1a4 | > __BIG_ENDIAN__ | failed
I think you already know this.
Yes.
| TEST systemtest.pas: a.out(2075) malloc: *** vm_allocate(size=2147483648) failed (error code=3) | a.out(2075) malloc: *** error: can't allocate region | a.out(2075) malloc: *** set a breakpoint in szone_error to debug | a.out(2075) malloc: *** vm_allocate(size=2147483648) failed (error code=3) | a.out(2075) malloc: *** error: can't allocate region | a.out(2075) malloc: *** set a breakpoint in szone_error to debug | OK
No idea, I don't know anything about Macintoshes (that's just a shell account I have at a friend's box).
Just a stupid bug in the kernel.
Regards
Adriaan van Os
Adriaan van Os dixit:
Thorsten Glaser wrote:
| TEST mir047h.pas: OK | ./test_run: line 345: 10690 Bus error ./"$A_OUT" "$1" | TEST mir048a.pas: OK
Looks familiar - the same problem shows up on i386-ecce-mirbsd8. May be a stack protector issue?
Probably, this one is new to me (doesn't happen with fsf-gcc).
Yup. Since it does happen on i386, I guess it's somehow related to ProPolice. Maybe there is actually a buffer overflow in somewhere?
[...]
Just a stupid bug in the kernel.
Thanks.
bye, //mirabile
Thorsten Glaser wrote:
Adriaan van Os dixit:
Thorsten Glaser wrote:
| TEST mir047h.pas: OK | ./test_run: line 345: 10690 Bus error ./"$A_OUT" "$1" | TEST mir048a.pas: OK
Looks familiar - the same problem shows up on i386-ecce-mirbsd8. May be a stack protector issue?
Probably, this one is new to me (doesn't happen with fsf-gcc).
Yup. Since it does happen on i386, I guess it's somehow related to ProPolice. Maybe there is actually a buffer overflow in somewhere?
Well, you can see what gdb tells you. And on the Mac you can look in ~/Library/Logs/CrashReporter/a.out.crash.log.
Regards,
Adriaan van Os
Adriaan van Os dixit:
Well, you can see what gdb tells you.
My gdb skills are limited...
Program received signal SIGSEGV, Segmentation fault. 0x08248b92 in _p_Write_String () from /usr/lib/libgpc.so.2.1 Current language: auto; currently c (gdb) bt #0 0x08248b92 in _p_Write_String () from /usr/lib/libgpc.so.2.1 #1 0x1c0009ea in main program () at ./mir047h.pas:41 #2 0x1c000ab3 in main (argc=1, argv=0xcfbf12d0, envp=0xcfbf12d8) at <implicit code>:43
bye, //mirabile
Thorsten Glaser wrote:
Adriaan van Os dixit:
Well, you can see what gdb tells you.
My gdb skills are limited...
Program received signal SIGSEGV, Segmentation fault. 0x08248b92 in _p_Write_String () from /usr/lib/libgpc.so.2.1 Current language: auto; currently c (gdb) bt #0 0x08248b92 in _p_Write_String () from /usr/lib/libgpc.so.2.1 #1 0x1c0009ea in main program () at ./mir047h.pas:41 #2 0x1c000ab3 in main (argc=1, argv=0xcfbf12d0, envp=0xcfbf12d8) at <implicit code>:43
This is weird, because the testsuite indicated a bus error, rather than a segmentation fault (as if the bus error was caused by an exception handler that is now intercepted by gdb). It could be a stack problem.
Anyway, I merged the IBM pro police stack detector http://www.research.ibm.com/trl/projects/security/ssp/ patches for gcc-3.4.4 <http://www.research.ibm.com/trl/projects/security/ssp/gcc3_4_4/ protector-3.4.4-1.tar.gz> with gcc-3.4.4 and gpc-20051116 and then configured with --enable-protector to activate the stack protector by default.
[G5:gcc/p/test] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc344d7/lib/gcc/powerpc-apple-darwin7/3.4.4/specs Configured with: ../gcc-3.4.4/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin7 --host=powerpc-apple-darwin7 --build=powerpc-apple-darwin7 --enable-protector --prefix=/Developer/Pascal/gpc344d7 Thread model: posix gpc version 20051116, based on gcc-3.4.4
There were no unexpected testsuite failures. So, if you need the stack detector, I suggest to use the gcc-3.4.4 release rather than the gcc-3.4.5 20051115 snapshot. But I don't know if the stack detector automatically also works for Pascal (maybe Waldek can say).
Regards,
Adriaan van Os
Adriaan van Os dixit:
Thorsten Glaser wrote:
Adriaan van Os dixit:
Well, you can see what gdb tells you.
My gdb skills are limited...
Program received signal SIGSEGV, Segmentation fault. 0x08248b92 in _p_Write_String () from /usr/lib/libgpc.so.2.1 Current language: auto; currently c (gdb) bt #0 0x08248b92 in _p_Write_String () from /usr/lib/libgpc.so.2.1 #1 0x1c0009ea in main program () at ./mir047h.pas:41 #2 0x1c000ab3 in main (argc=1, argv=0xcfbf12d0, envp=0xcfbf12d8) at <implicit code>:43
This is weird, because the testsuite indicated a bus error, rather than a
No, that was on i386. It's been easier for me to test on my local box than to ssh to the Macintosh again ;)
segmentation fault (as if the bus error was caused by an exception handler that is now intercepted by gdb). It could be a stack problem.
There were no unexpected testsuite failures.
Interesting. So it might be something else after all. Any gdb wizard here? I've only ever used DEBUG.COM and Borland's Turbo Debugger 1.0 for DOS in the past...
But I don't know if the stack detector automatically also works for Pascal (maybe Waldek can say).
I disabled it for Ada because they have their own system (which even conflicts with it), but didn't do it (yet) for Pascal, because I don't know if it can catch some (corner?) cases which the integrated checks (like {$R+,S+} etc.) don't find. I'm waiting for a response from the GPC wizards regarding this ;)
On a side note, ProPolice was redesigned and then integrated into gcc 4.1, so for the gpc port to gcc4 this might be interesting too.
bye, //mirabile
Thorsten Glaser wrote:
Adriaan van Os dixit:
But I don't know if the stack detector automatically also works for Pascal (maybe Waldek can say).
I disabled it for Ada because they have their own system (which even conflicts with it), but didn't do it (yet) for Pascal, because I don't know if it can catch some (corner?) cases which the integrated checks (like {$R+,S+} etc.) don't find. I'm waiting for a response from the GPC wizards regarding this ;)
For Extended Pascal range checking should catch all out of range indices, hence all buffer overflows. If some is not detected then this is a compiler bug. But gpc has bugs, so I would not exlude possibility of bug in range checking.
More important is that gpc allows various extensions and inline directives. {$R-} turns range checking off. {$pointer-arithmetic} turns on C-like pointer arithmetic. Also, gpc range checking assumes that inputs are in range, so for example in the program below:
program arrb; type ind = 1..5; var t: array [ind] of char; i : ind; function i20 : integer; begin i20 := 20; end; begin {$R-} i := i20; {$R+} t[i] := 'a'; end.
out of range access is not detected. So, gpc make checking convenient, but there is still a lot of room for human errors.
Testsuite results on i386-apple-darwin with gpc-20051116 and gcc-3.4.5. I applied the previously posted fixes for gpc-20051116 and made minor changes to the patches needed for gcc-3.4.4 on i386-apple-darwin.
[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-16 09:10:23 Native configuration is i386-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 4969 # of expected passes 4963 # of unexpected failures 1 # of unsupported tests 5
gpc version 20051116, based on gcc-3.4.5
Regards,
Adriaan van Os
-
Adriaan van Os -
Frank Heckenbach -
James A. Morrison -
Maurice Lombardi -
Mirsad Todorovac -
Peter N Lewis -
Prof A Olowofoyeku (The African Chief) -
Russell Whitaker -
Thorsten Glaser -
Waldek Hebisch