Prof A Olowofoyeku (The African Chief) wrote:

On 15 Feb 2006 at 4:39, Waldek Hebisch wrote:

...

I have put a new gpc snapshot at:

http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20060215.tar.bz2

[...] Generates an ICE in my OOP framework (Mingw, based on gcc-3.4.5).

"cwindows.pas:345: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.mingw.org/bugs.shtml for instructions. gpc1.exe: gpc exited with status 1"

This one has me stumped! It happens even when I pas "-S" or "-fsyntax- only".

AFAICS, there is no reason why there should be an ICE. The ICE happens in the interface section of a unit, in the middle of object declarations. The code has compiled under all GPC versions for the past 3 years or so (including 20051116), and under Delphi, Virtual Pascal, and FreePascal. It is valid Pascal code, and, AFAICS, the declarations do not contain any errors that should cause even a compiler error, least of all an ICE.

I am still trying to reduce the problem to a small program, but so far, I am not succeeding.

With this data I can not give any specific advice. But generally in similar cases I use debugger just on original testcase. You need to start a debugger (say gdb) on the compiler proper (gpc1.exe) and give it correct arguments (running gpc -v will tell you which one). The debugger will (assuming that you have compiled your gpc with debugging support, which is a default) tell you offending line number and its file. In gdb typing `bt' will give you a backtrace (the whole call chain with arguments).

BTW. When testing gpc it us usefull to give `--enable-checking' option to `configure' -- the compiler build in such way performs extra internal checks (the checks make the compiler slower and larger, so they are disabled by default).

Prof A Olowofoyeku (The African Chief) wrote:

Unfortunately, running gpc1 directly (either in gdb or outside of it, with or without parameters) causes an ICE. "gpc -v" doesn't tell me how to run gpc1 correctly.

One thing about terminology: "true" ICE is when the compiler detects an error and writes error message. Those messages normally include exact source location (line number and file) of the error, which helps quite a lot in fixing them. Another thing is segmentation fault. If you get segmentation fault it means that you can reporduce the bug inside debugger. The debugger should catch the fault, you can then type `bt' to get the bactrace. It is possible that mingw is doing something strange, so that the segmentation fault is caught by gpc1.exe, then you need to set breakpoint inside `internal_error': break internal_error

Also, it is possible that you get an error deeply inside automake. The simplest way then is to find which unit is crashing, compile all its imports with `--interface-only' and then try to compile the causing the crash. By the way: the crash may be in automake machinery (what you wrote suggest otherwise, by just in case I will mention this). Then you need to give `-fautomake' option to gpc1.exe, and additionaly -famtmpfile=fooo option (where `fooo' is a name of existing empty file).

One general remark: when you give an option with to dashes to gpc, you need to use `-f' to gpc1. For example: `--objects-are-references' has to be written as `-fobjects-are-references'. gpc accepts both versions, but convets the first ionto the second one. gpc1 accepts only the second version.

Prof A Olowofoyeku (The African Chief) wrote:

On 17 Feb 2006 at 4:17, Waldek Hebisch wrote:

...

Also, it is possible that you get an error deeply inside automake. The simplest way then is to find which unit is crashing, compile all its imports with `--interface-only' and then try to compile the causing the crash. By the way: the crash may be in automake machinery (what you wrote suggest otherwise, by just in case I will mention this). Then you need to give `-fautomake' option to gpc1.exe, and additionaly -famtmpfile=fooo option (where `fooo' is a name of existing empty file).

One general remark: when you give an option with to dashes to gpc, you need to use `-f' to gpc1. For example: `--objects-are-references' has to be written as `-fobjects-are-references'. gpc accepts both versions, but convets the first ionto the second one. gpc1 accepts only the second version.

Thanks. I tried used "-f", and this is the result from gdb:

(gdb) run -fautomake -fextended-syntax -fignore-function-results -fno- io-checking -fno-stack-checking -fimplicit-result -fdelphi-method- shadowing -fexecutable-file-name example2.pas Starting program: f:/mingw/libexec/gcc/mingw32/3.4.5/gpc1.exe - fautomake -fextended-syntax -fignore-function-results -fno-io-checking - fno-stack-checking -fimplicit-result -fdelphi-method-shadowing - fexecutable-file-name example2.pas ../../gcc/p/module.c:1210:find_automake_tempfile_entry: failed assertion `automake_temp_filename' example2.pas:27: error: Internal compiler error. Please submit a full bug report to the GPC mailing list gpc@gnu.de. See URL:http://www.gnu-pascal.de/todo.html for details.

Program exited with code 01. (gdb) bt No stack. (gdb)

Omit `-fautomake' from the command line (if needed compile all imported units first, using `--interface-only' to avoid problems with cyclic imports). If you really need automake (that is crash is inside automake machinery) then my remark about `-famtmpfile=fooo' applies (the gpc1 executable issues the message above when `-fautomake' is given without `-famtmpfile=fooo').

Prof A Olowofoyeku (The African Chief) wrote:

This is the result:

