Hi all,
Since at least three monthes a bug pops in and pops out in an erratic way while running dostest.bat after a new compilation of a gpc snapshot under djgpp-2.95.2 (nothing to do with the recent discussion about 2.95.3: I have reverted to 2.95.2). It is in one or both of the test programs nicola1.pas and/or nicola2.pas. On the screen (and in the make.out logfile) I have:
---------------------------------------------------
Running the GPC Test Suite. This may take a while...
NOTE, if you've used the Test Suite before: To get the long output format, run `make pascal.check-long' now.
TEST fjf165a.pas: SKIPPED: only for German locale TEST longr2.pas: SKIPPED: no LongReal math routines available TEST nicola1.pas: failed: ./nicola1.pas:7: referenced type `T2' undefined ./nicola1.pas:7: Internal compiler error in `handle_forward_pointers', at gpc-de cl.c:9884 Please submit a full bug report to the GPC mailing list gpc@gnu.de. See URL:http://home.pages.de/~GNU-Pascal/todo.html for details. TEST nicola2.pas: failed: ./nicola2.pas:4: referenced type `A' undefined ./nicola2.pas:4: Internal compiler error in `handle_forward_pointers', at gpc-de cl.c:9884 Please submit a full bug report to the GPC mailing list gpc@gnu.de. See URL:http://home.pages.de/~GNU-Pascal/todo.html for details.
# of GPC tests 1302 # of GPC tests passed 1298 # of GPC tests skipped 2 # of GPC tests failed 2
-------------------------------------------------------
If I run the compilation directly I see that this corresponds to a SIGSEGV error
---------------------------------------------------------
C:\djgpp\gnu\gcc-2.952\gcc\p\test>gpc --autobuild -g -O3 -Wall -Werror nicola1.pas nicola1.pas:7: referenced type `T2' undefined Exiting due to signal SIGSEGV Page fault at eip=0015d86d, error=0004 eax=0000007f ebx=ffe305e0 ecx=00000000 edx=ffe527e4 esi=ffe30574 edi=89000001 ebp=00389d30 esp=00389d08 program=C:\DJGPP\LIB\GCC-LIB\DJGPP\2.952\GPC1.EXE cs: sel=0117 base=83c03000 limit=ffe5dfff ds: sel=011f base=83c03000 limit=ffe5dfff es: sel=011f base=83c03000 limit=ffe5dfff fs: sel=00f7 base=000260d0 limit=0000ffff gs: sel=012f base=00000000 limit=0010ffff ss: sel=011f base=83c03000 limit=ffe5dfff App stack: [0038a3a4..0020a3a4] Exceptn stack: [0020a2b0..00208370]
Call frame traceback EIPs: 0x0015d86d 0x001a5bbe 0x0013bad9 0x0013f967 0x001caee2
C:\djgpp\gnu\gcc-2.952\gcc\p\test>gpc --autobuild -g -O3 -Wall -Werror nicola2.pas nicola2.pas:4: referenced type `A' undefined Exiting due to signal SIGSEGV Page fault at eip=0015d86d, error=0004 eax=0000007f ebx=ffe305e0 ecx=00000000 edx=ffe523f0 esi=ffe30574 edi=068b4625 ebp=00389d30 esp=00389d08 program=C:\DJGPP\LIB\GCC-LIB\DJGPP\2.952\GPC1.EXE cs: sel=0117 base=83c03000 limit=ffe5dfff ds: sel=011f base=83c03000 limit=ffe5dfff es: sel=011f base=83c03000 limit=ffe5dfff fs: sel=00f7 base=000260d0 limit=0000ffff gs: sel=012f base=00000000 limit=0010ffff ss: sel=011f base=83c03000 limit=ffe5dfff App stack: [0038a3a4..0020a3a4] Exceptn stack: [0020a2b0..00208370]
Call frame traceback EIPs: 0x0015d86d 0x001a5bbe 0x0013bad9 0x0013f967 0x001caee2
---------------------------------------------------------------------------------
Such a bug which appears and disappears without any relationship to the changes in gpc looks like a wandering pointer problem. It may be completely unseen on other systems.
Hope this helps
Maurice
Maurice Lombardi wrote:
Since at least three monthes a bug pops in and pops out in an erratic way while running dostest.bat after a new compilation of a gpc snapshot under djgpp-2.95.2 (nothing to do with the recent discussion about 2.95.3: I have reverted to 2.95.2). It is in one or both of the test programs nicola1.pas and/or nicola2.pas. On the screen (and in the make.out logfile) I have:
Well, both of these test programs are `WRONG' which means they detect if GPC recognizes a bug in the program correctly. Of course, segfaulting is not a very nice way of signalling a program error, but it's still better than segfaulting on a correct program.
To put it bluntly, Peter is way too busy with other stuff, and there are so many urgent "real" bugs to fix and features to implement, so you probably can just forget about such a "peripheral" problem being solved anytime soon.
I'll move the two test programs to knownbugs/ so they won't disturb the test suite, that's all I can do...
Frank