Adriaan van Os wrote:
OK, I built the 64-bit and fat libgcc and then turned to the testsuite, expecting many failures, but there were less than I had thought. This apart from problems with stabs and dwarf-2 debug info, that I ignored for now (not reproducing "can't find atom for N_GSYM stabs ..." in the results below). In fact, I believe that some of the testsuite is wrong in a situation where Integer and Longint are both 64-bit and CInteger is 32-bit, as on powerpc-apple-darwin-8 when using -m64 to create 64-bit binaries.
Some of the failures (not all) are reproduced below, with my comments. One possible fix of the testsuite is to replace Integer by CInteger where appropriate.
Yes. Have you made a diff already?
TEST c_gpc.pas: 13c13
< PascalProgramVariable is now 53021371269137.
PascalProgramVariable is now 12345.
failed
*** c_gpc.pas is wrong (two occurences of Integer should be CInteger)
TEST gpc_c_p.pas: TEST gpcu_c_u.pas:
*** gpc_c_p.pas is wrong (two occurences of Integer should be CInteger), *** gpc_c_u.pas is wrong (one occurence of Integer should be CInteger)
Clearly wrong in the test programs, indeed.
TEST chief40.pas: ./chief40.pas: In main program: ./chief40.pas:8: error: constant out of range ./chief40.pas:11: error: arithmetical overflow ./chief40.pas:11: error: constant overflow in expression ./chief40.pas:14: error: arithmetical overflow ./chief40.pas:14: error: constant overflow in expression failed
*** compiler is right, testsuite is wrong
TEST fjf526a.pas: ./fjf526a.pas: In main program: gpc1: warnings being treated as errors ./fjf526a.pas:8: warning: left shift count >= width of type failed
*** compiler is right, testsuite is wrong
TEST fjf526b.pas: ./fjf526b.pas: In main program: gpc1: warnings being treated as errors ./fjf526b.pas:8: warning: left shift count >= width of type failed
*** compiler is right, testsuite is wrong
TEST shl.pas: ./shl.pas: In main program: gpc1: warnings being treated as errors ./shl.pas:9: warning: left shift count >= width of type ./shl.pas:11: warning: right shift count >= width of type ./shl.pas:21: warning: left shift count >= width of type ./shl.pas:23: warning: right shift count >= width of type failed
*** compiler is right, testsuite is wrong
Yes, these tests rely on there being a type larger than `Integer', which is currently not guaranteed. Changing to CInteger will probably help (though not strictly guaranteed either, except perhaps indirectly via C standards which I don't know, but rather likely for all backends). FWIW, I still think it's problematic when there's no larger type than `Integer', as probably quite a few real programs implicitly rely on it, but until we have 128 bit type support, it seems there's nothing we can do about it.
TEST fjf327.pas: ./fjf327.pas: In main program: ./fjf327.pas:9: error: constant out of range failed
*** compiler is right, testsuite is wrong (I recall the discussion on range checking for constants)
What does the discussion have to do with it? AFAICS, it's the same issue as before: The test program assumes that the negative of the maximum value of Cardinal is representable which is true if and only if Cardinal is smaller than LongestInt. So, yes, the test program is wrong, as before.
TEST chuck6.pas: 1c1,4
< ./a.out: value out of range (error #300 at 28a3)
-10 10 -10 10 -10 10
failed
*** see the recent discussion on subrange expressions ?
I don't think so here. This test program is purely standard Pascal (obviously, being written by Chuck :-) and correct AFAICS. That GPC chooses an unsigned 64 bit (here) type for the type called "unsigned" is GPC's decision. It could have chosen signed as well, as it goes only up to maxint, and in fact, in ISO Pascal there's only subranges of (signed) Integer, so all the operations are correct.
How to fix this is another question. We could make subranges (formally) signed if they fit into a default signed type of a size not larger than the unsigned type otherwise chosen, but I fear this might cause other problems. This is a tricky area (but at least we could try it) ...
Frank