I have uploaded a new alpha version of GPC to http://www.gnu-pascal.de/alpha/.
Important notes:
- This is an ALPHA version, as discussed on the mailing list before. Not so many extensive tests have been made (though the test suite passes on my system). I'm not uploading binaries, diffs, separate test suite archives, updated web pages etc., just the source distribution. (Of course, others may feel free to upload binaries for various platforms.) I'm not aware of any serious bugs, but you have to decide for yourself whether to use it for production work.
- Bison (building GPC)
Bison version 2.0 has been released. It can be obtained at ftp://ftp.gnu.org/gnu/bison/bison-2.0.tar.gz. This is now the recommended version for all GPC compilations. Fortunately, we now don't depend on changing alpha/beta versions of bison anymore. Bison is required when building a minimal distribution of GPC (which now doesn't include the Bison generated files anymore, as it did temporarily); when building a full source distribution and not modifying the bison input files (*.y), bison is not strictly needed, but in case of doubt, it can't hurt to install the new bison version.
New features:
- Support for gcc-3.4.x (tested with 3.4.3)
The caveats that apply to gcc-3.3.x (especially on Dos/Windows) also apply here.
- Renamed options
Due to the way that gcc-3.4.x handles options, we had to rename two options (command line and compiler directive, respectively). To avoid confusion, we did this for all backend versions:
--no-default-paths -> --disable-default-paths --no-debug-info -> --disable-debug-info
Note: `--disable-debug-info' is only used in very special cases, and usually as a compiler directive. To turn off debug info one would normally use `-g0' which remains unaffected.
- Qualified identifiers (chief18.pas, fjf260*.pas, fjf921*.pas, grp1.pas, kurzw1.pas, mod{9,10,13..17}*.pas)
GPC now supports qualified identifiers, both Extended Pascal and Borland Pascal style.
A small incompatibility to previous versions arises when a declaration has the same name as an interface, which is not EP conformant, but GPC previously allowed. This will now cause compile-time errors. The solution is to rename either the interface or the declaration.
The linker names, if not specified explicitly, are now completely different. Since those linker names should not be relied upon anyway, we hope this is no problem. If you get problems here, just add `name' attributes where necesssary. (This will also make the code more robust, in case the internal conventions ever change again.)
- Importing within a routine (EP feature) works now. (mod15[c-e].pas)
- Range checking (chuck5.pas, fjf446.pas, fjf989*.pas, fjf992*.pas, fsc{01..37}*.pas, miklos1[bc].pas, mir{016,021..028,030..047}*.pas, russ4*.pas)
GPC now supports full range checking (previously it did so only for dynamic ranges and sets). Range checking is on by default (in all dialects) and can be turned off and on again by command-line arguments or compiler directives (`{$[no-]range-checking}' and also `{$R-}' and `{$R+}', BP compatible).
Note, this is not overflow checking, which may be implemented later and will be a separate option, just like in BP. Range checking applies when a value of a larger type (e.g., an `Integer' variable or the result of an integer operation) is used in a place where a subrange is expected (e.g., an array index, or assignment to a variable with more limited range). Overflow checking would apply if the result of an arithmetic or other operation exceeds the representable values (e.g., `var a: Integer = MaxInt; [...] WriteLn (a + a)'). This is not yet checked.
For input operations (`Read', `ReadLn', `ReadStr', `Val'), range checking errors are treated as I/O errors, so they can be trapped with `{$I-}' via `IOResult' (for `Read*'), or for `Val' via the 3rd parameter (while range errors in the 3rd parameter of `Val' itself are treated as regular runtime errors; this paramter is the error position, so range errors there can be avoided simply by declaring it of a sufficiently larger type, usually just `Integer' or `Cardinal').
For strings, range checking is BP compatible (access up to the capacity allowed) in `--borland-pascal' and `--delphi' modes and EP compatible (access only up to the current length allowed) otherwise. So in default (EP) mode code such as
if MyString[1] = '-' ...
without a check
if (MyString <> '') and ...
may now fail with a range-checking error. This is useful, since the first test was always undefined if `MyString' was empty, but in my experience so far, this has been one of the most common causes of range-checking errors in my code.
The same applies with `var' parameters and the address operator as well, so e.g. code such as:
BlockRead (f, StringLength, SizeOf (StringLength)); BlockRead (f, s[1], StringLength); SetLength (s, StringLength);
needs two changes to be range safe now:
BlockRead (f, StringLength, SizeOf (StringLength)); SetLength (s, StringLength); if StringLength > 0 then BlockRead (f, s[1], StringLength);
Another example (rather low-level code, found e.g. in the RTS):
BufPtr := PChars0 (@s[1]); BufSize := Length (s);
will fail if `s' is empty. Possible change (provided the using code doesn't access `BufPtr' if `BufSize' is empty, which would be undefined anyway when reading):
if s = '' then BufPtr := nil else BufPtr := PChars0 (@s[1]); BufSize := Length (s);
- `pow', `Trim', `Card', set operations (`-', `*', `><'), set comparisons, string comparisons and array slices with constant arguments can now be used in constants (fjf998*.pas, fjf1000*.pas, fjf1009*.pas)
- Initialized types in record and object fields and in schemata work now. (inirec[24].pas, fjf1016*.pas)
- Types and initializers containing variable expressions, including schemata with non-constant discriminants work now. (couper[45].pas, fjf186.pas, fjf548.pas, fjf612a.pas, fjf997*.pas, fjf1003*.pas, john1a.pas)
- With `-Wnested-comments' and without `--nested-comments' warn about comment openers found within comments. (fjf1017*.pas)
- New options `--[no-]case-value-checking' (fjf1012*.pas)
- Arithmetics with a complex and a real operand are now better optimized. (20020118143553.B28837@artax.karlin.mff.cuni.cz)
- Bug fixes:
* warn if an lhs cast decreases alignment (avo9.pas)
* don't require result variables in forward declarations except in strict ISO mode (marku10*.pas)
* writing to a file buffer at EOF didn't work (eof1.pas)
* don't allow `f^' for unopened files `f' (pcerror[ij].pas)
* evaluate initializers exactly as often as specified (fjf1019.pas)
* in standard Pascal modes, `EOF' is false on an empty file (tom7.pas)
* wrong `arithmetical overflow' with `set of byte' (igor1.pas)
* `ParamStr' evaluated its argument twice (fjf963b.pas)
* user-defined operators must not be applied to implicit operations (fjf991.pas and many other cases)
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8
Frank Heckenbach wrote:
I have uploaded a new alpha version of GPC to http://www.gnu-pascal.de/alpha/.
Thanks for the new alpha version.
There is a minor build problem.
[G5:~/gnu/gpc/gpc-20050217] adriaan% mkdir build [G5:~/gnu/gpc/gpc-20050217] adriaan% cd build/ [G5:gpc/gpc-20050217/build] adriaan% ../gcc-3.4.3/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc343d7 --target=powerpc-apple-darwin7 --host=powerpc-apple-darwin7 creating cache ./config.cache checking host system type... powerpc-apple-darwin7 checking target system type... powerpc-apple-darwin7 checking build system type... powerpc-apple-darwin7 checking for a BSD compatible install... /usr/bin/install -c
*** *** Detected GCC version 3.4.3. *** This version of GPC requires a patch to GCC to build with *** GCC version 3.4.3. *** This patch will now be applied. *** Press ENTER to continue, Ctrl-C to abort. ***
The text leading up to this was: -------------------------- |*** gcc/gcc-3.4.3/gcc/version.h Tue Oct 8 19:27:39 2002 |--- gcc/gcc-3.4.3/gcc/version.h Fri Feb 11 05:11:09 2005 -------------------------- File to patch:
Of course, the diff can be applied manually.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
I have uploaded a new alpha version of GPC to http://www.gnu-pascal.de/alpha/.
Thanks for the new alpha version.
There is a minor build problem.
[G5:~/gnu/gpc/gpc-20050217] adriaan% mkdir build [G5:~/gnu/gpc/gpc-20050217] adriaan% cd build/ [G5:gpc/gpc-20050217/build] adriaan% ../gcc-3.4.3/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc343d7 --target=powerpc-apple-darwin7 --host=powerpc-apple-darwin7 creating cache ./config.cache checking host system type... powerpc-apple-darwin7 checking target system type... powerpc-apple-darwin7 checking build system type... powerpc-apple-darwin7 checking for a BSD compatible install... /usr/bin/install -c
*** Detected GCC version 3.4.3. *** This version of GPC requires a patch to GCC to build with *** GCC version 3.4.3. *** This patch will now be applied. *** Press ENTER to continue, Ctrl-C to abort.
The text leading up to this was:
|*** gcc/gcc-3.4.3/gcc/version.h Tue Oct 8 19:27:39 2002 |--- gcc/gcc-3.4.3/gcc/version.h Fri Feb 11 05:11:09 2005
File to patch:
Of course, the diff can be applied manually.
Oh yes, silly mistake, thanks for the report.
Frank
gpc 20050217, gcc 3.4.3, IA32 (Athlon XP), Linux (Fedora Core 3):
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: aregextest.pas FAIL: awindtes.pas FAIL: awindtes2.pas FAIL: baby.pas FAIL: dostest.pas FAIL: dostest2.pas FAIL: filehand.pas FAIL: fjf684.pas FAIL: fjf751k.pas FAIL: fjf751l.pas FAIL: fjf800.pas FAIL: random.pas
=== gpc Summary ===
# of tests 4537 # of expected passes 4525 # of unexpected failures 11 # of unsupported tests 1
awindtes* and dostest* passed when I rerun the testsuite without range checking.
Emil Jerabek
On Thu, Feb 17, 2005 at 03:21:14PM +0100, Emil Jerabek wrote:
gpc 20050217, gcc 3.4.3, IA32 (Athlon XP), Linux (Fedora Core 3):
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: aregextest.pas FAIL: awindtes.pas FAIL: awindtes2.pas FAIL: baby.pas FAIL: dostest.pas FAIL: dostest2.pas FAIL: filehand.pas FAIL: fjf684.pas FAIL: fjf751k.pas FAIL: fjf751l.pas FAIL: fjf800.pas FAIL: random.pas
=== gpc Summary ===
# of tests 4537 # of expected passes 4525 # of unexpected failures 11 # of unsupported tests 1
awindtes* and dostest* passed when I rerun the testsuite without range checking.
Emil Jerabek
More details:
TEST awindtes.pas: `.' not found TEST awindtes2.pas: `.' not found TEST baby.pas: ./a.out: value out of range (error #300 at 804f092) TEST dostest.pas: `.' not found TEST dostest2.pas: `.' not found TEST filehand.pas: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/filehand.pas: In main program: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/filehand.pas:11: error: statement usedas an expression failed TEST fjf684.pas: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf684.pas: Inmain program: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf684.pas:12: error: invalid operandsto `=' failed TEST fjf751k.pas: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf751k.pas: In main program: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf751k.pas:8: error: argument to `WriteLn' is of wrong type failed TEST fjf751l.pas: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf751l.pas: In main program: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf751l.pas:8: error: argument to `WriteLn' is of wrong type failed TEST fjf800.pas: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf800.pas:65:error: redeclaration of `Fjf800' /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf800.pas:1: error: previous declaration /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf800.pas:65: error: redeclaration of`Fjf800' /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf800.pas:1: error: previous declaration failed TEST random.pas: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/random.pas: Inmain program: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/random.pas:22: error: invalid operandsto `*' /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/random.pas:22: error: invalid operandsto `*' failed
Emil
Emil Jerabek wrote:
TEST awindtes.pas: `.' not found TEST awindtes2.pas: `.' not found TEST baby.pas: ./a.out: value out of range (error #300 at 804f092) TEST dostest.pas: `.' not found TEST dostest2.pas: `.' not found TEST filehand.pas: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/filehand.pas: In main program: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/filehand.pas:11: error: statement usedas an expression failed TEST fjf684.pas: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf684.pas: Inmain program: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf684.pas:12: error: invalid operandsto `=' failed TEST fjf751k.pas: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf751k.pas: In main program: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf751k.pas:8: error: argument to `WriteLn' is of wrong type failed TEST fjf751l.pas: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf751l.pas: In main program: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf751l.pas:8: error: argument to `WriteLn' is of wrong type failed TEST fjf800.pas: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf800.pas:65:error: redeclaration of `Fjf800' /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf800.pas:1: error: previous declaration /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf800.pas:65: error: redeclaration of`Fjf800' /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/fjf800.pas:1: error: previous declaration failed TEST random.pas: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/random.pas: Inmain program: /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/random.pas:22: error: invalid operandsto `*' /home/emil/dist/gpc/gcc-3.4.3/gcc/p/test/random.pas:22: error: invalid operandsto `*' failed
Waldek, many of these failure seem to be side-effects of the fjf1018 patch.
Frank
Frank Heckenbach wrote:
Waldek, many of these failure seem to be side-effects of the fjf1018 patch.
That is incompatible change. If we want fjf1018.pas to be accepted by default then: filehand.pas, fjf684.pas, fjf751k.pas, fjf751l.pas, fjf800.pas, random.pas are invalid. Personally I woud prefer to accept fjf1018.pas only in BP mode.
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Waldek, many of these failure seem to be side-effects of the fjf1018 patch.
That is incompatible change. If we want fjf1018.pas to be accepted by default then: filehand.pas, fjf684.pas, fjf751k.pas, fjf751l.pas, fjf800.pas, random.pas are invalid.
Indeed, BP doesn't accept such programs.
Personally I woud prefer to accept fjf1018.pas only in BP mode.
OK.
If someone else wants to try it, use this patch and add `{$borland-pascal}' in test/fjf1018[acu.pas].
--- p/module.c Thu Feb 17 04:59:34 2005 +++ p/module.c Fri Feb 18 01:22:15 2005 @@ -472,7 +472,7 @@ chk_dialect ("programs without program header are", B_D_PASCAL); id = get_identifier ("noname"); } - if (kind == 1 || (kind == 0 && !(co->pascal_dialect & C_E_O_PASCAL))) + if (kind == 1 || (kind == 0 && (co->pascal_dialect & B_D_PASCAL))) pushdecl (build_decl (NAMESPACE_DECL, id, void_type_node)); current_module = find_module (id, 1); current_module->assembler_name = NULL;
Frank
Frank Heckenbach wrote:
If someone else wants to try it, use this patch and add `{$borland-pascal}' in test/fjf1018[acu.pas].
New test results on Mac OS X (with Waldek's code generation patch applied also)
[G5:gcc/p/test] adriaan% make EXTRA_PFLAGS=--longjmp-all-nonlocal-labels ... 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 FAIL: avo4.pas FAIL: az20.pas FAIL: fjf1021h.pas FAIL: fjf1021i.pas UNSUPPORTED: fjf165a.pas FAIL: fjf659o.pas FAIL: fjf746.pas FAIL: fjf980b.pas FAIL: fjf998r.pas UNSUPPORTED: gmptest.pas FAIL: longr2.pas FAIL: pack10.pas FAIL: pack12.pas FAIL: pack2.pas FAIL: pack4.pas FAIL: systemtest.pas
=== gpc Summary ===
# of tests 4537 # of expected passes 4517 # of unexpected failures 14 # of unsupported tests 6
gpc version 20050217, based on gcc-3.4.3
The result of systemtest.pas is interesting. With previous versions of gpc the output (caused by a bug in Mac OS X) was:
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[10229]: error: Can't allocate region *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[10229]: error: Can't allocate region OK
Now we get:
TEST systemtest.pas: ./test_run: line 345: 10339 Segmentation fault ./"$A_OUT" "$1"
with backtrace;
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x000e203c
Thread 0 Crashed: 0 a.out 0x0001d614 _p_FileHandle + 0x4 (files.pas:1015) 1 a.out 0x00005120 _p_WriteErrorMessage + 0x12c (error.pas:750) 2 a.out 0x000053fc _p__rts_Error_S24_Writestackdump + 0x2cc (error.pas:772) 3 a.out 0x00005df4 _p_EndRuntimeError + 0x38 (error.pas:862) 4 a.out 0x00005f00 _p__rts_Error_S32_Strerror + 0 (error.pas:875) 5 a.out 0x00004338 _p_IORangeCheckError + 0 (error.pas:585) 6 a.out 0x000161f0 _p__rts_Heap_S6_Addtomarklist + 0 (heap.pas:203) 7 a.out 0x00016458 _p_New + 0x4c (heap.pas:251) 8 a.out 0x00003f84 _p__M0_main_program + 0x3f8 (systemtest.pas:42) 9 a.out 0x0000413c main + 0x34 (<implicit code>:59) 10 a.out 0x00002140 _start + 0x188 (crt.c:267) 11 dyld 0x8fe1a558 _dyld_start + 0x64
Adriaan van Os wrote:
Frank Heckenbach wrote:
If someone else wants to try it, use this patch and add `{$borland-pascal}' in test/fjf1018[acu.pas].
New test results on Mac OS X (with Waldek's code generation patch applied also)
[G5:gcc/p/test] adriaan% make EXTRA_PFLAGS=--longjmp-all-nonlocal-labels ... 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 FAIL: avo4.pas FAIL: az20.pas FAIL: fjf1021h.pas FAIL: fjf1021i.pas UNSUPPORTED: fjf165a.pas FAIL: fjf659o.pas FAIL: fjf746.pas FAIL: fjf980b.pas FAIL: fjf998r.pas UNSUPPORTED: gmptest.pas FAIL: longr2.pas FAIL: pack10.pas FAIL: pack12.pas FAIL: pack2.pas FAIL: pack4.pas FAIL: systemtest.pas
=== gpc Summary ===
# of tests 4537 # of expected passes 4517 # of unexpected failures 14 # of unsupported tests 6
gpc version 20050217, based on gcc-3.4.3
The result of systemtest.pas is interesting. With previous versions of gpc the output (caused by a bug in Mac OS X) was:
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[10229]: error: Can't allocate region *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[10229]: error: Can't allocate region OK
Now we get:
TEST systemtest.pas: ./test_run: line 345: 10339 Segmentation fault ./"$A_OUT" "$1"
with backtrace;
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x000e203c
Thread 0 Crashed: 0 a.out 0x0001d614 _p_FileHandle + 0x4 (files.pas:1015) 1 a.out 0x00005120 _p_WriteErrorMessage + 0x12c (error.pas:750) 2 a.out 0x000053fc _p__rts_Error_S24_Writestackdump + 0x2cc (error.pas:772) 3 a.out 0x00005df4 _p_EndRuntimeError + 0x38 (error.pas:862) 4 a.out 0x00005f00 _p__rts_Error_S32_Strerror + 0 (error.pas:875) 5 a.out 0x00004338 _p_IORangeCheckError + 0 (error.pas:585) 6 a.out 0x000161f0 _p__rts_Heap_S6_Addtomarklist + 0 (heap.pas:203) 7 a.out 0x00016458 _p_New + 0x4c (heap.pas:251) 8 a.out 0x00003f84 _p__M0_main_program + 0x3f8 (systemtest.pas:42) 9 a.out 0x0000413c main + 0x34 (<implicit code>:59) 10 a.out 0x00002140 _start + 0x188 (crt.c:267) 11 dyld 0x8fe1a558 _dyld_start + 0x64
That looks like error in runtime system. Did you re-built `libgpc.a'? Re-making after applying patch will _not_ re-make `libgpc.a', one has to remove object files in `gcc/p/rts/' subdirectory by hand (including `stamp-error-gpi').
Waldek Hebisch wrote:
That looks like error in runtime system. Did you re-built `libgpc.a'? Re-making after applying patch will _not_ re-make `libgpc.a', one has to remove object files in `gcc/p/rts/' subdirectory by hand (including `stamp-error-gpi').
I had noticed that libgpc.a wasn't rebuilt and did a fresh rebuild. I believe there is a problem in the runtime system.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Waldek Hebisch wrote:
That looks like error in runtime system. Did you re-built `libgpc.a'? Re-making after applying patch will _not_ re-make `libgpc.a', one has to remove object files in `gcc/p/rts/' subdirectory by hand (including `stamp-error-gpi').
I had noticed that libgpc.a wasn't rebuilt and did a fresh rebuild. I believe there is a problem in the runtime system.
My working hypothesis is that range-checking code got mis-optimized (the patch I posted was intended to correct this). So turning off range-checking (also for libgpc) should eliminate failures. One could try removing (or commentig out) line:
TREE_SIDE_EFFECTS (t) = side_effects;
from my patch. Removing this line will produce many surious warnings, but the chance of mis-optimization is then smaller (however I was unable to see any change in generated code with this change).
Waldek Hebisch wrote:
Adriaan van Os wrote:
Waldek Hebisch wrote:
That looks like error in runtime system. Did you re-built `libgpc.a'? Re-making after applying patch will _not_ re-make `libgpc.a', one has to remove object files in `gcc/p/rts/' subdirectory by hand (including `stamp-error-gpi').
I had noticed that libgpc.a wasn't rebuilt and did a fresh rebuild. I believe there is a problem in the runtime system.
My working hypothesis is that range-checking code got mis-optimized (the patch I posted was intended to correct this). So turning off range-checking (also for libgpc) should eliminate failures. One could try removing (or commentig out) line:
TREE_SIDE_EFFECTS (t) = side_effects;
from my patch. Removing this line will produce many surious warnings, but the chance of mis-optimization is then smaller (however I was unable to see any change in generated code with this change).
It doesn't help, same segmentation fault.
I had a look at one of the test programs (pack2.pas). When I add writeln's like this:
Program Pack2;
Var a: packed array [ 1..188 ] of Boolean; {$W-} ai: Integer absolute a; i: Integer; {$W+}
begin writeln('ai:= 0;'); ai:= 0; writeln('a [ 1 ]:= true;'); a [ 1 ]:= true; writeln('a [ 2 ]:= true;'); a [ 2 ]:= true; writeln('a [ 3 ]:= true;'); a [ 3 ]:= true; writeln('for i:= 1 to 188 do'); for i:= 1 to 188 do begin writeln('i = ', i); writeln('if not a [ i ] then'); if not a [ i ] then begin writeln('a [ i ]:= true;'); a [ i ]:= true; end end; writeln('if ( SizeOf ( a ) = 24 ) and ( ai = -1 ) then'); if ( SizeOf ( a ) = 24 ) and ( ai = -1 ) then writeln ( 'OK' ) else writeln ( 'failed: ', SizeOf ( a ), ' ', ai ); end.
the crash occurs at
i = 33 if not a [ i ] then a [ i ]:= true; ./test_run: line 345: 16298 Segmentation fault ./"$A_OUT" "$1"
(for the backtrace see previous email).
Regards,
Adriaan van Os
Waldek Hebisch wrote:
Adriaan van Os wrote:
The result of systemtest.pas is interesting. With previous versions of gpc the output (caused by a bug in Mac OS X) was:
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[10229]: error: Can't allocate region *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[10229]: error: Can't allocate region OK
Now we get:
TEST systemtest.pas: ./test_run: line 345: 10339 Segmentation fault ./"$A_OUT" "$1"
with backtrace;
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x000e203c
Thread 0 Crashed: 0 a.out 0x0001d614 _p_FileHandle + 0x4 (files.pas:1015) 1 a.out 0x00005120 _p_WriteErrorMessage + 0x12c (error.pas:750) 2 a.out 0x000053fc _p__rts_Error_S24_Writestackdump + 0x2cc (error.pas:772) 3 a.out 0x00005df4 _p_EndRuntimeError + 0x38 (error.pas:862) 4 a.out 0x00005f00 _p__rts_Error_S32_Strerror + 0 (error.pas:875) 5 a.out 0x00004338 _p_IORangeCheckError + 0 (error.pas:585) 6 a.out 0x000161f0 _p__rts_Heap_S6_Addtomarklist + 0 (heap.pas:203) 7 a.out 0x00016458 _p_New + 0x4c (heap.pas:251) 8 a.out 0x00003f84 _p__M0_main_program + 0x3f8 (systemtest.pas:42) 9 a.out 0x0000413c main + 0x34 (<implicit code>:59) 10 a.out 0x00002140 _start + 0x188 (crt.c:267) 11 dyld 0x8fe1a558 _dyld_start + 0x64
That looks like error in runtime system. Did you re-built `libgpc.a'? Re-making after applying patch will _not_ re-make `libgpc.a', one has to remove object files in `gcc/p/rts/' subdirectory by hand (including `stamp-error-gpi').
Or just `make clean' in that directory. And possibly `rm -rf <build>/gcc/p/utils' to rebuild the utilities (if you care about them).
Somehow the given line numbers really don't match, something's strange here. If you're sure the RTS was rebuilt, please try rebuilding it again without optimization (CFLAGS=-O0). Sometimes optimization distorts the debug traces quite a bit. Of course, if you're (un)lucky, changing the optimization will also make the bugs disappear, we will see ...
Frank
Frank Heckenbach wrote:
Waldek Hebisch wrote:
Adriaan van Os wrote:
Now we get:
TEST systemtest.pas: ./test_run: line 345: 10339 Segmentation fault ./"$A_OUT" "$1"
(solved now for systemtest.pas but not yet for the other reported segmentation faults)
That looks like error in runtime system. Did you re-built `libgpc.a'? Re-making after applying patch will _not_ re-make `libgpc.a', one has to remove object files in `gcc/p/rts/' subdirectory by hand (including `stamp-error-gpi').
Or just `make clean' in that directory. And possibly `rm -rf <build>/gcc/p/utils' to rebuild the utilities (if you care about them).
Somehow the given line numbers really don't match, something's strange here. If you're sure the RTS was rebuilt, please try rebuilding it again without optimization (CFLAGS=-O0). Sometimes optimization distorts the debug traces quite a bit. Of course, if you're (un)lucky, changing the optimization will also make the bugs disappear, we will see ...
OK. rebuilt the rts with -O0
../.././xgpc -B../.././ -c -g -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations -O0 --unit-path=/Users/adriaan/gnu/gpc/gpc-20050217/gcc-3.4.3/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /Users/adriaan/gnu/gpc/gpc-20050217/gcc-3.4.3/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.4.3'" "/Users/adriaan/gnu/gpc/gpc-20050217/gcc-3.4.3/gcc/p/rts/rtsc.pas"
(etcetera)
Now, instead of:
typical backtrace for the segmentation faults:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x000d703c
Thread 0 Crashed: 0 a.out 0x00008260 _p_FileHandle + 0x4 (files.pas:1015) 1 a.out 0x00003760 _p_WriteErrorMessage + 0x10c (error.pas:750) 2 a.out 0x00003a40 _p__rts_Error_S24_Writestackdump + 0x2cc (error.pas:772) 3 a.out 0x00004438 _p_EndRuntimeError + 0x38 (error.pas:862) 4 a.out 0x00004544 _p__rts_Error_S32_Strerror + 0 (error.pas:875) 5 a.out 0x00002998 _p_IORangeCheckError + 0 (error.pas:585) 6 a.out 0x000026ac _p__M0_main_program + 0x23c (pack2.pas:18) 7 a.out 0x00002808 main + 0x34 (<implicit code>:22) 8 a.out 0x000020a8 _start + 0x188 (crt.c:267) 9 dyld 0x8fe1a558 _dyld_start + 0x64
I get:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x0008203c
Thread 0 Crashed: 0 a.out 0x00009f64 _p_FileHandle + 0x18 (<implicit code>:1079) 1 a.out 0x00003148 _p_WriteErrorMessage + 0x128 (error.pas:750) 2 a.out 0x000033c0 _p__rts_Error_S24_Writestackdump + 0x268 (error.pas:772) 3 a.out 0x00003cc0 _p_EndRuntimeError + 0x38 (error.pas:862) 4 a.out 0x00003dcc _p__rts_Error_S32_Strerror + 0 (error.pas:875) 5 a.out 0x00002350 _p_IORangeCheckError + 0 (error.pas:585) 6 a.out 0x00002068 _p__M0_main_program + 0x23c (pack2.pas:18) 7 a.out 0x000021c4 main + 0x34 (<implicit code>:22) 8 a.out 0x00001a64 _start + 0x188 (crt.c:267) 9 dyld 0x8fe1a558 _dyld_start + 0x64
The line numbers haven't changed. Can't this be the reported inaccurate-line-numbers-in-debug-info problem http://www.gnu-pascal.de/crystal/gpc/en/mail10675.html ? ...
Regards,
Adriaan van Os
Adriaan van Os wrote:
OK. rebuilt the rts with -O0
Now, instead of:
typical backtrace for the segmentation faults:
I get:
The traces seem to be quite consistent, and suggest crash when printing error message. Silly question: can you see _any_ message about failing range checks?
Waldek Hebisch wrote:
The traces seem to be quite consistent, and suggest crash when printing error message.
Yes, the same backtrace.
Silly question: can you see _any_ message about failing range checks?
At compile time (error: constant out of range), but not at runtime, e.g.
[G5:gcc/p/test] adriaan% cat pack2-debug3.pas Program Pack2;
Var a: array [ 1..1 ] of Boolean; i: integer; begin writeln('for i:= 1 to 2 do'); for i:= 1 to 2 do begin writeln('i = ', i); writeln('a [ i ]:= true;'); a [ i ]:= true end end. [G5:gcc/p/test] adriaan% gpc pack2-debug3.pas [G5:gcc/p/test] adriaan% ./a.out for i:= 1 to 2 do i = 1 a [ i ]:= true; i = 2 a [ i ]:= true; Segmentation fault
Or the same with a packed array of boolean ...
[G5:gcc/p/test] adriaan% cat pack2-debug4.pas Program Pack2;
Var a: packed array [ 1..1 ] of Boolean; i: integer; begin writeln('for i:= 1 to 1 do'); for i:= 1 to 1 do begin writeln('i = ', i); writeln('a [ i ]:= true;'); a [ i ]:= true end end. [G5:gcc/p/test] adriaan% gpc pack2-debug4.pas [G5:gcc/p/test] adriaan% ./a.out for i:= 1 to 1 do i = 1 a [ i ]:= true; Segmentation fault <-- same backtrace for a range check (??) error
Adriaan van Os wrote:
I get:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x0008203c
Thread 0 Crashed: 0 a.out 0x00009f64 _p_FileHandle + 0x18 (<implicit code>:1079) 1 a.out 0x00003148 _p_WriteErrorMessage + 0x128 (error.pas:750) 2 a.out 0x000033c0 _p__rts_Error_S24_Writestackdump + 0x268 (error.pas:772) 3 a.out 0x00003cc0 _p_EndRuntimeError + 0x38 (error.pas:862) 4 a.out 0x00003dcc _p__rts_Error_S32_Strerror + 0 (error.pas:875) 5 a.out 0x00002350 _p_IORangeCheckError + 0 (error.pas:585) 6 a.out 0x00002068 _p__M0_main_program + 0x23c (pack2.pas:18) 7 a.out 0x000021c4 main + 0x34 (<implicit code>:22) 8 a.out 0x00001a64 _start + 0x188 (crt.c:267) 9 dyld 0x8fe1a558 _dyld_start + 0x64
I think that real backtrace is: FileHandle WriteErrorMessage WriteStackDump Finalize1 EndRuntimeError RuntimeError RangeCheckError
Discrepances IMHO can be explained by tail calls and fuzz in line numbers. Now the question is why do we get range check error and what is happening in `FileHandle' (maybe `StdErr' is uninitialized).
Waldek Hebisch wrote:
I think that real backtrace is: FileHandle WriteErrorMessage WriteStackDump Finalize1 EndRuntimeError RuntimeError RangeCheckError
Discrepances IMHO can be explained by tail calls and fuzz in line numbers. Now the question is why do we get range check error and what is happening in `FileHandle' (maybe `StdErr' is uninitialized).
procedure Finalize1; begin FlushAllFiles; RestoreTerminal (True); Done_Files; if ErrorMessageString <> '' then WriteStackDump end;
Does Done_Files also operate on StdErr ?? The crash disappears if I comment out the Done_Files call;
Regards,
Adriaan van Os
Adriaan van Os wrote:
procedure Finalize1; begin FlushAllFiles; RestoreTerminal (True); Done_Files; if ErrorMessageString <> '' then WriteStackDump end;
Does Done_Files also operate on StdErr ?? The crash disappears if I comment out the Done_Files call;
It looks so (Frank knows better). Good catch. `Done_Files' probably should go after `WriteStackDump'.
Waldek Hebisch wrote:
Adriaan van Os wrote:
procedure Finalize1; begin FlushAllFiles; RestoreTerminal (True); Done_Files; if ErrorMessageString <> '' then WriteStackDump end;
Does Done_Files also operate on StdErr ?? The crash disappears if I comment out the Done_Files call;
It looks so (Frank knows better). Good catch.
Ouch! Yes, `WriteErrorMessage' accesses (via `FileHandle') a field of already disposed `StdErr' variable -- an evil bug, as it happens to work often (especially if the field is in the middle of a bigger structure, as is the case here), so it wasn't noticed so far. But, of course, it's wrong, and now it crashed ...
`Done_Files' probably should go after `WriteStackDump'.
Yes, try swapping the two statements.
Frank
Frank Heckenbach wrote:
Waldek Hebisch wrote:
Adriaan van Os wrote:
procedure Finalize1; begin FlushAllFiles; RestoreTerminal (True); Done_Files; if ErrorMessageString <> '' then WriteStackDump end;
Does Done_Files also operate on StdErr ?? The crash disappears if I comment out the Done_Files call;
It looks so (Frank knows better). Good catch.
Ouch! Yes, `WriteErrorMessage' accesses (via `FileHandle') a field of already disposed `StdErr' variable -- an evil bug, as it happens to work often (especially if the field is in the middle of a bigger structure, as is the case here), so it wasn't noticed so far. But, of course, it's wrong, and now it crashed ...
`Done_Files' probably should go after `WriteStackDump'.
Yes, try swapping the two statements.
It works OK now. Don't we need a testsuite program to test for proper handling of runtime errors ? The rts problem went unnoticed in the previous alpha version. Not sure how to do that. Cause a runtime error and then check the exit code in a shell script ?
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
Waldek Hebisch wrote:
Adriaan van Os wrote:
procedure Finalize1; begin FlushAllFiles; RestoreTerminal (True); Done_Files; if ErrorMessageString <> '' then WriteStackDump end;
Does Done_Files also operate on StdErr ?? The crash disappears if I comment out the Done_Files call;
It looks so (Frank knows better). Good catch.
Ouch! Yes, `WriteErrorMessage' accesses (via `FileHandle') a field of already disposed `StdErr' variable -- an evil bug, as it happens to work often (especially if the field is in the middle of a bigger structure, as is the case here), so it wasn't noticed so far. But, of course, it's wrong, and now it crashed ...
`Done_Files' probably should go after `WriteStackDump'.
Yes, try swapping the two statements.
It works OK now. Don't we need a testsuite program to test for proper handling of runtime errors ? The rts problem went unnoticed in the previous alpha version. Not sure how to do that. Cause a runtime error and then check the exit code in a shell script ?
We do something like this in several test programs, and mishandling is usually noticed (as you did).
The problem here was really that accessing an field of a disposed variable often works (because the memory still contains the old value, even if it is unallocated), so no test could have noticed it. (Except for general automatic runtime checks for dangling pointers, but as you can probably imagine, they'd be very expensive, similar to checks for undefined variables).
Frank
Waldek Hebisch wrote:
Now the question is why do we get range check error and what is happening in `FileHandle' (maybe `StdErr' is uninitialized).
The first question remains. New testsuite results:
Test Run By adriaan on 2005-02-22 09:22:07 Native configuration is powerpc-apple-darwin7 (G5.local) gpc 20050217, based on gcc-3.4.3, flags: -g -O3 -W -Wall -Wno-unused --longjmp-all-nonlocal-labels TEST avo4.pas: ./a.out: value out of range (error #300 at 31af) TEST az20.pas: ./a.out: value out of range (error #300 at 230f) TEST bprealtest.pas: ./a.out: BP compatible 6 byte `Real' type does not support infinity (error #871 at 2fd3) TEST fjf1021h.pas: ./fjf1021h.pas:6: error: expressions with side-effects are not allowed in schema types failed TEST fjf1021i.pas: ./fjf1021i.pas:8: error: expressions with side-effects are not allowed in schema types failed TEST fjf659o.pas: ./test_run: line 345: 5724 Segmentation fault ./"$A_OUT" "$1" TEST fjf746.pas: ./a.out: value out of range (error #300 at 230f) TEST fjf980b.pas: ./a.out: value out of range (error #300 at 22a3) TEST fjf998r.pas: failed: TEST longr2.pas: dummy.pas: In main program: dummy.pas:2: error: real constant out of range TEST pack10.pas: ./a.out: value out of range (error #300 at 21cb) TEST pack12.pas: ./a.out: value out of range (error #300 at 221f) TEST pack2.pas: ./a.out: value out of range (error #300 at 2323) TEST pack4.pas: ./a.out: value out of range (error #300 at 2bfb)
Backtrace for fjf659o.pas:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x000e6014
Thread 0 Crashed: 0 a.out 0x0000eeb4 _p_Write_Init + 0x34 (files.pas:518) 1 a.out 0x0000231c _p__M0_main_program + 0xac (fjf659o.pas:10) 2 a.out 0x00002470 main + 0x34 (<implicit code>:12) 3 a.out 0x00001ea8 _start + 0x188 (crt.c:267) 4 dyld 0x8fe1a558 _dyld_start + 0x64
Regards,
Adriaan van Os
Waldek Hebisch wrote:
Now the question is why do we get range check error and what is happening in `FileHandle' (maybe `StdErr' is uninitialized).
The first question remains.
Could you check the following program:
Program Pack2;
Var a: packed array [ 1..1 ] of Boolean; i: integer; begin i:= 1 ; a [ i ]:= true end.
I assume that it fails. But the machine code contains 10 comparisons, and it is not clear which one fails. The simplest method is probably to use `stepi' in gdb (or eqivalent metod to step trough machine instructions).
Backtrace for fjf659o.pas:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x000e6014
Thread 0 Crashed: 0 a.out 0x0000eeb4 _p_Write_Init + 0x34 (files.pas:518) 1 a.out 0x0000231c _p__M0_main_program + 0xac (fjf659o.pas:10) 2 a.out 0x00002470 main + 0x34 (<implicit code>:12) 3 a.out 0x00001ea8 _start + 0x188 (crt.c:267) 4 dyld 0x8fe1a558 _dyld_start + 0x64
Looks like _p_Write_Init is accessing freed file. We either need `Finalize' to set its argument to an invalid file (FDR) or to nil. In the second case all IO routines would have to check for nil.
Waldek Hebisch wrote:
I assume that it fails.
It does.
But the machine code contains 10 comparisons, and it is not clear which one fails.
The last one.
The simplest method is probably to use `stepi' in gdb (or eqivalent metod to step trough machine instructions).
Mixed source/disassembly for _p__M0_main_program in the CW debugger:
000021E0: 7C0802A6 mflr r0 000021E4: BF41FFE8 stmw r26,-24(SP) 000021E8: 90010008 stw r0,8(SP) 000021EC: 9421FFA0 stwu SP,-96(SP) 000021F0: 429F0005 bcl ALWAYS,31,_p__M0_main_program ; 0x000021F4 000021F4: 7FE802A6 mflr r31 begin 000021F8: 38000001 li r0,1 000021FC: 3C5F0003 addis RTOC,r31,3 00002200: 90021BD8 stw r0,7128(RTOC) i:= 1 ; 00002204: 3B400001 li r26,1 00002208: 38000000 li r0,0 0000220C: 3C5F0003 addis RTOC,r31,3 00002210: 38421BD4 addi RTOC,RTOC,7124 00002214: 38420004 addi RTOC,RTOC,4 00002218: 7F801214 add r28,r0,RTOC 0000221C: 7FC2002E lwzx r30,RTOC,r0 00002220: 3BA00000 li r29,0 00002224: 38400001 li RTOC,1 00002228: 2F820001 cmpwi cr7,RTOC,0x0001 0000222C: 41BE0008 beq+ cr7,_p__M0_main_program+0x24 ; 0x00002234 00002230: 48001151 bl _p_RangeCheckError+0x2380 ; 0x00003380 00002234: 3B62FFFF subi r27,RTOC,1 00002238: 576506FE clrlwi r5,r27,27 0000223C: 38600000 li r3,0 00002240: 38800001 li r4,1 00002244: 20A5003F subfic r5,r5,63 00002248: 4802B22D bl __ashldi3+0x2C474 ; 0x0002D474 0000224C: 7C6318F8 not r3,r3 00002250: 7C8420F8 not r4,r4 00002254: 7FA91838 and r9,r29,r3 00002258: 7FCA2038 and r10,r30,r4 0000225C: 7D5E5378 mr r30,r10 00002260: 2B890000 cmplwi cr7,r9,0x0000 00002264: 419D0018 bgt cr7,_p__M0_main_program+0x24 ; 0x0000227C 00002268: 2F890000 cmpwi cr7,r9,0x0000 0000226C: 409E0014 bne cr7,_p__M0_main_program+0x24 ; 0x00002280 00002270: 3800FFFF li r0,-1 00002274: 7F8A0040 cmpl cr7,0,r10,r0 00002278: 409D0008 ble cr7,_p__M0_main_program+0x24 ; 0x00002280 0000227C: 48001105 bl _p_RangeCheckError+0x2380 ; 0x00003380 00002280: 93DC0000 stw r30,0(r28) 00002284: 3C5F0003 addis RTOC,r31,3 00002288: 80421BD8 lwz RTOC,7128(RTOC) 0000228C: 2F820001 cmpwi cr7,RTOC,0x0001 00002290: 41BE0008 beq+ cr7,_p__M0_main_program+0x24 ; 0x00002298 00002294: 480010ED bl _p_RangeCheckError+0x2380 ; 0x00003380 00002298: 3B82FFFF subi r28,RTOC,1 0000229C: 5780E8FA rlwinm r0,r28,29,3,29 000022A0: 3C5F0003 addis RTOC,r31,3 000022A4: 38421BD4 addi RTOC,RTOC,7124 000022A8: 38420004 addi RTOC,RTOC,4 000022AC: 7F801214 add r28,r0,RTOC 000022B0: 7FC2002E lwzx r30,RTOC,r0 000022B4: 3BA00000 li r29,0 000022B8: 7F44D378 mr r4,r26 000022BC: 38600000 li r3,0 000022C0: 576506FE clrlwi r5,r27,27 000022C4: 20A5003F subfic r5,r5,63 000022C8: 4802B1AD bl __ashldi3+0x2C474 ; 0x0002D474 000022CC: 38600000 li r3,0 000022D0: 7FA91B78 or r9,r29,r3 000022D4: 7FCA2378 or r10,r30,r4 000022D8: 7D5E5378 mr r30,r10 000022DC: 2B890000 cmplwi cr7,r9,0x0000 000022E0: 419D0018 bgt cr7,_p__M0_main_program+0x24 ; 0x000022F8 000022E4: 2F890000 cmpwi cr7,r9,0x0000 000022E8: 409E0014 bne cr7,_p__M0_main_program+0x24 ; 0x000022FC 000022EC: 3800FFFF li r0,-1 000022F0: 7F8A0040 cmpl cr7,0,r10,r0 000022F4: 409D0008 ble cr7,_p__M0_main_program+0x24 ; 0x000022FC 000022F8: 48001089 bl _p_RangeCheckError+0x2380 ; 0x00003380 000022FC: 93DC0000 stw r30,0(r28) 00002300: 3C5F0003 addis RTOC,r31,3 00002304: 80421BD8 lwz RTOC,7128(RTOC) 00002308: 2F820001 cmpwi cr7,RTOC,0x0001 0000230C: 41BE0008 beq+ cr7,_p__M0_main_program+0x24 ; 0x00002314 00002310: 48001071 bl _p_RangeCheckError+0x2380 ; 0x00003380 00002314: 3B82FFFF subi r28,RTOC,1 00002318: 5780E8FA rlwinm r0,r28,29,3,29 0000231C: 3C5F0003 addis RTOC,r31,3 00002320: 38421BD4 addi RTOC,RTOC,7124 00002324: 7F801214 add r28,r0,RTOC 00002328: 7FC2002E lwzx r30,RTOC,r0 0000232C: 3BA00000 li r29,0 00002330: 576506FE clrlwi r5,r27,27 00002334: 38600000 li r3,0 00002338: 38800001 li r4,1 0000233C: 20A5003F subfic r5,r5,63 00002340: 4802B135 bl __ashldi3+0x2C474 ; 0x0002D474 00002344: 7C641B78 mr r4,r3 00002348: 38600000 li r3,0 0000234C: 7C6318F8 not r3,r3 00002350: 7C8420F8 not r4,r4 00002354: 7FA91838 and r9,r29,r3 00002358: 7FCA2038 and r10,r30,r4 0000235C: 7D5E5378 mr r30,r10 00002360: 2B890000 cmplwi cr7,r9,0x0000 00002364: 419D0018 bgt cr7,_p__M0_main_program+0x24 ; 0x0000237C 00002368: 2F890000 cmpwi cr7,r9,0x0000 0000236C: 409E0014 bne cr7,_p__M0_main_program+0x24 ; 0x00002380 00002370: 3800FFFF li r0,-1 00002374: 7F8A0040 cmpl cr7,0,r10,r0 00002378: 409D0008 ble cr7,_p__M0_main_program+0x24 ; 0x00002380 0000237C: 48001005 bl _p_RangeCheckError+0x2380 ; 0x00003380 00002380: 93DC0000 stw r30,0(r28) 00002384: 3C5F0003 addis RTOC,r31,3 00002388: 80421BD8 lwz RTOC,7128(RTOC) 0000238C: 2F820001 cmpwi cr7,RTOC,0x0001 00002390: 41BE0008 beq+ cr7,_p__M0_main_program+0x24 ; 0x00002398 00002394: 48000FED bl _p_RangeCheckError+0x2380 ; 0x00003380 00002398: 3B82FFFF subi r28,RTOC,1 0000239C: 5780E8FA rlwinm r0,r28,29,3,29 000023A0: 3C5F0003 addis RTOC,r31,3 000023A4: 38421BD4 addi RTOC,RTOC,7124 000023A8: 7F801214 add r28,r0,RTOC 000023AC: 7FC2002E lwzx r30,RTOC,r0 000023B0: 3BA00000 li r29,0 000023B4: 7F44D378 mr r4,r26 000023B8: 38600000 li r3,0 000023BC: 576506FE clrlwi r5,r27,27 000023C0: 20A5003F subfic r5,r5,63 000023C4: 4802B0B1 bl __ashldi3+0x2C474 ; 0x0002D474 000023C8: 7C69FE70 srawi r9,r3,31 000023CC: 7C6A0670 srawi r10,r3,0 000023D0: 7FA24B78 or RTOC,r29,r9 000023D4: 7FC35378 or r3,r30,r10 000023D8: 7C7E1B78 mr r30,r3 000023DC: 2B820000 cmplwi cr7,RTOC,0x0000 ---> 000023E0: 419D0018 bgt cr7,_p__M0_main_program+0x24 ; 0x000023F8 000023E4: 2F820000 cmpwi cr7,RTOC,0x0000 000023E8: 409E0014 bne cr7,_p__M0_main_program+0x24 ; 0x000023FC 000023EC: 3800FFFF li r0,-1 000023F0: 7F830040 cmpl cr7,0,r3,r0 000023F4: 409D0008 ble cr7,_p__M0_main_program+0x24 ; 0x000023FC ---> 000023F8: 48000F89 bl _p_RangeCheckError+0x2380 ; 0x00003380 000023FC: 93DC0000 stw r30,0(r28) a [ i ]:= true end. 00002400: 38210060 addi SP,SP,96 00002404: 80010008 lwz r0,8(SP) 00002408: 7C0803A6 mtlr r0 0000240C: BB41FFE8 lmw r26,-24(SP) 00002410: 00000238 dc.l 0x00000238 ; Invalid opcode '...8'
It jumps from offset 23E0 (the four CR7 bits are 0 1 0 0) to offset 23F8. Let me know if you need more information.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Waldek Hebisch wrote:
I assume that it fails.
It does.
But the machine code contains 10 comparisons, and it is not clear which one fails.
The last one.
I think the problem was that value to be assigned was internally converted to `Integer' which caused subsequent operation to treat arguments as signed. In particular shifting 1 (`True') from highest bit positions to proper place filled high sub-word with 1-s. Since later we want only low bits the range check failed. AFAICS earlier we would just silently produce wrong code (setting too many bits to 1).
The patch below should fix this:
diff -u p.bb1/expressions.c p/expressions.c --- p.bb1/expressions.c 2005-02-21 05:01:12.000000000 +0100 +++ p/expressions.c 2005-02-22 19:04:04.895349760 +0100 @@ -3652,11 +3652,18 @@ /* Now form a new expression to store the lower part of newrhs in low_lhs. Clear the bits in the target. */ shifted_mask = build_pascal_binary_op (LSHIFT_EXPR, mask, offset); - eraser = build_modify_expr (low_lhs, BIT_AND_EXPR, build_unary_op (BIT_NOT_EXPR, shifted_mask, 0)); + eraser = build_modify_expr (low_lhs, BIT_AND_EXPR, + convert(packed_array_unsigned_short_type_node, + build_unary_op (BIT_NOT_EXPR, shifted_mask, 0))); /* Do the assignment. */ - brush = build_pascal_binary_op (BIT_AND_EXPR, default_conversion (newrhs), mask); + brush = build_pascal_binary_op (BIT_AND_EXPR, + convert(packed_array_unsigned_long_type_node, newrhs), mask); brush = build_pascal_binary_op (LSHIFT_EXPR, brush, offset); - brush = build_pascal_binary_op (BIT_AND_EXPR, brush, TYPE_MAX_VALUE (packed_array_unsigned_short_type_node)); + brush = convert(packed_array_unsigned_long_type_node, brush); + brush = build_pascal_binary_op (BIT_AND_EXPR, brush, + convert(packed_array_unsigned_long_type_node, + TYPE_MAX_VALUE (packed_array_unsigned_short_type_node))); + brush = convert(packed_array_unsigned_short_type_node, brush); brush = build_modify_expr (low_lhs, BIT_IOR_EXPR, brush); low_assignment = build (COMPOUND_EXPR, TREE_TYPE (brush), save_rhs_stmt, build (COMPOUND_EXPR, TREE_TYPE (brush), eraser, brush)); @@ -3664,11 +3671,16 @@ /* Now do the same for the higher part and high_lhs. Prepare shifted_mask to access the higher half. Clear the bits in the target. */ shifted_mask = build (RSHIFT_EXPR, TREE_TYPE (shifted_mask), shifted_mask, TYPE_SIZE (TREE_TYPE (low_lhs))); - eraser = build_modify_expr (high_lhs, BIT_AND_EXPR, build_unary_op (BIT_NOT_EXPR, shifted_mask, 0)); + eraser = build_modify_expr (high_lhs, BIT_AND_EXPR, + convert(packed_array_unsigned_short_type_node, + build_unary_op (BIT_NOT_EXPR, shifted_mask, 0))); /* Do the assignment. */ - brush = build_pascal_binary_op (BIT_AND_EXPR, default_conversion (newrhs), mask); + brush = build_pascal_binary_op (BIT_AND_EXPR, + convert(packed_array_unsigned_long_type_node, newrhs), mask); brush = build_pascal_binary_op (LSHIFT_EXPR, brush, offset); + brush = convert(packed_array_unsigned_long_type_node, brush); brush = build_pascal_binary_op (RSHIFT_EXPR, brush, TYPE_SIZE (TREE_TYPE (low_lhs))); + brush = convert(packed_array_unsigned_short_type_node, brush); brush = build_modify_expr (high_lhs, BIT_IOR_EXPR, brush); /* Construct a COMPOUND_EXPR holding both. */ high_assignment = build (COMPOUND_EXPR, TREE_TYPE (brush), eraser, brush);
Waldek Hebisch wrote:
I think the problem was that value to be assigned was internally converted to `Integer' which caused subsequent operation to treat arguments as signed. In particular shifting 1 (`True') from highest bit positions to proper place filled high sub-word with 1-s. Since later we want only low bits the range check failed. AFAICS earlier we would just silently produce wrong code (setting too many bits to 1).
The patch below should fix this:
Great, this solves the problem !
New testsuite results (some of the failures discussed before)
TEST bprealtest.pas: ./a.out: BP compatible 6 byte `Real' type does not support infinity (error #871 at 2fd3)
TEST fjf1021h.pas: ./fjf1021h.pas:6: error: expressions with side-effects are not allowed in schema types failed
TEST fjf1021i.pas: ./fjf1021i.pas:8: error: expressions with side-effects are not allowed in schema types failed
TEST fjf659o.pas: ./test_run: line 345: 16184 Segmentation fault ./"$A_OUT" "$1"
TEST fjf998r.pas: failed:
TEST longr2.pas: dummy.pas: In main program: dummy.pas:2: error: real constant out of range
Regards,
Adriaan van Os
Adriaan van Os wrote:
Waldek Hebisch wrote:
I think the problem was that value to be assigned was internally converted to `Integer' which caused subsequent operation to treat arguments as signed. In particular shifting 1 (`True') from highest bit positions to proper place filled high sub-word with 1-s. Since later we want only low bits the range check failed. AFAICS earlier we would just silently produce wrong code (setting too many bits to 1).
The patch below should fix this:
Great, this solves the problem !
Good, I'm applying it. (Causes no regressions for me.)
Frank
Waldek Hebisch wrote:
Backtrace for fjf659o.pas:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x000e6014
Thread 0 Crashed: 0 a.out 0x0000eeb4 _p_Write_Init + 0x34 (files.pas:518) 1 a.out 0x0000231c _p__M0_main_program + 0xac (fjf659o.pas:10) 2 a.out 0x00002470 main + 0x34 (<implicit code>:12) 3 a.out 0x00001ea8 _start + 0x188 (crt.c:267) 4 dyld 0x8fe1a558 _dyld_start + 0x64
Looks like _p_Write_Init is accessing freed file. We either need `Finalize' to set its argument to an invalid file (FDR) or to nil. In the second case all IO routines would have to check for nil.
First of all, fjf659o.pas is a strange test program anyway. I was wondering about it, and it was on my list of things to have a closer look at again. So if it fails now, I don't consider it serious anyway.
It's supposed to test that `Finalize' does something for files. But what exactly it does, might better be left undefined. So, when the test program checks for a I/O error that can be caught, this might simply be too optimistic. (And file handling has changed internally since it was written, so it's possible that originally, it either caused a bad access that wasn't noticed, as now, or it didn't and does now.)
Anyway, I'm ready to retract this test program, unless it's really a symptom of a real problem (which it doesn't seem so far). Or to change the test program to test it somehow differently (not sure yet exactly how, but perhaps there's something with low-level TFDD interfaces, I'll try it ...)
Frank
Frank Heckenbach wrote:
Waldek Hebisch wrote:
Backtrace for fjf659o.pas:
Anyway, I'm ready to retract this test program, unless it's really a symptom of a real problem (which it doesn't seem so far). Or to change the test program to test it somehow differently (not sure yet exactly how, but perhaps there's something with low-level TFDD interfaces, I'll try it ...)
The attached version should do it. (Again, if you think there's a real problem here, we should discuss it, but if it's only this particular test, I think we can leave it at that.) fjf219c.pas had a similar problem (also questionable in the previous test program).
Frank
Frank Heckenbach wrote:
The attached version should do it. (Again, if you think there's a real problem here, we should discuss it, but if it's only this particular test, I think we can leave it at that.) fjf219c.pas had a similar problem (also questionable in the previous test program).
Both tests passed.
Regards,
Adriaan van Os
Frank Heckenbach wrote:
First of all, fjf659o.pas is a strange test program anyway. I was wondering about it, and it was on my list of things to have a closer look at again. So if it fails now, I don't consider it serious anyway.
It's supposed to test that `Finalize' does something for files. But what exactly it does, might better be left undefined. So, when the test program checks for a I/O error that can be caught, this might simply be too optimistic. (And file handling has changed internally since it was written, so it's possible that originally, it either caused a bad access that wasn't noticed, as now, or it didn't and does now.)
I think that it is not nice to crash. IMHO we should very clearly state in the documentation that access to a variable after calling `Finalize' on it is illegal, or make it more robust.
BTW do Delphi allow `Finalize' on files?
Waldek Hebisch wrote:
Frank Heckenbach wrote:
First of all, fjf659o.pas is a strange test program anyway. I was wondering about it, and it was on my list of things to have a closer look at again. So if it fails now, I don't consider it serious anyway.
It's supposed to test that `Finalize' does something for files. But what exactly it does, might better be left undefined. So, when the test program checks for a I/O error that can be caught, this might simply be too optimistic. (And file handling has changed internally since it was written, so it's possible that originally, it either caused a bad access that wasn't noticed, as now, or it didn't and does now.)
I think that it is not nice to crash. IMHO we should very clearly state in the documentation that access to a variable after calling `Finalize' on it is illegal,
I'd say so -- that's the purpose of `Finalize' after all. It's meant to be used, e.g., for variables allocated via pointers in memory mapped explicitly for some reason (i.e., not allocated with `New'). Since initialization and clean-up here cannot be done automatically as is done by `New' and `Dispose' (or for non-pointer variables on entry/exit of scope), there has to be an explicit statement. But using the variable after `Finalize' (and before a new `Initialize') should be wrong by definition IMHO. I'm adding a note in the documentation.
BTW, I have plans to change the internal structure of files again (not urgent). These will probably make access after `Finalize' not crash, but treat the file just as closed and unbound. But that's not my primary motivation for the change, and I wouldn't like to officially guarantee that behaviour then either.
Frank
Frank Heckenbach wrote:
BTW, I have plans to change the internal structure of files again (not urgent). These will probably make access after `Finalize' not crash, but treat the file just as closed and unbound. But that's not my primary motivation for the change, and I wouldn't like to officially guarantee that behaviour then either.
IMHO we can easily get such behaviour with current structure. We just need to pre-allocate one "invalid" FDR and change `Finalize' so that a) it does not mess with this FDR b) after finalization it makes files point to this FDR
Waldek Hebisch wrote:
Frank Heckenbach wrote:
BTW, I have plans to change the internal structure of files again (not urgent). These will probably make access after `Finalize' not crash, but treat the file just as closed and unbound. But that's not my primary motivation for the change, and I wouldn't like to officially guarantee that behaviour then either.
IMHO we can easily get such behaviour with current structure. We just need to pre-allocate one "invalid" FDR and change `Finalize' so that a) it does not mess with this FDR b) after finalization it makes files point to this FDR
I guess we could do so. I'm just not convinced whether we should. IMHO access after `Finalize' is just as invalid as access trough a dangling pointer or whatever. We don't check the latter (and probably won't do anytime soon), so is there anything special about `Finalize'?
However, with your method I see a problem as well: If someone actually accesses files after `Finalize' they will use this dummy FDR. So they could do any kind of operations with it. And several finalized files would even share this FDR which could lead to quite a mess AFAICS.
What I'll rather do is to set the pointer to nil on `Finalize' so that every attempt to use it will fail right away (reliably and at the point of the first invalid access, rather than randomly sometime later).
Frank
On 5 Mar 2005 at 2:46, Waldek Hebisch wrote:
Frank Heckenbach wrote:
First of all, fjf659o.pas is a strange test program anyway. I was wondering about it, and it was on my list of things to have a closer look at again. So if it fails now, I don't consider it serious anyway.
It's supposed to test that `Finalize' does something for files. But what exactly it does, might better be left undefined. So, when the test program checks for a I/O error that can be caught, this might simply be too optimistic. (And file handling has changed internally since it was written, so it's possible that originally, it either caused a bad access that wasn't noticed, as now, or it didn't and does now.)
I think that it is not nice to crash. IMHO we should very clearly state in the documentation that access to a variable after calling `Finalize' on it is illegal, or make it more robust.
BTW do Delphi allow `Finalize' on files?
Yes. But with this "hint": 'Expression needs no Initialize/Finalize'.
From what I can see, "Finalize" does nothing to files - e.g., you can
still read from a file after Finalizing it (as long as it has not been Closed).
This is the Delphi 7 help information on Finalize:
"procedure Finalize( var V [; Count: Integer] );
Description
Finalize should be used only in Delphi code where a dynamically allocated variable is deallocated by other means than the Dispose procedure. Dynamic arrays can never be deallocated using the Dispose procedure, but can be freed by passing them to Finalize.
For global variables, local variables, objects, and dynamic variables deallocated using Dispose, the compiler generates code that finalizes all long strings, variants, and interfaces contained by the variable when the instance is destroyed.
If a dynamic variable meets the following two conditions, a call to Finalize is required to finalize the variable before it can be deallocated.
The variable is deallocated by other means than the Dispose standard procedure (for example using FreeMem). The variable contains long strings, variants, or interfaces, not all of which are empty or Unassigned.
Finalize simply sets all long strings to empty and all variants and interfaces to Unassigned, thus properly releasing any memory that was referenced by the long strings and variants.
In cases where several variables are deallocated in a contiguous memory block such as a dynamically allocated array of strings, the additional Count parameter can be specified to finalize all variables in one operation.
If the variable specified in a call to Finalize contains no long strings, variants, or interfaces, the compiler eliminates the call and generates no code for it."
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
On Sat, Feb 19, 2005 at 03:03:56PM +0100, Frank Heckenbach wrote:
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Waldek, many of these failure seem to be side-effects of the fjf1018 patch.
That is incompatible change. If we want fjf1018.pas to be accepted by default then: filehand.pas, fjf684.pas, fjf751k.pas, fjf751l.pas, fjf800.pas, random.pas are invalid.
Indeed, BP doesn't accept such programs.
Personally I woud prefer to accept fjf1018.pas only in BP mode.
OK.
If someone else wants to try it, use this patch and add `{$borland-pascal}' in test/fjf1018[acu.pas].
New test results on Linux/IA32:
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: aregextest.pas FAIL: baby.pas
=== gpc Summary ===
# of tests 4537 # of expected passes 4535 # of unexpected failures 1 # of unsupported tests 1
TEST baby.pas: ./a.out: value out of range (error #300 at 804d70a)
Which means:
- The patch works.
- Failures of awindtes* and dostest* also went away.
- As for baby.pas: I found meanwhile that it is the same problem which I reported in another mail, i.e., inability to allocate more than about 128kB of memory. The offending range check happens after the increment in AddHeapRange in rts/heap.pas:
procedure AddHeapRange (p: Pointer; Size: SizeType); var Address: PtrCard; begin Address := PtrCard (p); if (HeapLow = 0) or (Address < HeapLow) then HeapLow := Address; Inc (Address, Size - 1); if Address > HeapHigh then HeapHigh := Address end;
Disassembling the code reveals:
Dump of assembler code for function AddHeapRange: 0x0804eef0 <AddHeapRange+0>: push %ebp 0x0804eef1 <AddHeapRange+1>: mov %esp,%ebp 0x0804eef3 <AddHeapRange+3>: sub $0x8,%esp 0x0804eef6 <AddHeapRange+6>: mov 0x80786a4,%eax 0x0804eefb <AddHeapRange+11>: mov 0x8(%ebp),%edx 0x0804eefe <AddHeapRange+14>: test %eax,%eax 0x0804ef00 <AddHeapRange+16>: je 0x804ef06 <AddHeapRange+22> 0x0804ef02 <AddHeapRange+18>: cmp %eax,%edx 0x0804ef04 <AddHeapRange+20>: jae 0x804ef0c <AddHeapRange+28> 0x0804ef06 <AddHeapRange+22>: mov %edx,0x80786a4 0x0804ef0c <AddHeapRange+28>: mov 0xc(%ebp),%eax 0x0804ef0f <AddHeapRange+31>: lea 0xffffffff(%eax,%edx,1),%eax 0x0804ef13 <AddHeapRange+35>: test %eax,%eax 0x0804ef15 <AddHeapRange+37>: js 0x804ef26 <AddHeapRange+54> ^^^^^^ 0x0804ef17 <AddHeapRange+39>: cmp 0x80786a8,%eax 0x0804ef1d <AddHeapRange+45>: jbe 0x804ef24 <AddHeapRange+52> 0x0804ef1f <AddHeapRange+47>: mov %eax,0x80786a8 0x0804ef24 <AddHeapRange+52>: leave 0x0804ef25 <AddHeapRange+53>: ret 0x0804ef26 <AddHeapRange+54>: call 0x8049fde <_p_RangeCheckError> End of assembler dump.
I.e., the range check fails if the result is negative, when interpreted as a signed integer. This is wrong, as all types involved are unsigned, and malloc() can easily return a pointer larger than $80000000. This also means that the 128kB threshold is rather random, and the test failure is heavily system dependent (thus hard to reproduce).
The test indeed passed when I put {$local R-} around "Inc (Address, Size - 1)".
Emil
Emil Jerabek wrote:
TEST baby.pas: ./a.out: value out of range (error #300 at 804d70a)
Which means:
The patch works.
Failures of awindtes* and dostest* also went away.
As for baby.pas: I found meanwhile that it is the same problem which
I reported in another mail, i.e., inability to allocate more than about 128kB of memory. The offending range check happens after the increment in AddHeapRange in rts/heap.pas:
procedure AddHeapRange (p: Pointer; Size: SizeType); var Address: PtrCard; begin Address := PtrCard (p); if (HeapLow = 0) or (Address < HeapLow) then HeapLow := Address; Inc (Address, Size - 1);
^^^^
if Address > HeapHigh then HeapHigh := Address end;
Disassembling the code reveals:
0x0804ef0f <AddHeapRange+31>: lea 0xffffffff(%eax,%edx,1),%eax 0x0804ef13 <AddHeapRange+35>: test %eax,%eax 0x0804ef15 <AddHeapRange+37>: js 0x804ef26 <AddHeapRange+54> ^^^^^^
Unfortunatly, this is correct translation of the above line according to current rules: 1 is of type integer (so it is considerd signed). Currently substractiong or adding Integer to Carginal gives Integer (same precision, signed result), so substracting 1 from size give result of type Integer. Also (Size - 1) to Address gives signed result. Since Address is unsigned range checking kicks in: it considers negative result illegal.
Somewhat similar problems hit on AMD64, but this one is worse. We were discussing privatly with Frank rules for choosing result type of arithmetic operations. This particular case can be easily fixed by making type rules slightly smarter (it is not much effort to realize that 1 do not need sign), but it is large effort to make RTS work with range checking and without using excess precision.
Waldek Hebisch wrote:
procedure AddHeapRange (p: Pointer; Size: SizeType); var Address: PtrCard; begin Address := PtrCard (p); if (HeapLow = 0) or (Address < HeapLow) then HeapLow := Address; Inc (Address, Size - 1);
^^^^
if Address > HeapHigh then HeapHigh := Address end;
Disassembling the code reveals:
0x0804ef0f <AddHeapRange+31>: lea 0xffffffff(%eax,%edx,1),%eax 0x0804ef13 <AddHeapRange+35>: test %eax,%eax 0x0804ef15 <AddHeapRange+37>: js 0x804ef26 <AddHeapRange+54> ^^^^^^
Unfortunatly, this is correct translation of the above line according to current rules: 1 is of type integer (so it is considerd signed). Currently substractiong or adding Integer to Carginal gives Integer (same precision, signed result), so substracting 1 from size give result of type Integer. Also (Size - 1) to Address gives signed result. Since Address is unsigned range checking kicks in: it considers negative result illegal.
Somewhat similar problems hit on AMD64, but this one is worse. We were discussing privatly with Frank rules for choosing result type of arithmetic operations. This particular case can be easily fixed by making type rules slightly smarter (it is not much effort to realize that 1 do not need sign),
The attached patch should do this (and thus also avoid this problem without turning off range-checking).
but it is large effort to make RTS work with range checking and without using excess precision.
Indeed.
Frank
Hi
It seems that MaxLongint is declared twice in system.pas (once by importing from the GPC unit, and once by explicit declaration). I think one of them should go.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
It seems that MaxLongint is declared twice in system.pas (once by importing from the GPC unit, and once by explicit declaration). I think one of them should go.
The imported one is renamed:
import GPC (MaxLongInt => GPC_MaxLongInt);
So the explicit declaration is valid (and necessary if BP types sizes are wanted).
Did you get an error about it?
Frank
On 22 Feb 2005 at 3:19, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
It seems that MaxLongint is declared twice in system.pas (once by importing from the GPC unit, and once by explicit declaration). I think one of them should go.
The imported one is renamed:
import GPC (MaxLongInt => GPC_MaxLongInt);
So the explicit declaration is valid (and necessary if BP types sizes are wanted).
Did you get an error about it?
Yes - about "bad import" and "redeclaration of `MaxLongint'". But the problem happened becauses of mixing "import" and "uses", which I have now changed.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 22 Feb 2005 at 3:19, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
It seems that MaxLongint is declared twice in system.pas (once by importing from the GPC unit, and once by explicit declaration). I think one of them should go.
The imported one is renamed:
import GPC (MaxLongInt => GPC_MaxLongInt);
So the explicit declaration is valid (and necessary if BP types sizes are wanted).
Did you get an error about it?
Yes - about "bad import" and "redeclaration of `MaxLongint'". But the problem happened becauses of mixing "import" and "uses", which I have now changed.
Did you import/use both `GPC' and `System', or what did you do?
Frank
On 22 Feb 2005 at 17:01, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
On 22 Feb 2005 at 3:19, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
It seems that MaxLongint is declared twice in system.pas (once by importing from the GPC unit, and once by explicit declaration). I think one of them should go.
The imported one is renamed:
import GPC (MaxLongInt => GPC_MaxLongInt);
So the explicit declaration is valid (and necessary if BP types sizes are wanted).
Did you get an error about it?
Yes - about "bad import" and "redeclaration of `MaxLongint'". But the problem happened becauses of mixing "import" and "uses", which I have now changed.
Did you import/use both `GPC' and `System', or what did you do?
The program used a combination of "units" and "modules", involving "uses system" and "import gpc" respectively. So I changed the modules to units and did away with the "import gpc".
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
The program used a combination of "units" and "modules", involving "uses system" and "import gpc" respectively. So I changed the modules to units and did away with the "import gpc".
You could either `uses GPC' (this doesn't complain about duplicates, BP compatible), or `import GPC' and rename one of the offending identifiers.
Frank
On 23 Feb 2005 at 3:06, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
The program used a combination of "units" and "modules", involving "uses system" and "import gpc" respectively. So I changed the modules to units and did away with the "import gpc".
You could either `uses GPC' (this doesn't complain about duplicates, BP compatible), or `import GPC' and rename one of the offending identifiers.
Can one use "uses" in a module?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 23 Feb 2005 at 3:06, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
The program used a combination of "units" and "modules", involving "uses system" and "import gpc" respectively. So I changed the modules to units and did away with the "import gpc".
You could either `uses GPC' (this doesn't complain about duplicates, BP compatible), or `import GPC' and rename one of the offending identifiers.
Can one use "uses" in a module?
Yes.
Frank
Prof. Abimbola A. Olowofoyeku wrote:
Can one use "uses" in a module?
Yes, both are allowed. You can `import' a unit and use a module with `uses'. Both form are allowed both inside modules and units. `uses' used to be more flexible then `import' but now `import' is more powerfull. Namely, `import' allows renames, qualified or selective import:
import GPC qualified;
will do qualified and hence _never_ signal a conflict.
import GPC only (MaxLongInt, ExitCode);
will import only `MaxLongInt' and `ExitCode'. You can use `import' in routines:
functin GetMax : LongInt; import GPC; begin GetMax := MaxLongInt end;
In this case imported identifiers from GPC are visible only inside `GetMax'.
I wrote some time ago:
To clarify rules that I have implemented: for redefinitions it does not matter if you have modules or units. The distinction is made only between `import' and `uses':
import GPC; System;
signals error, while
uses GPC; System;
gives no error. My resoning was that typically exporter can not predict conflicts. On the other hands in importing (`using') module/unit one can decide what is proper way to resolve conflicts. IMHO for new code preffered way is qualified import plus renames. For quick fix in existing code one can change `import' to `uses'.
Later I wrote:
In standard units (`dos.pas' ...) we do:
import GPC (MaxLongInt => Orig_GPC_Maxlongint); System;
the rename prevents the conflict.
On 24 Feb 2005 at 3:05, Waldek Hebisch wrote:
Prof. Abimbola A. Olowofoyeku wrote:
Can one use "uses" in a module?
Yes, both are allowed. You can `import' a unit and use a module with `uses'. Both form are allowed both inside modules and units. `uses' used to be more flexible then `import' but now `import' is more powerfull. Namely, `import' allows renames, qualified or selective import:
[...]
Ok, thanks.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
I have a small, rather trivial, question.
How do I access the compile date (and/or time) of a program so I can display it to the used when asked.
e.g. I would like to write...
writeln('Compile on:',__DATE__, __TIME__); { borrowing from c }
or put it up in my MacOSX GUI 'About' box...
SetDialogItemText(theItem, {$I %DATE%}); { Free Pascal way to add compile date }
Is there a way to do this with GPC?
Regards, Steven
Steven Borley wrote:
I have a small, rather trivial, question.
How do I access the compile date (and/or time) of a program so I can display it to the used when asked.
e.g. I would like to write...
writeln('Compile on:',__DATE__, __TIME__); { borrowing from c }
You guessed (what you wrote just works).
Hi
It seems that "{$R-}" does not work in units to turn off range checking, and that one has to use it in the main program. Is this by design?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
It seems that "{$R-}" does not work in units to turn off range checking, and that one has to use it in the main program. Is this by design?
No, this "works" for me (says 11). Can you give an example?
{$R-}
unit MyUnit;
interface
var i: 1 .. 10;
procedure p;
implementation
procedure p; begin Inc (i) end;
end.
program MyProg;
uses MyUnit;
begin i := 10; p; WriteLn (i) end.
Frank
On 22 Feb 2005 at 17:01, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
It seems that "{$R-}" does not work in units to turn off range checking, and that one has to use it in the main program. Is this by design?
No, this "works" for me (says 11). Can you give an example?
[...]
It works in simple programs like this. It does not work in a big and complicated program that I have, while it works in another big and complicated program. I will continue to investigate ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 22 Feb 2005 at 17:01, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
It seems that "{$R-}" does not work in units to turn off range checking, and that one has to use it in the main program. Is this by design?
No, this "works" for me (says 11). Can you give an example?
[...]
It works in simple programs like this. It does not work in a big and complicated program that I have, while it works in another big and complicated program. I will continue to investigate ...
Are you sure the range error occurs in the unit with `{$R-}' (not e.g., in a calling or called unit or the RTS)?
You find out, you can:
- compile the program with debug info (`-g')
- run the program (not the compiler) with `--gpc-rts=-Eerror.log' as the first option
- look the the file `error.log' after a runtime error and pipe it though `addr2line -e path-to-your-executable'
This will show the routines called at the time of error. If the one before the error handling routines (in error.pas) is also in the RTS, it might be an RTS range-check error which we'll have to fix.
Frank
On 23 Feb 2005 at 5:02, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
On 22 Feb 2005 at 17:01, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
It seems that "{$R-}" does not work in units to turn off range checking, and that one has to use it in the main program. Is this by design?
No, this "works" for me (says 11). Can you give an example?
[...]
It works in simple programs like this. It does not work in a big and complicated program that I have, while it works in another big and complicated program. I will continue to investigate ...
Are you sure the range error occurs in the unit with `{$R-}' (not e.g., in a calling or called unit or the RTS)?
You find out, you can:
compile the program with debug info (`-g')
run the program (not the compiler) with `--gpc-rts=-Eerror.log' as the first option
look the the file `error.log' after a runtime error and pipe it though `addr2line -e path-to-your-executable'
This will show the routines called at the time of error. If the one before the error handling routines (in error.pas) is also in the RTS, it might be an RTS range-check error which we'll have to fix.
I don't really understand these things, so I'll give you the results - error.log: value out of range (error #300 at 442b71) 442b71 Routines called: 44fa7c 44fb61 44e1ec 442b71 43d041 401cff 4026d3 421551 421509 41feeb 41c63a 77d48708 77d487ea 77d4b742 77d4b7aa
Output of "addr2line -e instdemo.exe < error.log" : ??:0 d:/gpc/obj/objects.pas:2816 ??:0 D:/gpc/win32/<implicit code>:400 D:/gpc/win32/<implicit code>:400 D:/gpc/win32/<implicit code>:400 d:/gpc/obj/objects.pas:2816 d:/gpc/win32/cclasses.pas:826 d:/gpc/win32/instdemo.pas:171 d:/gpc/win32/instdemo.pas:274 d:/gpc/win32/cwindows.pas:2056 d:/gpc/win32/cwindows.pas:2031 d:/gpc/win32/cwindows.pas:1770 d:/gpc/win32/cwindows.pas:860 ??:0 ??:0 ??:0 ??:0
What does this all mean?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 23 Feb 2005 at 5:02, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
On 22 Feb 2005 at 17:01, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
It seems that "{$R-}" does not work in units to turn off range checking, and that one has to use it in the main program. Is this by design?
No, this "works" for me (says 11). Can you give an example?
[...]
It works in simple programs like this. It does not work in a big and complicated program that I have, while it works in another big and complicated program. I will continue to investigate ...
Are you sure the range error occurs in the unit with `{$R-}' (not e.g., in a calling or called unit or the RTS)?
You find out, you can:
compile the program with debug info (`-g')
run the program (not the compiler) with `--gpc-rts=-Eerror.log' as the first option
look the the file `error.log' after a runtime error and pipe it though `addr2line -e path-to-your-executable'
This will show the routines called at the time of error. If the one before the error handling routines (in error.pas) is also in the RTS, it might be an RTS range-check error which we'll have to fix.
I don't really understand these things, so I'll give you the results - error.log: value out of range (error #300 at 442b71) 442b71 Routines called: 44fa7c 44fb61 44e1ec 442b71 43d041 401cff 4026d3 421551 421509 41feeb 41c63a 77d48708 77d487ea 77d4b742 77d4b7aa
Output of "addr2line -e instdemo.exe < error.log" : ??:0 d:/gpc/obj/objects.pas:2816 ??:0 D:/gpc/win32/<implicit code>:400 D:/gpc/win32/<implicit code>:400 D:/gpc/win32/<implicit code>:400 d:/gpc/obj/objects.pas:2816 d:/gpc/win32/cclasses.pas:826 d:/gpc/win32/instdemo.pas:171 d:/gpc/win32/instdemo.pas:274 d:/gpc/win32/cwindows.pas:2056 d:/gpc/win32/cwindows.pas:2031 d:/gpc/win32/cwindows.pas:1770 d:/gpc/win32/cwindows.pas:860 ??:0 ??:0 ??:0 ??:0
What does this all mean?
Did you build the RTS with `-g'? I suppose not, so the RTS entries cannot be resolved by addr2line and are (for some strange reasons) reported as `<implicit code>:400'.
But since there are only three such entries (I get four in my test, but it may depend on optimization settings and perhaps backend versions), I suppose they correspond to the error handling routines (with a `-g' RTS, we'd know more certainly). This suggests that the range check error is indeed raised in line 2816 (+/-1 due to GPC line inaccuracies) of objects.pas (and not in a RTS routine called from there). Are you sure this part was compiled with `{$R-}'? What does this code do?
Frank
On 24 Feb 2005 at 3:00, Frank Heckenbach wrote:
[...]
Output of "addr2line -e instdemo.exe < error.log" : ??:0 d:/gpc/obj/objects.pas:2816 ??:0 D:/gpc/win32/<implicit code>:400 D:/gpc/win32/<implicit code>:400 D:/gpc/win32/<implicit code>:400 d:/gpc/obj/objects.pas:2816 d:/gpc/win32/cclasses.pas:826 d:/gpc/win32/instdemo.pas:171 d:/gpc/win32/instdemo.pas:274 d:/gpc/win32/cwindows.pas:2056 d:/gpc/win32/cwindows.pas:2031 d:/gpc/win32/cwindows.pas:1770 d:/gpc/win32/cwindows.pas:860 ??:0 ??:0 ??:0 ??:0
What does this all mean?
Did you build the RTS with `-g'? I suppose not,
No.
so the RTS entries cannot be resolved by addr2line and are (for some strange reasons) reported as `<implicit code>:400'.
But since there are only three such entries (I get four in my test, but it may depend on optimization settings and perhaps backend versions), I suppose they correspond to the error handling routines (with a `-g' RTS, we'd know more certainly). This suggests that the range check error is indeed raised in line 2816 (+/-1 due to GPC line inaccuracies) of objects.pas (and not in a RTS routine called from there).
Indeed, that was the problem.
Are you sure this part was compiled with `{$R-}'?
The program itself was compiled with "{$R-}", but not that unit.
What does this code do?
Bug (does things with "Items [foo - 1]" without first checking that "foo > 0").
This range checking thing is very useful indeed :-)
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
On Mon, Feb 21, 2005 at 03:37:13PM +0100, Waldek Hebisch wrote:
Emil Jerabek wrote:
TEST baby.pas: ./a.out: value out of range (error #300 at 804d70a)
Which means:
The patch works.
Failures of awindtes* and dostest* also went away.
As for baby.pas: I found meanwhile that it is the same problem which
I reported in another mail, i.e., inability to allocate more than about 128kB of memory. The offending range check happens after the increment in AddHeapRange in rts/heap.pas:
procedure AddHeapRange (p: Pointer; Size: SizeType); var Address: PtrCard; begin Address := PtrCard (p); if (HeapLow = 0) or (Address < HeapLow) then HeapLow := Address; Inc (Address, Size - 1);
^^^^
if Address > HeapHigh then HeapHigh := Address end;
Disassembling the code reveals:
0x0804ef0f <AddHeapRange+31>: lea 0xffffffff(%eax,%edx,1),%eax 0x0804ef13 <AddHeapRange+35>: test %eax,%eax 0x0804ef15 <AddHeapRange+37>: js 0x804ef26 <AddHeapRange+54> ^^^^^^
Unfortunatly, this is correct translation of the above line according to current rules: 1 is of type integer (so it is considerd signed). Currently substractiong or adding Integer to Carginal gives Integer (same precision, signed result), so substracting 1 from size give result of type Integer. Also (Size - 1) to Address gives signed result. Since Address is unsigned range checking kicks in: it considers negative result illegal.
Hmm. What I would expect from range checking is that the expression is computed with unlimited precision, and then the result is checked to fit in the destination type (conceptually, it doesn't have to be implemented this way). In other words, the type of the expression is not determined by types of operands, but by its environment.
In this example, Size - 1 should indeed be of type Integer, not because it is Cardinal - Integer, but because the second argument of Inc is declared as Integer (or at least, it is documented as such). Then adding (Size - 1) to Address should give a result of type SizeType (which is unsigned), because it is assigned back to Address.
I understand that this is essentially impossible to implement efficiently, since intermediary results in complex expressions would have to be computed with extra precision. However, this problem should not arise in the example above, because the only intermediary result here (Size - 1) is explicitely typed as Integer by the declaration of Inc.
Somewhat similar problems hit on AMD64, but this one is worse. We were discussing privatly with Frank rules for choosing result type of arithmetic operations. This particular case can be easily fixed by making type rules slightly smarter (it is not much effort to realize that 1 do not need sign), but it is large effort to make RTS work with range checking and without using excess precision.
-- Waldek Hebisch hebisch@math.uni.wroc.pl
On Mon, Feb 21, 2005 at 05:48:35PM +0100, Frank Heckenbach wrote: [...]
The attached patch should do this (and thus also avoid this problem without turning off range-checking).
It solves the problem in AddHeapRange, but seems to introduce another failure.
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: aregextest.pas FAIL: bprealtest.pas
=== gpc Summary ===
# of tests 4537 # of expected passes 4535 # of unexpected failures 1 # of unsupported tests 1
TEST bprealtest.pas: ./a.out: error in exponentiation (Numerical result out of range) (error #700 at 804b08a)
Emil Jerabek
Emil Jerabek wrote:
Hmm. What I would expect from range checking is that the expression is computed with unlimited precision, and then the result is checked to fit in the destination type (conceptually, it doesn't have to be implemented this way). In other words, the type of the expression is not determined by types of operands, but by its environment.
In this example, Size - 1 should indeed be of type Integer, not because it is Cardinal - Integer, but because the second argument of Inc is declared as Integer (or at least, it is documented as such).
I'm changing the documentation. If it were so, it would preclude using larger integer types than `Integer', which is in fact allowed. So any integer type is allowed for the second argument in fact.
Then adding (Size - 1) to Address should give a result of type SizeType (which is unsigned), because it is assigned back to Address.
I understand that this is essentially impossible to implement efficiently, since intermediary results in complex expressions would have to be computed with extra precision.
Yes. It's a nice idea (though IMHO not directly related with the range checking feature -- which does just what it says, i.e. do additional checks), but very difficult to implement.
However, this problem should not arise in the example above, because the only intermediary result here (Size - 1) is explicitely typed as Integer by the declaration of Inc.
Unfortunately not, see above. `Inc (a, b)' is really equivalent to `a := a + b', while evaluating the reference to `a' only once.
It solves the problem in AddHeapRange, but seems to introduce another failure.
TEST bprealtest.pas: ./a.out: error in exponentiation (Numerical result out of range) (error #700 at 804b08a)
Yes, I get this as well. The problem is this line:
x.r := (Random + 1e-6) * Exp (Random (86) - 43);
`Random' (with one argument) is declared to have a result of type `LongestCard'. Now, after making the constant (43) unsigned, we have a difference of two `LongestCard' values.
Differences of unsigned values are a tricky part. As I've just discussed with Waldek, I don't think we can make them signed (of the same precision), because then we'd have no way of computing differences such as `High (LongestCard) - 1'. While most other type selections also preclude some possibly results, it's at least possible to get them with (range-safe) type conversions, e.g. if the sum of two `LongestInt' values is signed (which is reasonable), one cannot directly get results larger than `High (LongestInt)'. But one can check if both values are >= 0 (only then this can happen), then assign them both to `LongestCard' variables (this is no dangerous type-cast, but just an assignment we know cannot range-fail), and add those.
For differences of large unsigned values, we have no such recourse. Therefore IMHO they need to produce unsigned results. If possible, we can use higher precision for the result, and then a signed type, which covers all possible results. But if the operands are already of the largest type, this isn't possible, and that's the case in this example.
Of course, we could work-around it in this example by an explicit cast or conversion, and perhaps that's actually what we *should* do, given that `Random' is of type `LongestCard'. So this failure is easy to fix, I'm just not certain if there are more serious problems like this ...
Ironically, that's just caused by making a constant to be unsigned. But I don't see a better way to choose the "signedness" of positive constants. Always making them signed (if the range matches) if what we've done before, and it caused problems in heap.pas. Of course, these problems were also easy to work-around, as was noted here. So one could ask which kind of problem is more common. I think it's the one in heap.pas, while here in bprealtest.pas we have a `LongestCard' value that we in fact know must be < 86 (but the compiler doesn't know). So making constants unsigned still seems a bit preferable.
Another idea would be to derive the constant's signedness from the other operand. While probably not too difficult, it wouldn't actually help here, since the other operand *is* unsigned, so it's probably not helpful ...
Finally, one could think of changing the result type of `Random'. Making it `LongestInt' would reduce the available range.
However, we could have different versions for `LongestCard' and plain `Cardinal', and choose the one to use based on the argument type. As we do this for other built-ins (e.g. `Write'), and it would fix this problem, and would probably even be somewhat more efficient, perhaps we should do this ...
Frank
I wrote:
Emil Jerabek wrote:
It solves the problem in AddHeapRange, but seems to introduce another failure.
TEST bprealtest.pas: ./a.out: error in exponentiation (Numerical result out of range) (error #700 at 804b08a)
Yes, I get this as well. The problem is this line:
x.r := (Random + 1e-6) * Exp (Random (86) - 43);
Of course, we could work-around it in this example by an explicit cast or conversion, and perhaps that's actually what we *should* do, given that `Random' is of type `LongestCard'. So this failure is easy to fix, I'm just not certain if there are more serious problems like this ...
Finally, one could think of changing the result type of `Random'.
However, we could have different versions for `LongestCard' and plain `Cardinal', and choose the one to use based on the argument type. As we do this for other built-ins (e.g. `Write'), and it would fix this problem, and would probably even be somewhat more efficient, perhaps we should do this ...
However, it wouldn't solve the problem on 64 bit platforms until we have 128 bit types, and it would create additional complications WRT RandIntPtr.
So what I do now instead is to simply convert the result to LongestInt if the argument is known (at compile time) to fit (because the result cannot be larger than the argument). I think this should close the issue WRT `Random' and thus `bprealtest.pas'. One can still get larger random ranges (up to `High (LongestCard)'), and in this case, one must obviously be prepared to handle the large range in one's code.
Frank
HI
Just ran the testsuite (Mingw, based on gcc-3.2.3). There were some failures (I have updated the compiler sources with the post-release patches, but I did not update the test programs). Anyway, these are the failures:
TEST avo7.pas: gpc1.exe: warnings being treated as errors ./avo7.pas:5: warning: identifiers should not start with an underscore failed
TEST bprealtest.pas: d:\src\mingw\gcc-3.2.3\gcc\p\test\a.exe: error in exponentiation (Result too large) (error #700 at 402275)
TEST filehand.pas: ./filehand.pas: In main program: ./filehand.pas:11: statement used as an expression failed
TEST fjf1021d.pas: ./fjf1021d.pas:7: expressions with side-effects are not allowed in schema types failed
TEST fjf1021h.pas: ./fjf1021h.pas:6: expressions with side-effects are not allowed in schema types failed
TEST fjf1021i.pas: ./fjf1021i.pas:8: expressions with side-effects are not allowed in schema types failed
TEST fjf1021j.pas: ./fjf1021j.pas:6: expressions with side-effects are not allowed in schema types failed
TEST fjf751k.pas: ./fjf751k.pas: In main program: ./fjf751k.pas:8: argument to `WriteLn' is of wrong type failed
TEST fjf751l.pas: ./fjf751l.pas: In main program: ./fjf751l.pas:8: argument to `WriteLn' is of wrong type failed
TEST fjf800.pas: ./fjf800.pas:65: redeclaration of `Fjf800' ./fjf800.pas:1: previous declaration ./fjf800.pas:65: redeclaration of `Fjf800' ./fjf800.pas:1: previous declaration failed
TEST random.pas: ./random.pas: In main program: ./random.pas:22: invalid operands to `*' ./random.pas:22: invalid operands to `*' failed
TEST y2k.pas: failed 1999 1999
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Emil Jerabek wrote:
I.e., the range check fails if the result is negative, when interpreted as a signed integer. This is wrong, as all types involved are unsigned, and malloc() can easily return a pointer larger than $80000000. This also means that the 128kB threshold is rather random, and the test failure is heavily system dependent (thus hard to reproduce).
The test indeed passed when I put {$local R-} around "Inc (Address, Size - 1)".
Excellent analysis. The workaround also solves the "systemtest.pas" crash on Mac OS X.
Regards,
Adriaan van Os
Testresults on powerpc-apple-darwin
[G5:gcc/p/test] adriaan% make EXTRA_PFLAGS=--longjmp-all-nonlocal-labels ... Native configuration is powerpc-apple-darwin7 (G5.local)
=== gpc tests ===
Running target any Running testsuite ...
FAIL: adam3q.pas FAIL: adam3r.pas UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas UNSUPPORTED: asmtest.pas FAIL: avo4.pas FAIL: filehand.pas UNSUPPORTED: fjf165a.pas FAIL: fjf659o.pas FAIL: fjf684.pas FAIL: fjf751k.pas FAIL: fjf751l.pas FAIL: fjf800.pas FAIL: fjf980b.pas FAIL: fjf998r.pas UNSUPPORTED: gmptest.pas FAIL: longr2.pas FAIL: pack10.pas FAIL: pack12.pas FAIL: pack2.pas FAIL: pack4.pas FAIL: random.pas FAIL: sets9.pas FAIL: systemtest.pas
=== gpc Summary ===
# of tests 4537 # of expected passes 4512 # of unexpected failures 19 # of unsupported tests 6
gpc version 20050217, based on gcc-3.4.3
TEST adam3q.pas: ./test_run: line 345: 27780 Segmentation fault ./"$A_OUT" "$1" TEST adam3r.pas: ./test_run: line 345: 27801 Segmentation fault ./"$A_OUT" "$1" TEST avo4.pas: ./test_run: line 345: 28617 Segmentation fault ./"$A_OUT" "$1" TEST filehand.pas: ./filehand.pas: In main program: ./filehand.pas:11: error: statement used as an expression failed TEST fjf659o.pas: ./test_run: line 345: 13241 Segmentation fault ./"$A_OUT" "$1" TEST fjf684.pas: ./fjf684.pas: In main program: ./fjf684.pas:12: error: invalid operands to `=' failed TEST fjf751k.pas: ./fjf751k.pas: In main program: ./fjf751k.pas:8: error: argument to `WriteLn' is of wrong type failed TEST fjf751l.pas: ./fjf751l.pas: In main program: ./fjf751l.pas:8: error: argument to `WriteLn' is of wrong type failed TEST fjf800.pas: ./fjf800.pas:65: error: redeclaration of `Fjf800' ./fjf800.pas:1: error: previous declaration ./fjf800.pas:65: error: redeclaration of `Fjf800' ./fjf800.pas:1: error: previous declaration failed TEST fjf980b.pas: ./test_run: line 345: 29625 Segmentation fault ./"$A_OUT" "$1" TEST fjf998r.pas: failed: TEST longr2.pas: dummy.pas: In main program: dummy.pas:2: error: real constant out of range TEST pack10.pas: ./test_run: line 345: 13658 Segmentation fault ./"$A_OUT" "$1" TEST pack12.pas: ./test_run: line 345: 13698 Segmentation fault ./"$A_OUT" "$1" TEST pack2.pas: ./test_run: line 345: 13719 Segmentation fault ./"$A_OUT" "$1" TEST pack4.pas: ./test_run: line 345: 13759 Segmentation fault ./"$A_OUT" "$1" TEST random.pas: ./random.pas: In main program: ./random.pas:22: error: invalid operands to `*' ./random.pas:22: error: invalid operands to `*' failed TEST sets9.pas: failed TEST systemtest.pas: ./test_run: line 345: 19818 Segmentation fault ./"$A_OUT" "$1"
Typical backtrace for the segmentation faults:
Thread 0 Crashed: 0 a.out 0x00009250 _p_FileHandle + 0x4 (files.pas:1015) 1 a.out 0x00004750 _p_WriteErrorMessage + 0x10c (error.pas:750) 2 a.out 0x00004a30 _p__rts_Error_S24_Writestackdump + 0x2cc (error.pas:772) 3 a.out 0x00005428 _p_EndRuntimeError + 0x38 (error.pas:862) 4 a.out 0x00005534 _p__rts_Error_S32_Strerror + 0 (error.pas:875) 5 a.out 0x00003988 _p_IORangeCheckError + 0 (error.pas:585) 6 a.out 0x00002ce0 _p__M0_main_program + 0x260 (pack4.pas:39) 7 a.out 0x000037f8 main + 0x34 (<implicit code>:43) 8 a.out 0x000026b8 _start + 0x188 (crt.c:267) 9 dyld 0x8fe1a558 _dyld_start + 0x64
Regards,
Adriaan van Os
Frank Heckenbach wrote:
For strings, range checking is BP compatible (access up to the capacity allowed) in `--borland-pascal' and `--delphi' modes and EP compatible (access only up to the current length allowed) otherwise. So in default (EP) mode code such as
if MyString[1] = '-' ...
without a check
if (MyString <> '') and ...
may now fail with a range-checking error. This is useful, since the first test was always undefined if `MyString' was empty, but in my experience so far, this has been one of the most common causes of range-checking errors in my code.
Shouldn't this depend on the internal representation of the respective string rather than the dialect ? BP compatible range checking for strings makes sense for UCSD-Pascal strings when implemented in GPC. UCSD-Pascal strings are not only used by --borland-pascal but also by --ucsd-pascal and --mac-pascal. And UCSD-Pascal strings allow access to element 0.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
For strings, range checking is BP compatible (access up to the capacity allowed) in `--borland-pascal' and `--delphi' modes and EP compatible (access only up to the current length allowed) otherwise. So in default (EP) mode code such as
if MyString[1] = '-' ...
without a check
if (MyString <> '') and ...
may now fail with a range-checking error. This is useful, since the first test was always undefined if `MyString' was empty, but in my experience so far, this has been one of the most common causes of range-checking errors in my code.
Shouldn't this depend on the internal representation of the respective string rather than the dialect ? BP compatible range checking for strings makes sense for UCSD-Pascal strings when implemented in GPC. UCSD-Pascal strings are not only used by --borland-pascal but also by --ucsd-pascal and --mac-pascal.
I don't think so. Access beyond the length is just as valid (for special low-level tricks) or invalid (usually), regardless of the representation.
And UCSD-Pascal strings allow access to element 0.
That's another issue. In this case you're right, UCSD strings will allow the lower bound 0 instead of 1.
Frank
Adriaan van Os wrote:
Frank Heckenbach wrote:
For strings, range checking is BP compatible (access up to the capacity allowed) in `--borland-pascal' and `--delphi' modes and EP compatible (access only up to the current length allowed) otherwise. So in default (EP) mode code such as
if MyString[1] = '-' ...
without a check
if (MyString <> '') and ...
may now fail with a range-checking error. This is useful, since the first test was always undefined if `MyString' was empty, but in my experience so far, this has been one of the most common causes of range-checking errors in my code.
Shouldn't this depend on the internal representation of the respective string rather than the dialect ? BP compatible range checking for strings makes sense for UCSD-Pascal strings when implemented in GPC. UCSD-Pascal strings are not only used by --borland-pascal but also by --ucsd-pascal and --mac-pascal. And UCSD-Pascal strings allow access to element 0.
I don't think you can make a single range checking rule for UCSD Pascal style strings. There is some variation between different vendors' implementation in the range checking criteria enforced in accessing individual string elements of UCSD Pascal style strings.
For example, the documentation for THINK Pascal (a MacPascal dialect compiler) states range checking checks that the individual character element being accessed is within the range 1..n where n is the current length of the string whose individual character element is being accessed. The documentation also specifically notes (by example) that accessing "element" 0, e.g., MyString[0], is not allowed when the range checking option is on.
As to what string range checking criteria to use for GPC's --mac-pascal dialect mode, since the documentation for Metrowerks/CodeWarrior Pascal and MPW Pascal does not explicitly state what the string range checking criteria is for the respective compilers, I need to do some test program checking with the compiler implementations to see what the implementations actually enforce with the range checking option on before stating what the criteria should be. (As Frank has indicated, what is allowed and works with range checking off is not necessarily allowed with range checking on. Since range checking is off by default, one can easily form a mistaken impression that some string constructs which work without range checking also work with range checking on when they really don't.)
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
I don't think you can make a single range checking rule for UCSD Pascal style strings. There is some variation between different vendors' implementation in the range checking criteria enforced in accessing individual string elements of UCSD Pascal style strings.
For example, the documentation for THINK Pascal (a MacPascal dialect compiler) states range checking checks that the individual character element being accessed is within the range 1..n where n is the current length of the string whose individual character element is being accessed. The documentation also specifically notes (by example) that accessing "element" 0, e.g., MyString[0], is not allowed when the range checking option is on.
BTW, does it have some other way to modify the length then? (BP doesn't, so writing to `MyString[0]' is the only way there.)
I don't think we need to be so strict, i.e. we can always allow access to element 0 for short strings then. For the upper bound, `--mac-pascal' currently behaves like EP (i.e., length, not capacity), so I suppose that's ok.
Frank
On Thu, Feb 17, 2005 at 05:27:30AM +0100, Frank Heckenbach wrote: [...]
- Initialized types in record and object fields and in schemata work now. (inirec[24].pas, fjf1016*.pas)
The following schema definition does not compile.
[~/pas]% cat tstsch.pas program Test (output);
type colour = (red, yellow, green, blue); { from ISO 10206, 6.4.10 } colour_map (formal_discriminant: colour) = record case formal_discriminant of red: (red_field: integer value ord (red)); yellow: (yellow_field: integer value ord (yellow)); green: (green_field: integer value ord (green)); blue: (blue_field: integer value ord (blue)); end; cmap_blue = colour_map (blue);
const cb = cmap_blue [case blue of [blue_field: 42]];
var cg: colour_map (green);
begin if (cb.blue_field = 42) and (cg.green_field = 2) then writeln ('OK') else writeln ('failed') end. [~/pas]% gpc34 -v Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: ../gcc-3.4.3/configure --enable-languages=pascal --program-suffix=34 Thread model: posix gpc version 20050217, based on gcc-3.4.3 [~/pas]% gpc34 tstsch.pas tstsch.pas:13: error: undeclared identifier `red_field' (first use in this routine) tstsch.pas:13: error: (Each undeclared identifier is reported only once tstsch.pas:13: error: for each routine it appears in.) tstsch.pas:13: error: undeclared identifier `yellow_field' (first use in this routine) tstsch.pas:13: error: undeclared identifier `green_field' (first use in this routine) tstsch.pas:13: error: undeclared identifier `blue_field' (first use in this routine)
And another bug:
[~/pas]% cat test.p program foo;
type t = array [0..32765] of integer;
var m: ^t;
begin new (m) end. [~/pas]% gpc34 test.p [~/pas]% ./a.out ./a.out: value out of range (error #300 at 804ef2a)
Emil
Emil Jerabek wrote:
On Thu, Feb 17, 2005 at 05:27:30AM +0100, Frank Heckenbach wrote: [...]
- Initialized types in record and object fields and in schemata work now. (inirec[24].pas, fjf1016*.pas)
The following schema definition does not compile.
[~/pas]% cat tstsch.pas program Test (output);
type colour = (red, yellow, green, blue); { from ISO 10206, 6.4.10 } colour_map (formal_discriminant: colour) = record case formal_discriminant of red: (red_field: integer value ord (red)); yellow: (yellow_field: integer value ord (yellow)); green: (green_field: integer value ord (green)); blue: (blue_field: integer value ord (blue)); end; cmap_blue = colour_map (blue);
const cb = cmap_blue [case blue of [blue_field: 42]];
var cg: colour_map (green);
begin if (cb.blue_field = 42) and (cg.green_field = 2) then writeln ('OK') else writeln ('failed') end. [~/pas]% gpc34 -v Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: ../gcc-3.4.3/configure --enable-languages=pascal --program-suffix=34 Thread model: posix gpc version 20050217, based on gcc-3.4.3 [~/pas]% gpc34 tstsch.pas tstsch.pas:13: error: undeclared identifier `red_field' (first use in this routine) tstsch.pas:13: error: (Each undeclared identifier is reported only once tstsch.pas:13: error: for each routine it appears in.) tstsch.pas:13: error: undeclared identifier `yellow_field' (first use in this routine) tstsch.pas:13: error: undeclared identifier `green_field' (first use in this routine) tstsch.pas:13: error: undeclared identifier `blue_field' (first use in this routine)
This program triggers three bugs in GPC. The attached patch fixes two of them alraedy (simplified tests attached), I'll work on the third one.
Frank
Frank Heckenbach wrote:
This program triggers three bugs in GPC. The attached patch fixes two of them alraedy (simplified tests attached), I'll work on the third one.
The patch causes regressions for fjf1021d.pas and fjf1021j.pas
TEST fjf1021d.pas: ./fjf1021d.pas:7: error: expressions with side-effects are not allowed in schema types failed
TEST fjf1021h.pas: ./fjf1021h.pas:6: error: expressions with side-effects are not allowed in schema types failed
TEST fjf1021i.pas: ./fjf1021i.pas:8: error: expressions with side-effects are not allowed in schema types failed
TEST fjf1021j.pas: ./fjf1021j.pas:6: error: expressions with side-effects are not allowed in schema types failed
Regards,
Adriaan van Os
Emil Jerabek wrote:
The following schema definition does not compile.
[~/pas]% cat tstsch.pas program Test (output);
type colour = (red, yellow, green, blue); { from ISO 10206, 6.4.10 } colour_map (formal_discriminant: colour) = record case formal_discriminant of red: (red_field: integer value ord (red)); yellow: (yellow_field: integer value ord (yellow)); green: (green_field: integer value ord (green)); blue: (blue_field: integer value ord (blue)); end; cmap_blue = colour_map (blue);
const cb = cmap_blue [case blue of [blue_field: 42]];
var cg: colour_map (green);
begin if (cb.blue_field = 42) and (cg.green_field = 2) then writeln ('OK') else writeln ('failed') end.
I've fixed the problem now (emil28a.pas). I'm not sending a patch now, since I'm not 100% sure which changes were relevant, and I'm still investigating some related issues. But I plan to make a new alpha soon, when the other current problems are resolved.
Frank
Frank Heckenbach wrote:
Emil Jerabek wrote:
The following schema definition does not compile.
[~/pas]% cat tstsch.pas program Test (output);
type colour = (red, yellow, green, blue); { from ISO 10206, 6.4.10 } colour_map (formal_discriminant: colour) = record case formal_discriminant of red: (red_field: integer value ord (red)); yellow: (yellow_field: integer value ord (yellow)); green: (green_field: integer value ord (green)); blue: (blue_field: integer value ord (blue)); end; cmap_blue = colour_map (blue);
const cb = cmap_blue [case blue of [blue_field: 42]];
var cg: colour_map (green);
begin if (cb.blue_field = 42) and (cg.green_field = 2) then writeln ('OK') else writeln ('failed') end.
I've fixed the problem now (emil28a.pas). I'm not sending a patch now, since I'm not 100% sure which changes were relevant, and I'm still investigating some related issues. But I plan to make a new alpha soon, when the other current problems are resolved.
Frank
Might this be the gpc.alpha to auto-generate c.headers for (ie; with module dot qualifiers) ??
I would like to give it a try using TCL scripts.
Rick Engebretson wrote:
I've fixed the problem now (emil28a.pas). I'm not sending a patch now, since I'm not 100% sure which changes were relevant, and I'm still investigating some related issues. But I plan to make a new alpha soon, when the other current problems are resolved.
Frank
Might this be the gpc.alpha to auto-generate c.headers for (ie; with module dot qualifiers) ??
If you mean if it supports qualified identifiers, the previous alpha already did.
Frank
Frank Heckenbach wrote:
Rick Engebretson wrote:
I've fixed the problem now (emil28a.pas). I'm not sending a patch now, since I'm not 100% sure which changes were relevant, and I'm still investigating some related issues. But I plan to make a new alpha soon, when the other current problems are resolved.
Frank
Might this be the gpc.alpha to auto-generate c.headers for (ie; with module dot qualifiers) ??
If you mean if it supports qualified identifiers, the previous alpha already did.
Frank
Excellent! Thanks.
Please be a little patient with my output. And I hope TCL suits all.
Thanks, Rick.
Rick Engebretson wrote:
Frank Heckenbach wrote:
Rick Engebretson wrote:
I've fixed the problem now (emil28a.pas). I'm not sending a patch now, since I'm not 100% sure which changes were relevant, and I'm still investigating some related issues. But I plan to make a new alpha soon, when the other current problems are resolved.
Frank
Might this be the gpc.alpha to auto-generate c.headers for (ie; with module dot qualifiers) ??
If you mean if it supports qualified identifiers, the previous alpha already did.
Frank
Excellent! Thanks.
Please be a little patient with my output. And I hope TCL suits all.
Thanks, Rick.
Oh, a little follow-up. Please, somebody, install iwidgets. The tabbed notebook and text tools are second to none. You'll see for yourself.
Rick.
On 17 Feb 2005 at 5:27, Frank Heckenbach wrote:
I have uploaded a new alpha version of GPC to http://www.gnu-pascal.de/alpha/.
[...]
Unfortunately, this snapshot has serious problems under Windows (Mingw). xgpc.exe crashes with a GPF every time it is called. I have tried building it on different PCs, and I have tried different gcc backend sources - same result :-(
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku wrote:
Unfortunately, this snapshot has serious problems under Windows (Mingw). xgpc.exe crashes with a GPF every time it is called. I have tried building it on different PCs, and I have tried different gcc backend sources - same result :-(
FYI, I have just built 20050217-based Mingw32 compiler. I did this using cross-compiler from Linux to Mingw32 to cross-compile native Mingw32 compiler. I have no Windows for real test but the resulting compiler runs under wine and I am able run (again under wine) resulting executables (well, at least "Hello World").
Note: I used stock 3.2.3 sources. Also, I used old 3.1.1 cross-compiler, mingw-runtime-19991107 and binutils 2.13.1.
Note2: The `gpc.c' file is substantially changed. It is now more similar to `gcc.c' from gcc-3.4.3 then to old `gpc.c'. So it may trigger bugs in the C compiler used to bootstrap. Also if you apply any special Mingw32 patches which affect `gpc.c' those patches need to be updated.
Note3: strncmp suggest that exact filenames/patch and options are crucial.
On 20 Feb 2005 at 5:38, Waldek Hebisch wrote:
Prof A Olowofoyeku wrote:
Unfortunately, this snapshot has serious problems under Windows (Mingw). xgpc.exe crashes with a GPF every time it is called. I have tried building it on different PCs, and I have tried different gcc backend sources - same result :-(
FYI, I have just built 20050217-based Mingw32 compiler. I did this using cross-compiler from Linux to Mingw32 to cross-compile native Mingw32 compiler. I have no Windows for real test but the resulting compiler runs under wine and I am able run (again under wine) resulting executables (well, at least "Hello World").
Note: I used stock 3.2.3 sources. Also, I used old 3.1.1 cross-compiler, mingw-runtime-19991107 and binutils 2.13.1.
Note2: The `gpc.c' file is substantially changed. It is now more similar to `gcc.c' from gcc-3.4.3 then to old `gpc.c'. So it may trigger bugs in the C compiler used to bootstrap. Also if you apply any special Mingw32 patches which affect `gpc.c' those patches need to be updated.
Note3: strncmp suggest that exact filenames/patch and options are crucial.
Well, I used Mingw special gcc-3.2.3 sources, *and* pristine gcc-3.3.5 sources. The result was exactly the same. Perhaps the actual installed gcc compiler (3.4.2) is buggy - but isn't that what "make bootstrap- lean" is supposed to avoid?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Frank Heckenbach wrote:
I have uploaded a new alpha version of GPC to http://www.gnu-pascal.de/alpha/.
After the patches you already sent: No errors found so far.
Frank Heckenbach a écrit:
I have uploaded a new alpha version of GPC to http://www.gnu-pascal.de/alpha/.
I have compiled this alpha for djgpp 2.03p2.
One problem: due to change in autoconf version from 2.13 to 2.59 in the rts SYS_SIGLIST_DECLARED is replaced by HAVE_DECL_SYS_SYGLIST this caused a failure with message /dev/c/djgpp/b/gnu/gcc-3.23/gcc/p/rts/rts.c:241: conflicting types for `sys_siglist' c:/djgpp/include/signal.h:86: previous declaration of `sys_siglist'
this is corrected with the following diff
--- rts.c.orig 2005-02-15 03:19:54.000000000 +0000 +++ rts.c 2005-02-21 17:56:02.000000000 +0000 @@ -237,7 +237,7 @@
#if !defined (HAVE_STRSIGNAL) && !defined (strsignal) #if defined (HAVE_SYS_SIGLIST) || defined (sys_siglist) -#if !defined (sys_siglist) && !defined (SYS_SIGLIST_DECLARED) +#if !defined (sys_siglist) && !defined (HAVE_DECL_SYS_SIGLIST) extern char **sys_siglist; #endif #elif defined (HAVE__SYS_SIGLIST) || defined (_sys_siglist)
After that, and a related correction needed because djgpp 2.03 has only autoconf-2.57 (and I need the djgpp version of autoconf to take into account some djgpp peculiarities), the compilation (bootstrap) goes smoothly. I only remarked a strange fact: at stage 1 gpc and rts are compiled instead of only C. But this causes no observable damage.
I included diffs posted here up to yesterday to expressions.c gpc.c module.c types.c and test\fjf1018[acu].pas
The result of running the test suite is
FAIL: avo7.pas FAIL: bprealtest.pas FAIL: fjf1021h.pas FAIL: fjf1021i.pas UNSUPPORTED: fjf165a.pas UNSUPPORTED: longr2.pas FAIL: y2k.pas
=== gpc Summary ===
# of tests 4537 # of expected passes 4530 # of unexpected failures 5 # of unsupported tests 2
explicitly:
TEST avo7.pas: gpc1.exe: warnings being treated as errors c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/avo7.pas:5: warning: identifiers should not start with an underscore failed TEST bprealtest.pas: c:/djgpp/b/gnu/build.gcc/gcc/p/test/a.out: error in exponentiation (Output of function out of range (ERANGE)) (error #700 at 2715) TEST fjf1021h.pas: c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/fjf1021h.pas:6: expressions with side-effects are not allowed in schema types failed TEST fjf1021i.pas: c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/fjf1021i.pas:8: expressions with side-effects are not allowed in schema types failed TEST fjf165a.pas: SKIPPED: German locale not installed TEST longr2.pas: SKIPPED: no LongReal math routines available TEST y2k.pas: failed 1999 1999
Not bad ... Some of these failures have been reported here by others. I will have a closer look before to upload.
Maurice
Maurice Lombardi wrote:
I have compiled this alpha for djgpp 2.03p2.
One problem: due to change in autoconf version from 2.13 to 2.59 in the rts SYS_SIGLIST_DECLARED is replaced by HAVE_DECL_SYS_SYGLIST this caused a failure with message /dev/c/djgpp/b/gnu/gcc-3.23/gcc/p/rts/rts.c:241: conflicting types for `sys_siglist' c:/djgpp/include/signal.h:86: previous declaration of `sys_siglist'
this is corrected with the following diff
--- rts.c.orig 2005-02-15 03:19:54.000000000 +0000 +++ rts.c 2005-02-21 17:56:02.000000000 +0000 @@ -237,7 +237,7 @@
#if !defined (HAVE_STRSIGNAL) && !defined (strsignal) #if defined (HAVE_SYS_SIGLIST) || defined (sys_siglist) -#if !defined (sys_siglist) && !defined (SYS_SIGLIST_DECLARED) +#if !defined (sys_siglist) && !defined (HAVE_DECL_SYS_SIGLIST) extern char **sys_siglist; #endif #elif defined (HAVE__SYS_SIGLIST) || defined (_sys_siglist)
I'm putting in both conditions, so it should work with both autoconf versions ...
#if !defined (sys_siglist) && !defined (SYS_SIGLIST_DECLARED) && !defined (HAVE_DECL_SYS_SIGLIST)
TEST avo7.pas: gpc1.exe: warnings being treated as errors c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/avo7.pas:5: warning: identifiers should not start with an underscore failed
This is fixed by a backend diff I hadn't included for 3.2.x -- I'll do this in the next release, but you'll have to start with fresh GCC sources (not yet patched by GPC) then to profit from it.
Frank
Frank Heckenbach a écrit:
I have uploaded a new alpha version of GPC to http://www.gnu-pascal.de/alpha/.
I have found a new bug. with DJGPP/ gcc-3.2.3 compiling a simple hello.pas program with options gpc hello.pas -o hello.exe -march=pentium4 -v
Reading specs from c:/djgpp/lib/gcc-lib/djgpp/3.23/specs Configured with: /djgpp/b/gnu/gcc-3.23/configure i586-pc-msdosdjgpp --prefix=/dev/env/DJDIR --disable-nls --enable-languages=pascal --enable-checking Thread model: single gpc version 20050217, based on gcc-3.2.3 c:/djgpp/lib/gcc-lib/djgpp/3.23/gpcpp.exe -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=3 -D__GXX_ABI_VERSION=102 -D__MSDOS__ -D__GO32__ -D__DJGPP__=2 -D__unix__ -D__MSDOS__ -D__GO32__ -D__DJGPP__=2 -D__unix__ -Asystem=msdos -Asystem=unix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__pentium4 -D__pentium4__ -D__tune_pentium4__-D__SSE__ -D__MMX__ -D__SSE2__ -DMSDOS -DGO32 -DDJGPP=2 -Dunix -remap -imacros c:/djgpp/lib/gcc-lib/djgpp/3.23/djgpp.ver hello.pas -famtmpfile=c:/djgpp/tmp/ccsYIPTf.gpa -fautobuild c:/djgpp/tmp/ccKMhvDl.i GNU Pascal Compiler PreProcessor version 20050217, based on gcc-3.2.3 (80386, BSD syntax) hello.pas:0: malformed option `-D __tune_pentium4__-D__SSE__'
Missing a space. Nothing similar with -march=pentiumpro or with the previous gpc-20040218 I have checked that the specs file is not overwritten.
Maurice
On 25 Feb 2005 at 17:15, Maurice Lombardi wrote:
Frank Heckenbach a écrit:
I have uploaded a new alpha version of GPC to http://www.gnu-pascal.de/alpha/.
I have found a new bug. with DJGPP/ gcc-3.2.3 compiling a simple hello.pas program with options gpc hello.pas -o hello.exe -march=pentium4 -v
Reading specs from c:/djgpp/lib/gcc-lib/djgpp/3.23/specs Configured with: /djgpp/b/gnu/gcc-3.23/configure i586-pc-msdosdjgpp --prefix=/dev/env/DJDIR --disable-nls --enable-languages=pascal --enable-checking Thread model: single gpc version 20050217, based on gcc-3.2.3 c:/djgpp/lib/gcc-lib/djgpp/3.23/gpcpp.exe -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=3 -D__GXX_ABI_VERSION=102 -D__MSDOS__ -D__GO32__ -D__DJGPP__=2 -D__unix__ -D__MSDOS__ -D__GO32__ -D__DJGPP__=2 -D__unix__ -Asystem=msdos -Asystem=unix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__pentium4 -D__pentium4__ -D__tune_pentium4__-D__SSE__ -D__MMX__ -D__SSE2__ -DMSDOS -DGO32 -DDJGPP=2 -Dunix -remap -imacros c:/djgpp/lib/gcc-lib/djgpp/3.23/djgpp.ver hello.pas -famtmpfile=c:/djgpp/tmp/ccsYIPTf.gpa -fautobuild c:/djgpp/tmp/ccKMhvDl.i GNU Pascal Compiler PreProcessor version 20050217, based on gcc-3.2.3 (80386, BSD syntax) hello.pas:0: malformed option `-D __tune_pentium4__-D__SSE__'
Missing a space. Nothing similar with -march=pentiumpro or with the previous gpc-20040218 I have checked that the specs file is not overwritten.
Confirmed also under Mingw: Reading specs from d:/mingw/bin/../lib/gcc-lib/mingw32/3.2.3/specs Configured with: ../configure --with-gcc --with-gnu-ld --with-gnu-as -- host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads -- disable-nls --enable-languages=pascal --disable-win32-registry -- disable-shared --enable-sjlj-exceptions --without-x --enable- interpreter --enable-hash-synchronization Thread model: win32 gpc version 20050217, based on gcc-3.2.3 (mingw special 20030504-1) d:/mingw/bin/../lib/gcc-lib/mingw32/3.2.3/gpcpp.exe - D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 - D__WORDS_LITTLE_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -v -iprefix d:\mingw\bin../lib/gcc-lib/mingw32/3.2.3/ -D__GNUC__=3 - D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=3 -D__GXX_ABI_VERSION=102 - D_WIN32 -D__WIN32 -D__WIN32__ -DWIN32 -D__MINGW32__ -D__MSVCRT__ - DWINNT -D_X86_=1 -D_WIN32 -D__WIN32 -D__WIN32__ -D__WIN32__ - D__MINGW32__ -D__MSVCRT__ -D__WINNT__ -D_X86_=1 -D__WIN32 -D__WINNT - Asystem=winnt -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 - Amachine=i386 -Di386 -D__i386 -D__i386__ -D__pentium4 -D__pentium4__ - D__tune_pentium4__-D__SSE__ -D__MMX__ -D__SSE2__ - D__stdcall=__attribute__((__stdcall__)) - D__cdecl=__attribute__((__cdecl__)) - D__fastcall=__attribute__((__fastcall__)) - D_stdcall=__attribute__((__stdcall__)) - D_cdecl=__attribute__((__cdecl__)) - D_fastcall=__attribute__((__fastcall__)) - D__declspec(x)=__attribute__((x)) hello.pas - famtmpfile=e:/temp/ccqsaaaa.gpa e:/temp/ccGKaaaa.i GNU Pascal Compiler PreProcessor version 20050217, based on gcc-3.2.3 (mingw special 20030504-1) (80386, BSD syntax) hello.pas:0: malformed option `-D __tune_pentium4__-D__SSE__'
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Maurice Lombardi wrote:
I have found a new bug. with DJGPP/ gcc-3.2.3 compiling a simple hello.pas program with options gpc hello.pas -o hello.exe -march=pentium4 -v
...
-D__pentium4 -D__pentium4__ -D__tune_pentium4__-D__SSE__ -D__MMX__ -D__SSE2__ -DMSDOS -DGO32 -DDJGPP=2 -Dunix -remap -imacros c:/djgpp/lib/gcc-lib/djgpp/3.23/djgpp.ver hello.pas -famtmpfile=c:/djgpp/tmp/ccsYIPTf.gpa -fautobuild c:/djgpp/tmp/ccKMhvDl.i GNU Pascal Compiler PreProcessor version 20050217, based on gcc-3.2.3 (80386, BSD syntax) hello.pas:0: malformed option `-D __tune_pentium4__-D__SSE__'
Missing a space. Nothing similar with -march=pentiumpro or with the previous gpc-20040218 I have checked that the specs file is not overwritten.
Spec file handling has changed in gcc-3.4. `gpc.c' is now more like `gcc.c' in 3.4 then in earlier versions. The following should correct the problem:
--- gpc.c.bb 2005-02-25 22:59:07.946190544 +0100 +++ gpc.c 2005-02-25 22:59:38.179594368 +0100 @@ -6587,8 +6587,10 @@ }
end_body = p; +#ifdef GCC_3_4 while (end_body[-1] == ' ' || end_body[-1] == '\t') end_body--; +#endif
if (have_subst && !starred) abort ();
Waldek Hebisch a écrit:
Maurice Lombardi wrote:
I have found a new bug. with DJGPP/ gcc-3.2.3 compiling a simple hello.pas program with options gpc hello.pas -o hello.exe -march=pentium4 -v
...
-D__pentium4 -D__pentium4__ -D__tune_pentium4__-D__SSE__ -D__MMX__ -D__SSE2__ -DMSDOS -DGO32 -DDJGPP=2 -Dunix -remap -imacros c:/djgpp/lib/gcc-lib/djgpp/3.23/djgpp.ver hello.pas -famtmpfile=c:/djgpp/tmp/ccsYIPTf.gpa -fautobuild c:/djgpp/tmp/ccKMhvDl.i GNU Pascal Compiler PreProcessor version 20050217, based on gcc-3.2.3 (80386, BSD syntax) hello.pas:0: malformed option `-D __tune_pentium4__-D__SSE__'
Missing a space. Nothing similar with -march=pentiumpro or with the previous gpc-20040218 I have checked that the specs file is not overwritten.
Spec file handling has changed in gcc-3.4. `gpc.c' is now more like `gcc.c' in 3.4 then in earlier versions. The following should correct the problem:
--- gpc.c.bb 2005-02-25 22:59:07.946190544 +0100 +++ gpc.c 2005-02-25 22:59:38.179594368 +0100 @@ -6587,8 +6587,10 @@ }
end_body = p; +#ifdef GCC_3_4 while (end_body[-1] == ' ' || end_body[-1] == '\t') end_body--; +#endif
if (have_subst && !starred) abort ();
OK it works now. Thanks
Maurice