I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/.
IMPORTANT LICENSING NOTE:
Due to the recent disputes over the GNU Free Documentation License by some parties, we made a detailed investigation of the license status of GPC's documentation. Thereby it turned out that the change to the FDL last November might not have been done absolutely correctly, since neither permission of some earlier authors nor of the FSF as the copyright holder was obtained for that change. To avoid any possible problems resulting from that, we decided to rewind the complete documentation to the state of 2002-11-27, the last version licensed under the GPL, and redo all later changes with explicit permission of the respective authors under the GPL. As the result, the whole documentation is now licensed under the GPL (again), and the license status of GPC versions 20021128, 20030209, 20030323 and 20030507 remains dubious. (Note: This affects only the documentation. The compiler itself has not changed its license and is therefore safe. Neither are programs compiled by such a GPC version affected.) I am not a lawyer, so I can't give you any advice what to do if you have used such a version, but my personal suggestion (also for technical reasons) is to change to the current release as soon as possible.
Therefore, we have removed the problematic distributions from our server. Those who have made available binaries of one of the problematic versions are suggested to do the same (which, I suppose, they will do anyway, replacing them by the new release). For the same reason, we do not offer a patch against gpc-20030507, so you will have to download the whole GPC distribution to upgrade. (A patch against gpc-20021111 would be safe, but probably rather large and not worth the effort, since many users might not have gpc-20021111 handy anymore.)
To avoid similar problems, we do not plan another attempt to change the license in the nearer future. It may be required for GCC integration someday, but not until the disputes over the FDL are finally settled. If you have any suggestions regarding these matters, please contact Peter Gerwinski or me by private mail.
BUILD NOTE:
This GPC version requires quite a recent version of Bison. (And building CVS Bison again requires bleeding edge versions of some other utilities.) Therefore, I have included the Bison generated files in the distribution (also in the "minimal" distribution), so you won't need Bison at all unless you remove them or change parse.y.
New features:
* `CompilerAssert' (fjf904*.pas)
* options `--[no]-assert' renamed to `--[no]-assertions' (necessary to avoid a conflict with GCC) (@)
* new options `--[no-]range-checking', also as short compiler directives `{$R+}'/`{$R-}' (default is on) (C, E, B, @)
* new options `--[no-]methods-always-virtual' (fjf903*.pas) (M)
* new options `--[no-]pointer-arithmetic', `--[no-]cstrings-as-strings', `-W[no-]absolute' (all of which `--[no-]extended-syntax' implies)
* `Integer2StringBase', `Integer2StringBaseExt'
* new constants `NumericBaseDigits', `NumericBaseDigitsUpper'
* allow assigning, passing by value and returning objects, with assignments of an object of derived type to one of a base type (chief35[ab].pas, fjf451*.pas, fjf696[ef].pas, fjf884*.pas), BP compatible except for a bug in the BP feature itself (see the comment in `p/test/fjf451h.pas') (B)
* new options `-W[no-]object-assignment'
* warn (except in `--borland-pascal') if a virtual method overrides a non-virtual one (chief52*.pas)
* warn when an non-abstract object type has virtual methods, but no constructor (chief51*.pas)
* `--maximum-field-alignment' does not apply to `packed' records
* `ArcSin', `ArcCos'
Note: Range checking options are recognized, but range checking in general is *not* yet implemented. Only some special cases are checked, such as sets and dynamic subranges (subranges in local declarations and array slice access).
Fixed bugs:
* open internal files with `O_EXCL' on `Rewrite' (as a protection against symlink attacks)
* `pow' and `**' are EP conformant now (in particular `x pow y = (1 div x) pow (Ây)' if `y' is negative and `x <> 0') (fjf908.pas)
* `--enable-keyword'/`--disable-keyword' on the command-line makes GPC crash (david5.pas)
* GPC accepts, but ignores, options with invalid suffixes (e.g. `--delphi-pascal')
* wrong type-error when applying `Inc' to a type-casted pointer (peter3.pas)
* with range checking enabled, check dynamic subrange/array size (fjf222*.pas, fjf813*.pas, fjf900*.pas)
* GPC allows modification of conformant array bounds, result of `High'/`Low' etc. (fjf897*.pas)
* don't allow linker names starting with a digit (fjf894.pas)
* `SubStr' with constant arguments doesn't work in constants (gale1.pas)
* handle `BitSizeOf' correctly for packed array fields, don't allow `SizeOf' on them (fjf891*.pas)
* System: `BPReal' must be a packed record 3EE8A26D.C919BE7D@flexim.de
* schema types with initializers (drf1.pas, fjf886*.pas)
* `Return' doesn't work for sets (fjf885.pas)
* bug with arrays as fields of `packed' records (waldek6.pas)
* don't allow duplicate imports in a module interface and implementation (nick1b.pas)
* compensate for parser read-ahead in the lexer, so compiler directives don't become effective too early and error messages refer more closely to the correct source position (still not quite correct due to issues with Bison)
* bug when dividing two integers with `/' (fjf481.pas)
* don't allow `absolute' in type definitions
* subranges with variable limits (couper[23].pas)
Frank
Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/.
Thanks for the new alpha upload.
I tried gpc-20030850 with gcc-3.3.1. and got an internal compiler error while building the runtime library:
../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/Users/adriaan/gnu/gpc-20030830/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /Users/adriaan/gnu/gpc-20030830/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.3.1'" /Users/adriaan/gnu/gpc-20030830/gcc/p/rts/string.pas /Users/adriaan/gnu/gpc-20030830/gcc/p/rts/string.pas: In function `TrimBothStr': /Users/adriaan/gnu/gpc-20030830/gcc/p/rts/string.pas:756: internal compiler error: in tree_node_structure, at tree.c:1524 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [string.o] Error 1 make[1]: *** [pascal.rts] Error 2 make: *** [all-gcc] Error 2
The backtrace reads like this:
**********
Date/Time: 2003-08-22 09:21:56 +0200 OS Version: 10.2.4 (Build 6I32) Host: G4.local.
Command: gpc1 PID: 11906
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x02000008
Thread 0 Crashed: #0 0x0023e9ac in ht_expand (hashtable.c:198) #1 0x0023e8ac in ht_lookup (hashtable.c:173) #2 0x000c3ba8 in get_identifier (stringpool.c:109) #3 0x000048f0 in set_identifier_spelling (declarations.c:1058) #4 0x00016590 in yylex (gpc-lex.c:1361) #5 0x0002fabc in main_yyparse (parse.c:573) #6 0x000980a0 in compile_file (toplev.c:2134) #7 0x0009d308 in do_compile (toplev.c:5384) #8 0x0009d3d4 in toplev_main (toplev.c:5414) #9 0x00002740 in _start (crt.c:267) #10 0x000025c0 in start
PPC Thread State: srr0: 0x0023e9ac srr1: 0x0000d930 vrsave: 0x00000000 xer: 0x00000000 lr: 0x0023e984 ctr: 0x00000000 mq: 0x00000000 r0: 0x00000000 r1: 0xbfffe730 r2: 0x2800824b r3: 0x00ff7000 r4: 0x012ab040 r5: 0x01017000 r6: 0x02000000 r7: 0x01015c74 r8: 0x0000ffff r9: 0x0000c819 r10: 0x0000eeff r11: 0x00036468 r12: 0x00000000 r13: 0x002f5dbc r14: 0x000000c8 r15: 0xbfffeca0 r16: 0x00000075 r17: 0x00000000 r18: 0x002d96ac r19: 0x00000000 r20: 0xbfffeb10 r21: 0x00000001 r22: 0x0086bd00 r23: 0x0000000b r24: 0x00007b2f r25: 0xd96f164e r26: 0x00843890 r27: 0x00007fff r28: 0x00843890 r29: 0x00010000 r30: 0x012ab000 r31: 0x000c3b7c
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/.
Thanks for the new alpha upload.
I tried gpc-20030850 with gcc-3.3.1. and got an internal compiler error while building the runtime library:
Seems like something has to be added there (or elsewhere) to support that apparently new mechanism. I hope Waldek will take care of it.
Otherwise, please note that gcc-3.3.x is still considered experimental.
Frank
Frank Heckenbach writes:
Adriaan van Os wrote:
Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/.
Thanks for the new alpha upload.
I tried gpc-20030850 with gcc-3.3.1. and got an internal compiler error while building the runtime library:
Seems like something has to be added there (or elsewhere) to support that apparently new mechanism. I hope Waldek will take care of it.
Otherwise, please note that gcc-3.3.x is still considered experimental.
I dont's this failure with gcc-3.3 CVS 20030831. The failing platforms for me are alpha-linux and ia64-linux (both 64bit).
See http://buildd.debian.org/build.php?arch=&pkg=gcc-3.3 for more details. hppa-linux and i486-linux built fine.
Matthias
Matthias Klose wrote:
Frank Heckenbach writes:
Adriaan van Os wrote:
Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/.
Thanks for the new alpha upload.
I tried gpc-20030850 with gcc-3.3.1. and got an internal compiler error while building the runtime library:
Seems like something has to be added there (or elsewhere) to support that apparently new mechanism. I hope Waldek will take care of it.
Otherwise, please note that gcc-3.3.x is still considered experimental.
I dont's this failure with gcc-3.3 CVS 20030831. The failing platforms for me are alpha-linux and ia64-linux (both 64bit).
See http://buildd.debian.org/build.php?arch=&pkg=gcc-3.3 for more details. hppa-linux and i486-linux built fine.
Yes, but isn't that gcc itself ? On Mac OS X, gcc-3.3.1 builds fine without gpc-20030831 (C only) and it also builds fine with gpc-20030507 (both C and Pascal).
Regards,
Adriaan van Os
On Sun, Aug 31, 2003 at 06:49:43AM +0200, Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/.
[...]
- `pow' and `**' are EP conformant now (in particular `x pow y = (1 div x) pow (y)' if `y' is negative and `x <> 0') (fjf908.pas)
According to the standard, `x pow y' and `x ** y' should be an error if x = 0 and y <= 0 (in fact, there is no sensible value to return in these cases). This (mostly) worked in the old implementation, but it doesn't any more.
Emil
Le Mardi 2 Septembre 2003 11:27, Emil Jerabek a écrit :
On Sun, Aug 31, 2003 at 06:49:43AM +0200, Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/.
[...]
- `pow' and `**' are EP conformant now (in particular `x pow y = (1 div x) pow (y)' if `y' is negative and `x <> 0') (fjf908.pas)
According to the standard, `x pow y' and `x ** y' should be an error if x = 0 and y <= 0 (in fact, there is no sensible value to return in these cases). This (mostly) worked in the old implementation, but it doesn't any more.
when possible, returning NAN (Not A Number in IEEE arithmetic) instead of an error is a sensible option
Jean-Pierre Vial wrote:
Le Mardi 2 Septembre 2003 11:27, Emil Jerabek a écrit :
On Sun, Aug 31, 2003 at 06:49:43AM +0200, Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/.
[...]
- `pow' and `**' are EP conformant now (in particular `x pow y = (1 div x) pow (Ây)' if `y' is negative and `x <> 0') (fjf908.pas)
According to the standard, `x pow y' and `x ** y' should be an error if x = 0 and y <= 0 (in fact, there is no sensible value to return in these cases). This (mostly) worked in the old implementation, but it doesn't any more.
when possible, returning NAN (Not A Number in IEEE arithmetic) instead of an error is a sensible option
ISO Pascal wants an error (though, in principle, I think we could use NaN and document the error as "not detected" -- we might do this sometime, perhaps optionally). For now, I'm making it runtime errors. (emil27*.pas)
Frank
Frank Heckenbach wrote:
ISO Pascal wants an error (though, in principle, I think we could use NaN and document the error as "not detected" -- we might do this sometime, perhaps optionally). For now, I'm making it runtime errors. (emil27*.pas)
Special cases for the pow function in IEEE 754 (see e.g. Apple Numerics Manual, second edition, page 64, or the PowerPC Numerics manual available from <http://developer.apple.com/documentation/mac/PPCNumerics/PPCNumerics- 2.html>).
Operation Result Exceptions raised
pow( x, y) for x < 0 NaN if y is not integer Invalid x^y if y is integer None
pow( +0, y) +/-0 if y is odd integer > 0 None +0 if y > 0 but not odd integer None +/- INF if y is odd integer < 0 Divide-by-zero +INF if y < 0 but not odd integer Divide-by-zero
pow( x, +0) +1 None
pow( -0, y) +/-0 if y is odd integer > 0 None +0 if y > 0 but not odd integer None +/-INF if y is odd integer < 0 Divide-by-zero +INF if y < 0 but not odd integer Divide-by-zero
pow( x, -0) +1 None
pow( NaN, y) NaN if y <> 0 None* +1 if y = 0 None*
pow( x, NaN) NaN None*
pow( +INF, y) +INF if y > 0 None +0 if y < 0 None +1 if y = 0 None
pow( x, +INF) +INF if |x| > 1 None +0 if |x| < 1 None NaN if |x| = 1 Invalid
pow( -INF, y) -INF if y is odd integer > 0 None +INF if y > 0 but not odd integer None -0 if y is odd integer < 0 None +0 if y < 0 but not odd integer None +1 if y = 0 None pow( x, -INF) +0 if |x| > 1 None +INF if |x| < 1 None NaN if |x| = 1 Invalid
* If the NaN is a signaling NaN, the invalid exception is raised.
In an IEEE environment, you have routines that give you precise control over what happens if exceptions are signaled (halt vectors and exception flags).
Regards,
Adriaan van Os
Emil Jerabek wrote:
On Sun, Aug 31, 2003 at 06:49:43AM +0200, Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/.
[...]
- `pow' and `**' are EP conformant now (in particular `x pow y = (1 div x) pow (Ây)' if `y' is negative and `x <> 0') (fjf908.pas)
According to the standard, `x pow y' and `x ** y' should be an error if x = 0 and y <= 0 (in fact, there is no sensible value to return in these cases). This (mostly) worked in the old implementation, but it doesn't any more.
Unless I'm missing something, the standard seems to contradict itself:
: 6.8.3.2 : : [...] : : A factor of the form x**y shall be an error if x is zero and y is less than : or equal to zero.
Like you say.
: A factor of the form x**y, where x is of integerÂtype or : realÂtype, shall be an error if x is negative; otherwise, the : value of x**y shall be zero if x is zero, else [...]
Like I implemented it.
(Note that there's no "otherwise" at the beginning of the 2nd paragraph.)
: The value of a factor of the form x**y, where x is of complexÂtype, shall : be zero if x is zero, [...]
Same here.
: A factor of the form x pow y shall be an error if x is zero and y is less : than or equal to zero. : : The value of a factor of the form x pow y, where x is of integerÂtype, : shall be zero if x is zero, [...]
Again.
Frank
Frank Heckenbach wrote:
Emil Jerabek wrote:
On Sun, Aug 31, 2003 at 06:49:43AM +0200, Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/.
[...]
- `pow' and `**' are EP conformant now (in particular `x pow y = (1 div x) pow (Ây)' if `y' is negative and `x <> 0') (fjf908.pas)
According to the standard, `x pow y' and `x ** y' should be an error if x = 0 and y <= 0 (in fact, there is no sensible value to return in these cases). This (mostly) worked in the old implementation, but it doesn't any more.
Unless I'm missing something, the standard seems to contradict itself:
: 6.8.3.2 : : [...] : : A factor of the form x**y shall be an error if x is zero and y is less than : or equal to zero.
Like you say.
: A factor of the form x**y, where x is of integerÂtype or : realÂtype, shall be an error if x is negative; otherwise, the : value of x**y shall be zero if x is zero, else [...]
Like I implemented it.
I think that the standard really means:
if (x = 0) and (y <= 0) then do_anything (* error *);
if is_integer_or_real(x) then if (x < 0 ) then do_anything (* error *) else if x = 0 then result := 0.0 else if y = 0 then result := 1.0 else result := exp(y*log(x));
if is_complex(x) then if x = 0 then result := 0.0 else if y = 0 then result := 1.0 else result := exp(y*log(x));
Why?
3.2 Error
A violation by a program of the requirements of this International that a processor is permitted to leave undetected.
So statements about errors are obligation on source program, and error in source program (IMHO) effectively voids requrement on implementation to deliver results. So `otherwise' is not needed. The first line about error is clearly intended to apply both to real and to complex case. Putting an `otherwise' between first line and the second statement would limit the scope of first line only to real case.
By the way, the standard is rather careful to specify correct mathematical results, and without first line the result would be incorrect.
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Emil Jerabek wrote:
On Sun, Aug 31, 2003 at 06:49:43AM +0200, Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/.
[...]
- `pow' and `**' are EP conformant now (in particular `x pow y = (1 div x) pow (Ây)' if `y' is negative and `x <> 0') (fjf908.pas)
According to the standard, `x pow y' and `x ** y' should be an error if x = 0 and y <= 0 (in fact, there is no sensible value to return in these cases). This (mostly) worked in the old implementation, but it doesn't any more.
Unless I'm missing something, the standard seems to contradict itself:
: 6.8.3.2 : : [...] : : A factor of the form x**y shall be an error if x is zero and y is less than : or equal to zero.
Like you say.
: A factor of the form x**y, where x is of integerÂtype or : realÂtype, shall be an error if x is negative; otherwise, the : value of x**y shall be zero if x is zero, else [...]
Like I implemented it.
I think that the standard really means:
if (x = 0) and (y <= 0) then do_anything (* error *);
if is_integer_or_real(x) then if (x < 0 ) then do_anything (* error *) else if x = 0 then result := 0.0 else if y = 0 then result := 1.0 else result := exp(y*log(x));
if is_complex(x) then if x = 0 then result := 0.0 else if y = 0 then result := 1.0 else result := exp(y*log(x));
Why?
3.2 Error
A violation by a program of the requirements of this International that a processor is permitted to leave undetected.
So statements about errors are obligation on source program,
I don't think so. 3.2, Note 1:
: 1 If it is possible to construct a program in which the violation or : nonÂviolation of this standard requires knowledge of the data read by the : program or the implementation definition of implementationÂdefined features, : then violation of that requirement is classified as either a : dynamicÂviolation or an error.
(And this case certainly belongs to this class, since it depends on the actual values of the operands.)
For obligations on the source code, the standard uses the term "shall", and does not classify them as errors or dynamicÂviolations. The difference between errors and dynamicÂviolations seems to be that an implementation may leave (certain) errors undetected, but not dynamicÂviolations (when they're reached at runtime).
and error in source program (IMHO) effectively voids requrement on implementation to deliver results. So `otherwise' is not needed. The first line about error is clearly intended to apply both to real and to complex case. Putting an `otherwise' between first line and the second statement would limit the scope of first line only to real case.
They'd have to change the formulation somewhat to make it apply to both cases, but that shouldn't be an excuse for ambiguousness.
By the way, the standard is rather careful to specify correct mathematical results, and without first line the result would be incorrect.
The only way I could make sense of it is that a (runtime) error takes precedence of value requirements (though I'm not sure if/where this is actually stated), so an implementation which detects this error wouldn't be concerned about the value requirement.
However, it would also be correct (according to 3.2) to leave this error undetected. Then, AFAICS, the value requirement would become effective, and the value would have to be 0. This is what GPC currently does, though I agree it's not really useful mathematically.
It would also mean that yielding NaN, as Jean-Pierre Vial suggested, would be incorrect in any case.
Frank
On 31 Aug 2003 at 6:49, Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/.
[...]
Compiling for Mingw, based on gcc-3.3.1, I get this error:
make[1]: Entering directory `/src/mingw/gcc-3.3.1-20030804-1/gcc/p/rts' make[1]: Nothing to be done for `generated-files'. make[1]: Leaving directory `/src/mingw/gcc-3.3.1-20030804-1/gcc/p/rts' make: *** No rule to make target `../../gcc/p/doc/es/gpc.texi', needed by `../../gcc/p/doc/info/gpc-es.info'. Stop.
Any ideas?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
On 31 Aug 2003 at 6:49, Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/.
[...]
Compiling for Mingw, based on gcc-3.3.1, I get this error:
make[1]: Entering directory `/src/mingw/gcc-3.3.1-20030804-1/gcc/p/rts' make[1]: Nothing to be done for `generated-files'. make[1]: Leaving directory `/src/mingw/gcc-3.3.1-20030804-1/gcc/p/rts' make: *** No rule to make target `../../gcc/p/doc/es/gpc.texi', needed by `../../gcc/p/doc/info/gpc-es.info'. Stop.
Probably because it doesn't support symlinks.
The thing is, Francisco Javier Fernandez had sent me Spanish translations, and I added support for them in the Makefile etc. Afterwards, I discovered that they contained syntactic errors and wouldn't build (and he hasn't sent me corrected ones so far). Since I didn't want to undo the Makefile changes (and redo them later which would mean triple work for me), I just symlinked the English texts.
So without symlinks, try copying all files from ../en (except gpcs.texi which exists in Spanish).
Frank
On 3 Sep 2003 at 9:46, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
On 31 Aug 2003 at 6:49, Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/.
[...]
Compiling for Mingw, based on gcc-3.3.1, I get this error:
make[1]: Entering directory `/src/mingw/gcc-3.3.1-20030804-1/gcc/p/rts' make[1]: Nothing to be done for `generated-files'. make[1]: Leaving directory `/src/mingw/gcc-3.3.1-20030804-1/gcc/p/rts' make: *** No rule to make target `../../gcc/p/doc/es/gpc.texi', needed by `../../gcc/p/doc/info/gpc-es.info'. Stop.
Probably because it doesn't support symlinks.
The thing is, Francisco Javier Fernandez had sent me Spanish translations, and I added support for them in the Makefile etc. Afterwards, I discovered that they contained syntactic errors and wouldn't build (and he hasn't sent me corrected ones so far). Since I didn't want to undo the Makefile changes (and redo them later which would mean triple work for me), I just symlinked the English texts.
So without symlinks, try copying all files from ../en (except gpcs.texi which exists in Spanish).
Thanks.
All is well now. I have built it successfully on Mingw (gcc-3.3.1) and Cygwin (gcc-3.2.3). I will run the testsuites and then upload binaries if everything is okay ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Frank Heckenbach a écrit:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/.
I have compiled it (and ran the test suite with no error) with gc-3.2.2 and gcc-3.2.3 with DJGPP and installed them in the usual "Contrib/Maurice" directory.
While trying with gcc 3.3.1 (after installing it also as "system" compiler) with ./djmake CFLAGS=-O2 PFLAGS=-gstabs (no bootstrap) it dies with the following message:
---------------------------------------------------------------------
../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -O2 -gstabs --unit-path=/dev/c/djgpp/b/gnu/gcc-3.31/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /dev/c/djgpp/b/gnu/gcc-3.31/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.31'" /dev/c/djgpp/b/gnu/gcc-3.31/gcc/p/rts/string.pas /dev/c/djgpp/b/gnu/gcc-3.31/gcc/p/rts/string.pas: In function `StrEQPad': /dev/c/djgpp/b/gnu/gcc-3.31/gcc/p/rts/string.pas:883: internal compiler error: in tree_node_structure, at tree.c:1524 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make.exe[2]: *** [string.o] Error 1 make.exe[2]: Leaving directory `c:/djgpp/b/gnu/build.gcc/gcc/p/rts' make.exe[1]: *** [pascal.rts] Error 2 make.exe[1]: Leaving directory `c:/djgpp/b/gnu/build.gcc/gcc' make.exe: *** [all-gcc] Error 2
---------------------------------------------------------------------
Hope this helps Maurice
gpc-20030830 have a memory management bug which is probably responsible for crashes reported by Adriaan van Os and Maurice Lombardi. Mainly builds with gcc-3.3.x are affected (I do not know if it is possible to trigger the bug with earlier gcc version). The patch below fixes the problem:
diff -ru gpc-20030830.orig/p/gpc.h gpc-20030830/p/gpc.h --- gpc-20030830.orig/p/gpc.h Wed Aug 13 06:30:35 2003 +++ gpc-20030830/p/gpc.h Sun Sep 7 03:28:26 2003 @@ -276,12 +276,13 @@ };
union lang_tree_node - GTY((desc ("((TREE_CODE (&%h.generic) == IDENTIFIER_NODE) || (TREE_CODE (&%h.generic) == INTERFACE_NAME_NODE)) ? TREE_CODE (&%h.generic) : 0"), + GTY((desc ("((TREE_CODE (&%h.generic) == IDENTIFIER_NODE) || (TREE_CODE (&%h.generic) == INTERFACE_NAME_NODE) || (TREE_CODE (&%h.generic) == IMPORT_NODE)) ? TREE_CODE (&%h.generic) : 0"), chain_next ("(union lang_tree_node *) TREE_CHAIN (&%h.generic)"))) { union tree_node GTY ((tag ("0"), desc ("tree_node_structure (&%h)"))) generic; struct lang_identifier GTY ((tag ("IDENTIFIER_NODE"))) identifier; struct tree_inn GTY ((tag ("INTERFACE_NAME_NODE"))) interface; + struct tree_import GTY ((tag ("IMPORT_NODE"))) import; };
#define AS_LANG_IDENTIFIER_NODE(ID) ((struct lang_identifier *) IDENTIFIER_NODE_CHECK (ID)) diff -ru gpc-20030830.orig/p/p-tree.def gpc-20030830/p/p-tree.def --- gpc-20030830.orig/p/p-tree.def Fri Jun 6 00:14:08 2003 +++ gpc-20030830/p/p-tree.def Sun Sep 7 03:40:08 2003 @@ -27,14 +27,14 @@ /* The field `gpi_int checksum' might be larger than a pointer, so reserve two pointer sizes for it. */ DEFTREECODE (INTERFACE_NAME_NODE, "interface_name_node", 'x', 3) -DEFTREECODE (IMPORT_NODE, "import_node", 'x', 3) +DEFTREECODE (IMPORT_NODE, "import_node", 'x', 4) DEFTREECODE (POWER_EXPR, "power_expr", '2', 2) DEFTREECODE (POW_EXPR, "pow_expr", '2', 2) DEFTREECODE (SYMDIFF_EXPR, "symdiff_expr", '2', 2) #else DEFTREECODE (OPERATOR_DECL, "operator_decl", "d", 0) DEFTREECODE (INTERFACE_NAME_NODE, "interface_name_node", "x", 3) -DEFTREECODE (IMPORT_NODE, "import_node", "x", 3) +DEFTREECODE (IMPORT_NODE, "import_node", "x", 4) DEFTREECODE (POWER_EXPR, "power_expr", "2", 2) DEFTREECODE (POW_EXPR, "pow_expr", "2", 2) DEFTREECODE (SYMDIFF_EXPR, "symdiff_expr", "2", 2)
Waldek Hebisch wrote:
gpc-20030830 have a memory management bug which is probably responsible for crashes reported by Adriaan van Os and Maurice Lombardi. Mainly builds with gcc-3.3.x are affected (I do not know if it is possible to trigger the bug with earlier gcc version). The patch below fixes the problem:
Thanks for looking into this.
I tried the patch with gpc-20030830 and gcc-3.3.1. The string.pas unit now compiles, but I get what also seems a memory management related error.
../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/Users/adriaan/gnu/gpc-331d3/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /Users/adriaan/gnu/gpc-331d3/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.3.1'" /Users/adriaan/gnu/gpc-331d3/gcc/p/rts/string.pas ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/Users/adriaan/gnu/gpc-331d3/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /Users/adriaan/gnu/gpc-331d3/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.3.1'" /Users/adriaan/gnu/gpc-331d3/gcc/p/rts/error.pas *** malloc[21421]: error for object 0xf400e0: Incorrect checksum for freed object - object was probably modified after being freed; break at szone_error /Users/adriaan/gnu/gpc-331d3/gcc/p/rts/error.pas: In procedure `DefaultSignalHandler': /Users/adriaan/gnu/gpc-331d3/gcc/p/rts/error.pas:1071: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [error.o] Error 1 make[1]: *** [pascal.rts] Error 2 make: *** [all-gcc] Error 2
The backtrace reads as follows:
**********
Date/Time: 2003-09-07 21:39:07 +0200 OS Version: 10.2.4 (Build 6I32) Host: G4.local.
Command: gpc1 PID: 21421
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x26000004
Thread 0 Crashed: #0 0x000d1d20 in alloc_page (ggc-page.c:683) #1 0x000d0c70 in ggc_alloc (ggc-page.c:1026) #2 0x0013df00 in gen_rtx_fmt_ee (genrtl.c:37) #3 0x001c8db0 in simplify_plus_minus (simplify-rtx.c:1896) #4 0x001c57fc in simplify_gen_binary (simplify-rtx.c:129) #5 0x001dcf50 in find_best_addr (cse.c:3093) #6 0x001df678 in fold_rtx (cse.c:3600) #7 0x001dec9c in fold_rtx (cse.c:3794) #8 0x001e0d2c in cse_insn (cse.c:5106) #9 0x001e5afc in cse_basic_block (cse.c:7347) #10 0x001e5704 in cse_main (cse.c:7220) #11 0x000a57d4 in rest_of_compilation (toplev.c:2817) #12 0x00019310 in finish_routine (declarations.c:2530) #13 0x0000a784 in yyuserAction (parse.c:4581) #14 0x00013c38 in yydoAction (parse.c:8238) #15 0x00013700 in yyglrReduce (parse.c:8290) #16 0x000127e0 in main_yyparse (parse.c:8959) #17 0x000a4d8c in compile_file (toplev.c:2134) #18 0x000a9ff4 in do_compile (toplev.c:5384) #19 0x000aa0c0 in toplev_main (toplev.c:5414) #20 0x00002520 in _start (crt.c:267) #21 0x000023a0 in start
PPC Thread State: srr0: 0x000d1d20 srr1: 0x0200f930 vrsave: 0x00000000 xer: 0x20000000 lr: 0x000d1cb8 ctr: 0x00000000 mq: 0x00000000 r0: 0x2a000000 r1: 0xbfffcb00 r2: 0x24004282 r3: 0x26000000 r4: 0x00000004 r5: 0x0146dfc0 r6: 0x00000000 r7: 0x0146dfc0 r8: 0x00000047 r9: 0x0114a54b r10: 0x00000010 r11: 0x44044242 r12: 0x84042228 r13: 0xbfffcc80 r14: 0x00000000 r15: 0x00000002 r16: 0x00000004 r17: 0x00000001 r18: 0x00000001 r19: 0x00311cb8 r20: 0x00000000 r21: 0x00000022 r22: 0xbfffcc80 r23: 0x00000100 r24: 0x0000003c r25: 0x00310c1c r26: 0x00000004 r27: 0x00000088 r28: 0x00001000 r29: 0x00d16250 r30: 0x00000000 r31: 0x000d1cb8
Regards,
Adriaan van Os
Waldek Hebisch a écrit:
gpc-20030830 have a memory management bug which is probably responsible for crashes reported by Adriaan van Os and Maurice Lombardi. Mainly builds with gcc-3.3.x are affected (I do not know if it is possible to trigger the bug with earlier gcc version). The patch below fixes the problem:
diff -ru gpc-20030830.orig/p/gpc.h gpc-20030830/p/gpc.h --- gpc-20030830.orig/p/gpc.h Wed Aug 13 06:30:35 2003 +++ gpc-20030830/p/gpc.h Sun Sep 7 03:28:26 2003 @@ -276,12 +276,13 @@ };
union lang_tree_node
- GTY((desc ("((TREE_CODE (&%h.generic) == IDENTIFIER_NODE) || (TREE_CODE (&%h.generic) == INTERFACE_NAME_NODE)) ? TREE_CODE (&%h.generic) : 0"),
- GTY((desc ("((TREE_CODE (&%h.generic) == IDENTIFIER_NODE) || (TREE_CODE (&%h.generic) == INTERFACE_NAME_NODE) || (TREE_CODE (&%h.generic) == IMPORT_NODE)) ? TREE_CODE (&%h.generic) : 0"), chain_next ("(union lang_tree_node *) TREE_CHAIN (&%h.generic)")))
{ union tree_node GTY ((tag ("0"), desc ("tree_node_structure (&%h)"))) generic; struct lang_identifier GTY ((tag ("IDENTIFIER_NODE"))) identifier; struct tree_inn GTY ((tag ("INTERFACE_NAME_NODE"))) interface;
- struct tree_import GTY ((tag ("IMPORT_NODE"))) import;
};
#define AS_LANG_IDENTIFIER_NODE(ID) ((struct lang_identifier *) IDENTIFIER_NODE_CHECK (ID)) diff -ru gpc-20030830.orig/p/p-tree.def gpc-20030830/p/p-tree.def --- gpc-20030830.orig/p/p-tree.def Fri Jun 6 00:14:08 2003 +++ gpc-20030830/p/p-tree.def Sun Sep 7 03:40:08 2003 @@ -27,14 +27,14 @@ /* The field `gpi_int checksum' might be larger than a pointer, so reserve two pointer sizes for it. */ DEFTREECODE (INTERFACE_NAME_NODE, "interface_name_node", 'x', 3) -DEFTREECODE (IMPORT_NODE, "import_node", 'x', 3) +DEFTREECODE (IMPORT_NODE, "import_node", 'x', 4) DEFTREECODE (POWER_EXPR, "power_expr", '2', 2) DEFTREECODE (POW_EXPR, "pow_expr", '2', 2) DEFTREECODE (SYMDIFF_EXPR, "symdiff_expr", '2', 2) #else DEFTREECODE (OPERATOR_DECL, "operator_decl", "d", 0) DEFTREECODE (INTERFACE_NAME_NODE, "interface_name_node", "x", 3) -DEFTREECODE (IMPORT_NODE, "import_node", "x", 3) +DEFTREECODE (IMPORT_NODE, "import_node", "x", 4) DEFTREECODE (POWER_EXPR, "power_expr", "2", 2) DEFTREECODE (POW_EXPR, "pow_expr", "2", 2) DEFTREECODE (SYMDIFF_EXPR, "symdiff_expr", "2", 2)
With this patch it compiles under DJGPP. Running the test suite results in the following test_summary
---------------------------------------------------------------------------------
TEST agettext2test.pas: c:/djgpp/lib/libintl.a(dcigettext.o)(.text+0x968): In function `__nl_find_msg': dcigettext.c:872: undefined reference to `_libiconv' c:/djgpp/lib/libintl.a(loadmsgcat.o)(.text+0x1b2): In function `__nl_init_domain_conv': loadmsgcat.c:301: undefined reference to `_libiconv_open' c:/djgpp/lib/libintl.a(loadmsgcat.o)(.text+0x1fb): In function `__nl_free_domain_conv': loadmsgcat.c:331: undefined reference to `_libiconv_close' collect2: ld returned 1 exit status failed TEST aturbo3test.pas: c:/djgpp/bin/ld.exe: cannot find -lncurses collect2: ld returned 1 exit status failed TEST crttest.pas: c:/djgpp/bin/ld.exe: cannot find -lncurses collect2: ld returned 1 exit status failed TEST dialec3.pas: c:/djgpp/bin/ld.exe: cannot find -lncurses collect2: ld returned 1 exit status failed TEST dialec5.pas: c:/djgpp/bin/ld.exe: cannot find -lncurses collect2: ld returned 1 exit status failed TEST dialec6.pas: c:/djgpp/bin/ld.exe: cannot find -lncurses collect2: ld returned 1 exit status failed TEST dialec7.pas: c:/djgpp/bin/ld.exe: cannot find -lncurses collect2: ld returned 1 exit status failed TEST dosunixtest.pas: Error in Assign #1 TEST fjf165a.pas: SKIPPED: German locale not installed TEST gettexttest.pas: c:/djgpp/lib/libintl.a(dcigettext.o)(.text+0x968): In function `__nl_find_msg': dcigettext.c:872: undefined reference to `_libiconv' c:/djgpp/lib/libintl.a(loadmsgcat.o)(.text+0x1b2): In function `__nl_init_domain_conv': loadmsgcat.c:301: undefined reference to `_libiconv_open' c:/djgpp/lib/libintl.a(loadmsgcat.o)(.text+0x1fb): In function `__nl_free_domain_conv': loadmsgcat.c:331: undefined reference to `_libiconv_close' collect2: ld returned 1 exit status failed TEST longr2.pas: SKIPPED: no LongReal math routines available TEST mir029el.pas: failed TEST pipetes2.pas: c:/djgpp/b/gnu/build.gcc/gcc/p/test/a.out: error when reading from file `f' bound to file handle #0 (Bad file descriptor (EBADF)) (error #464 at 291e) TEST pipetest.pas: qwec:/djgpp/b/gnu/build.gcc/gcc/p/test/a.out: assertion failed (error #306 at 2120)
# of GPC tests 3794 # of GPC tests passed 3780 # of GPC tests skipped 2 # of GPC tests failed 12
---------------------------------------------------------------------------------
In fact all errors but the mir029el.pas come from the compiler no more defining by default
-DMSDOS -DDJGPP=2 -DGO32 (and underscored versions)
All errors (except mir029el) disappear if I use EXTRA_TEST_PFLAGS="-gstabs -DMSDOS -DDJGPP=2 -DGO32"
When looking into the the specs files I find that in gcc-3.2.2 these where defined in the sections *cpp: (without underscore) *predefines: (with underscores)
and they have disappeared in gcc-3.3.1
I understand nothing to specs syntax but probably I have to ask on the djgpp list the reason for that. Has any other system the same problem ?
Maurice
Maurice Lombardi a écrit:
In fact all errors but the mir029el.pas come from the compiler no more defining by default
-DMSDOS -DDJGPP=2 -DGO32 (and underscored versions)
All errors (except mir029el) disappear if I use EXTRA_TEST_PFLAGS="-gstabs -DMSDOS -DDJGPP=2 -DGO32"
When looking into the the specs files I find that in gcc-3.2.2 these where defined in the sections *cpp: (without underscore) *predefines: (with underscores)
and they have disappeared in gcc-3.3.1
This seems to be a problem of sync between gcc and gpc. These variables are defined elsewhere in gcc. Indeed if I write a small test program in C -------------------------------------------------------------- #include <stdio.h>
int main(void) { #ifdef DJGPP printf("DJGPP version %d.%d\n",DJGPP,DJGPP_MINOR); #else printf("DJGPP not defined ???\n"); #endif #ifdef MSDOS printf("MSDOS defined\n"); #endif #ifdef GO32 printf("GO32 defined\n"); #endif return 0; } --------------------------------------------------------------
I compile with C:\LOMBARDI\DJGPP\C>gcc -v test2.c -o test2.exe -------------------------------------------------------------- Reading specs from c:/djgpp/lib/gcc-lib/djgpp/3.31/specs Configured with: /devel/gnu/gcc/3.3/gnu/gcc-3.31/configure i586-pc-msdosdjgpp -- prefix=/dev/env/DJDIR --disable-nls Thread model: single gcc version 3.3.1 c:/djgpp/lib/gcc-lib/djgpp/3.31/cc1.exe -quiet -v -D__GNUC__=3 -D__GNUC_MINOR__ =3 -D__GNUC_PATCHLEVEL__=1 -remap -imacros c:/djgpp/lib/gcc-lib/djgpp/3.31/djgpp .ver test2.c -quiet -dumpbase test2.c -auxbase test2 -version -o c:/djgpp/tmp/cc dIBHI3.s GNU C version 3.3.1 (djgpp) compiled by GNU C version 3.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "c:/djgpp/djgpp/include" #include "..." search starts here: #include <...> search starts here: c:/djgpp/lib/gcc-lib/djgpp/3.31/include c:/djgpp/include End of search list. c:/djgpp/bin/as.exe --traditional-format -o c:/djgpp/tmp/cccaplI0.o c:/djgpp/tm p/ccdIBHI3.s c:/djgpp/lib/gcc-lib/djgpp/3.31/collect2.exe -o test2.exe c:/djgpp/lib/crt0.o - Lc:/djgpp/lib -Lc:/djgpp/lib/gcc-lib/djgpp/3.31 -Lc:/djgpp/bin -Lc:/djgpp/lib -L c:/djgpp/lib/gcc-lib/djgpp/3.31/../../.. c:/djgpp/tmp/cccaplI0.o -lgcc -lc -lgcc -Tdjgpp-x.djl c:/djgpp/bin/stubify.exe -v test2.exe stubify for djgpp V2.X executables, Copyright (C) 1995 DJ Delorie stubify: test2.exe -> test2.000 -> test2.exe ------------------------------------------------------------
I obtain the answer
DJGPP version 2.3 MSDOS defined GO32 defined
which shows that all variables are known. DJGPP and friends come from the file djgpp.ver which contains #include <sys/version.h> and this file defines the various DJGPP DJGPP_MINOR with and without underscores. MSDOS and GO32 I do not know.
I gave a look to where this could be defined. It seems to come from file gcc/config/i386/djgpp.h
in gcc-3.2.3 it contained (after application of the djgpp patches) among others: ------------------------------------------------------------------ #undef CPP_PREDEFINES #define CPP_PREDEFINES "-D__MSDOS__ -D__GO32__ -D__DJGPP__=2 -D__unix__ -Asystem=msdos -Asystem=unix"
/* Include <sys/version.h> so __DJGPP__ and __DJGPP_MINOR__ are defined. */ #undef CPP_SPEC #define CPP_SPEC "%(cpp_cpu) %{posix:-D_POSIX_SOURCE} \ %{!ansi:%{!std=c*:%{!std=i*:-DMSDOS -DGO32 -DDJGPP=2 -Dunix}}} \ -remap %{!nostdinc:-imacros %sdjgpp.ver}" ------------------------------------------------------------------------------ the specs file comes from there.
in gcc-3.3.1 this has been replaced by ------------------------------------------------------------------------------ #define TARGET_OS_CPP_BUILTINS() \ do \ { \ if (!flag_iso) \ builtin_define_with_int_value ("DJGPP",2); \ builtin_define_with_int_value ("__DJGPP",2); \ builtin_define_with_int_value ("__DJGPP__",2); \ builtin_define_std ("MSDOS"); \ builtin_define_std ("GO32"); \ builtin_define_std ("unix"); \ builtin_assert ("system=msdos"); \ } \ while (0)
/* Include <sys/version.h> so __DJGPP__ and __DJGPP_MINOR__ are defined. */ #undef CPP_SPEC #define CPP_SPEC "-remap %{posix:-D_POSIX_SOURCE} \ %{!nostdinc:-imacros %sdjgpp.ver}" ------------------------------------------------------------------------------ This gives what we see in the specs file, but in addition there are all those builtins which probably do what we want.
Hope this helps.
Maurice
Maurice Lombardi wrote:
In fact all errors but the mir029el.pas come from the compiler no more defining by default
I get the mir029el.pas on other platforms with gcc-3.3. The problem seems to be that set initializers with a single element of (ordinal) value 0 are mistaken as empty. I'll try to investigate, but currently I haven't got much time to work on GPC, so ...
Frank
Waldek Hebisch wrote:
gpc-20030830 have a memory management bug which is probably responsible for crashes reported by Adriaan van Os and Maurice Lombardi. Mainly builds with gcc-3.3.x are affected (I do not know if it is possible to trigger the bug with earlier gcc version). The patch below fixes the problem:
Thanks. I've updated the archives on the server since the bug may be quite serious even with previous gcc versions.
Frank
On 31 Aug 2003 at 6:49, Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/.
[...]
I have built this successfully under Windows (Mingw and Cygwin). Most of the testsuite runs okay, but some tests are failed - viz:
1. Mingw: Testing gpc.exe 20030830, based on gcc-3.3.1 (mingw special 20030804-1) (mingw32) [....] TEST aturbo3test.pas: d:/mingw/bin/../lib/gcc- lib/mingw32/3.3.1/collect2.exe: cannot find -lncurses failed [and other complaints about ncurses - which I am not sure will ever be ported to Mingw]
TEST dosunixtest.pas: Error in Assign #1
TEST fjf401.pas: failed 1: /etc/d:\src\mingw\gcc-3.3.1-20030804- 1\gcc\p\test\a.conf (expected: /etc/a.conf)
TEST mir029el.pas: failed
TEST pipetes2.pas: Could not create pipe: program `d:\src\mingw\gcc- 3.3.1-20030804-1\gcc\p\test\a.exe' not found
TEST pipetest.pas: qwed:\src\mingw\gcc-3.3.1-20030804- 1\gcc\p\test\a.exe: assertion failed (error #306 at 401e77)
2. Cygwin: Testing gpc 20030830, based on gcc-3.2.3 (i686-pc-cygwin) [...] TEST params.pas: failed: ./a
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) and others wrote:
TEST mir029el.pas: failed
It's a backend bug in gcc-3.3 (platform independent). Here's a fix, thanks to Waldek Hebisch. (Apply manually or add to p/diffs/gcc-3.3.diff if you *haven't* build GPC with gcc-3.3 yet.)
Frank
-
Adriaan van Os -
Emil Jerabek -
Frank Heckenbach -
Frank Heckenbach -
Jean-Pierre Vial -
Matthias Klose -
Maurice Lombardi -
Prof A Olowofoyeku (The African Chief) -
Waldek Hebisch