(gdb) run -famtmpfile=foo -fautomake -fextended-syntax -fignore- function-results -fno-io-checking -fno-stack-checking -fimplicit-result -fdelphi-method- shadowin g cwindows.pas Starting program: f:/mingw/libexec/gcc/mingw32/3.4.5/gpc1.exe - famtmpfile=foo -f automake -fextended-syntax -fignore-function-results -fno-io-checking - fno-stack -checking -fimplicit-result -fdelphi-method-shadowing cwindows.pas

Program received signal SIGSEGV, Segmentation fault. yyprocessOneStack (yystack=0x174fde0, yyk=0, yyposn=1999, yylvalp=0x80c010, yyllocp=0x80c014) at parse.c:8436 8436 parse.c: No such file or directory. in parse.c (gdb) bt #0 yyprocessOneStack (yystack=0x174fde0, yyk=0, yyposn=1999, yylvalp=0x80c010, yyllocp=0x80c014) at parse.c:8436 #1 0x00410f23 in main_yyparse () at parse.c:9345 #2 0x005147be in toplev_main (argc=10, argv=0x122490) at ../../gcc/toplev.c:1822 #3 0x0054f06a in main (argc=10, argv=0x122490) at ../../gcc/main.c:35 (gdb)

Could you at this point print a few relevanat variables:

print yystack->yyspaceLeft

print (yystack->yynextFree - yystack->yyitems)

On 19 Feb 2006 at 22:41, Waldek Hebisch wrote:

Prof A Olowofoyeku (The African Chief) wrote:

...

This is the result:

(gdb) run -famtmpfile=foo -fautomake -fextended-syntax -fignore- function-results -fno-io-checking -fno-stack-checking -fimplicit-result -fdelphi-method- shadowin g cwindows.pas Starting program: f:/mingw/libexec/gcc/mingw32/3.4.5/gpc1.exe - famtmpfile=foo -f automake -fextended-syntax -fignore-function-results -fno-io-checking

• fno-stack -checking -fimplicit-result -fdelphi-method-shadowing

cwindows.pas

Program received signal SIGSEGV, Segmentation fault. yyprocessOneStack (yystack=0x174fde0, yyk=0, yyposn=1999, yylvalp=0x80c010, yyllocp=0x80c014) at parse.c:8436 8436 parse.c: No such file or directory. in parse.c (gdb) bt #0 yyprocessOneStack (yystack=0x174fde0, yyk=0, yyposn=1999, yylvalp=0x80c010, yyllocp=0x80c014) at parse.c:8436 #1 0x00410f23 in main_yyparse () at parse.c:9345 #2 0x005147be in toplev_main (argc=10, argv=0x122490) at ../../gcc/toplev.c:1822 #3 0x0054f06a in main (argc=10, argv=0x122490) at ../../gcc/main.c:35 (gdb)

Could you at this point print a few relevanat variables:

print yystack->yyspaceLeft

$1 = 4294966881

print (yystack->yynextFree - yystack->yyitems)

$2 = 10415

I hope this makes sense to you!

Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

On 15 Feb 2006 at 16:24, Waldek Hebisch wrote:

[...]

BTW. When testing gpc it us usefull to give `--enable-checking' option to `configure' -- the compiler build in such way performs extra internal checks (the checks make the compiler slower and larger, so they are disabled by default).

This doesn't advance the situation very much - I still can't find the source of the problem.

On the positive side, the snapshot passes the testsuite, with only these problems:

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):main.c:(.text+0x106): undefined reference to `WinMain@16' collect2: ld returned 1 exit status failed compile: prep1a.pas

This one is spurious, because the `WinMain@16' complaint is unrelated to GPC.

Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

On 17 Feb 2006 at 4:42, Waldek Hebisch wrote:

Prof A Olowofoyeku (The African Chief) wrote:

...

On 15 Feb 2006 at 16:24, Waldek Hebisch wrote:

[...]

...

BTW. When testing gpc it us usefull to give `--enable-checking' option to `configure' -- the compiler build in such way performs extra internal checks (the checks make the compiler slower and larger, so they are disabled by default).

This doesn't advance the situation very much - I still can't find the source of the problem.

On the positive side, the snapshot passes the testsuite, with only these problems:

TEST avo7.pas: ./avo7.pas:5: warning: identifiers should not start with an underscore failed

For this one we have to modify the C compiler. I you type: gpc -v --gnu-pascal -Wno-underscore avo7.pas

I see:

Reading specs from /usr/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.4/specs

as the first line. The specs file should contain the following blob: *cc1_options: %{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}} %1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*} %{c|S:%{o*:-auxbase-strip %*}%{!o*:-auxbase %b}}%{!c:%{!S:-auxbase %b}} %{g*} %{O*} %{f*&W*&pedantic*&w} %{std*&ansi&trigraphs} %{v:-version} %{pg:-p} %{p} %{undef} %{Qn:-fno-ident} %{--help:--help} %{--target-help:--target-help} %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}} %{fsyntax-only:-o %j} %{-param*}

