According to Bill Currie:
Sigh, got gpi-hash fixed and now this :(
At least it's easy to reproduce, I just have absolutly no understanding of what's going on.
Just compile with `gpc -O2 -c system.pas'.
Reproducible. :-)
A warning is given (doesn't make sense to me yet)
You commented out the definition of `LongInt' to be `Integer' (32 bits), so GPC used its built-in `LongInt' (64 bits), whereas pointers on iX86 processors only have 32 bits.
and then the call to `convert' in `build_c_cast' (line 5316 in gpc-typeck.c) goes bananas (infinite(?) recursion). This happens in fillchar (line 178) [...]
Fixed. :-) Patch for `gpc-typeck.c' below.
There's also a strange bug where an untytped constant that's declared in one unit that's used by onother and both of those are used by a third gets lost to the third unit if the second unit is `used' after the first. Unfortunatly, I have yet to reproduce this in small files.
And unfortunately, I cannot reproduce it by myself. :-( But I don't expect this to be as weird as the "hashing" bug you just fixed. :-)
Greetings,
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]
8< ---- gpc-typeck.c.diff ----------------------------------------------------
@@ -5303,7 +5308,9 @@ pedwarn ("constant out of range - truncated"); }
- if (TREE_UNSIGNED (type) != TREE_UNSIGNED (TREE_TYPE (value)) + if (TREE_CODE (type) != POINTER_TYPE + && TREE_CODE (TREE_TYPE (value)) != POINTER_TYPE + && TREE_UNSIGNED (type) != TREE_UNSIGNED (TREE_TYPE (value)) && TYPE_PRECISION (type) != TYPE_PRECISION (TREE_TYPE (value))) { /* Do the conversion in two stages, e.g.