where the `%{f*&W*&pedantic*&w}' part is the crucial one

I can see it - but I'd rather leave it alone. I am not sure whether anything else in Mingw relies on it ...

...

TEST prep1a.pas: f:/mingw/lib/libmingw32.a(main.o):main.c:(.text+0x106): undefined reference to `WinMain@16' collect2: ld returned 1 exit status failed compile: prep1a.pas

This one is spurious, because the `WinMain@16' complaint is unrelated to GPC.

This is most likely problem in the test. But it is not entirely suprious. The intent of the test is to check that running the compiler directly (`gpc.exe') is equivalent to running it in stages. I was mostly concerned with preprocessor here, but additionaly it tests that command line handling works as intended. But apparently on Mingw32 it does not work that way. Most likely, the test is garbling command line (or Mingw32 needs some extra twists), but there is also a tiny chance for compiler bug (maybe the compiler is misunderstanding the command). Could you add `-v' to the compiler options in the `prep1a.cmp' script and post the output?

Adding "-v" to prep1a.cmp added nothing to the equation. I added it to the flags in the make file, and this was the result:

(Mingw)/src/mingw/gcc-3.4.5-20060117-1/gcc/p/test $make MASK="prep1a.pas" 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 -v -O3 -W -Wall -Wno-unused " PFLAGS_NO_PATHS="-g -v -O3 -W -Wall -Wno-unused " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" prep1a.pas | tee test_log | "./test_sum" -d ./test_run: fatal: `--print-needed-options' yields: Reading specs from f:/mingw/bin/../lib/gcc/mingw32/3.4.5/specs Configured with: ../configure --enable-checking --enable- languages=pascal --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 - -target=mingw32 --prefix=/mingw --enable-threads --disable-nls -- disable-win32-registry --disable-shared --enable-sjlj-exceptions -- enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm -- disable-libgcj-debug --enable-interpreter --enable-hash-synchronization Thread model: win32 gpc version 20060215, based on gcc-3.4.5 (mingw special) f:/mingw/bin/../libexec/gcc/mingw32/3.4.5/gpc1.exe -quiet -v -iprefix f:\mingw\bin../lib/gcc/mingw32/3.4.5/ dummy.pas -quiet -dumpbase dummy.pas -auxbase dummy -g -O3 -W -Wall -Wno-unused -version - famtmpfile=f:/temp/ccyKaaaa.gpa -fautobuild -fprint-needed-options -o f:/temp/ccWkbaaa.s GNU Pascal version 20060215, based on gcc-3.4.5 (mingw special) (mingw32) compiled by GNU C version 3.4.5 (mingw special). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Pascal Compiler PreProcessor version 20060215, based on gcc-3.4.5 (mingw special)

Nothing was run.

Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

Maurice Lombardi wrote:

Waldek Hebisch a écrit:

...

I have put a new gpc snapshot at:

http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20060215.tar.bz2

Compiled with DJGPP and gcc 3.4.4 Only one failure for a new test (y2k has no meaning)

Running target any Running testsuite ...

UNSUPPORTED: fjf165a.pas UNSUPPORTED: longr2.pas FAIL: peter8.pas FAIL: y2k.pas

             === gpc Summary ===

# of tests 5057 # of expected passes 5053 # of unexpected failures 2 # of unsupported tests 2

TEST peter8.pas: Exiting due to signal SIGSEGV

Could you narrow down the problem? peter8.pas defines 27 routines and around 20 arguments and tries all combinations of routines and arguments. You can comment out lines loking like `do_tstc (f1);' to choose only specific arguments. You can remove parts of `do_tstc' (and `do_tstc0' and `do_tstc1') macros to test only some routines.

There is also a series of tests checking that arguments are passed by reference (`do_tstr' series), each test two routines (one with `const' argument and one with `const var' argument).

Also, do optimization matter? The routines are small so there is a lot of possibilities for inlining.

BTW. peter8.pas uses macros, but no units, so you can test is separatly in another directory.

Maurice Lombardi wrote:

This is a problem of stack overflow, presumably due to this complexity. The default stack in DJGPP is 512k Increasing it to 2048k makes the problem disappear.

I increase the stack manually in DJGPP by typing

stubedit gpc1.exe minstack=2048K

I have checked that you can do it automatically by including the following lines in peter8.pas immediately after the program header

{$ifdef __GO32__} const MinStackSize: Cardinal = $200000; attribute (name = '_stklen'); {$endif}

(the recipe is somewhere in the gpc docs)

One can easily reduce the memory usage of `peter8.pas'. For example intead of 1000 char size for arrays one could use 250 bytes. Also putting groups of tests in subroutines and calling subroutines should reduce stack usage. But in principle `peter8.pas' should run using just tens of kilobytes of stack space, so the failure can be classified as a bug (but probably an old one). Namely, the calls are independent and the compiler should re-use the stack space used in one call to perfrom another one. But ATM it allows that garbage accumulates and eats large part of the stack and the space can be re-used only when a routine returns. I am not sure how hard will be to fix this. And some programs may depend on this bug.