Waldek Hebisch wrote:

Adriaan van Os wrote:

...

Now that gpc has preliminary support for gcc-4 (thanks!) I am trying to build a 64-bit libgpc.a for use with -m64 on powerpc-apple- darwin8. This results in an ICE in fname.pas.

../.././xgpc -B../.././ -c -I. -W -Wall -Wmissing-prototypes - Wmissing-declarations -g -O2 -m64 --unit-path=/Users/adriaan/gnu/ gpc/gpc-20060325/gcc-4/gcc-4.0.3/gcc/p/rts --automake - DRTS_RELEASE_STRING="'`cat /Users/adriaan/gnu/gpc/gpc-20060325/gcc-4/ gcc-4.0.3/gcc/p/rts/rts-version`'" -DGCC_VERSION="'4.0.3'" "/Users/ adriaan/gnu/gpc/gpc-20060325/gcc-4/gcc-4.0.3/gcc/p/rts/random.pas" ../.././xgpc -B../.././ -c -I. -W -Wall -Wmissing-prototypes - Wmissing-declarations -g -O2 -m64 --unit-path=/Users/adriaan/gnu/ gpc/gpc-20060325/gcc-4/gcc-4.0.3/gcc/p/rts --automake - DRTS_RELEASE_STRING="'`cat /Users/adriaan/gnu/gpc/gpc-20060325/gcc-4/ gcc-4.0.3/gcc/p/rts/rts-version`'" -DGCC_VERSION="'4.0.3'" "/Users/ adriaan/gnu/gpc/gpc-20060325/gcc-4/gcc-4.0.3/gcc/p/rts/fname.pas" /Users/adriaan/gnu/gpc/gpc-20060325/gcc-4/gcc-4.0.3/gcc/p/rts/ fname.pas: In function `InternalFSearch': /Users/adriaan/gnu/gpc/gpc-20060325/gcc-4/gcc-4.0.3/gcc/p/rts/ fname.pas:705: internal compiler error: in output_constant, at varasm.c:3929 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. make[2]: *** [fname.o] Error 1 make[1]: *** [pascal.rts] Error 2 make: *** [all-gcc] Error 2

It would be nice to have a 64-bit darwin compiler available for download at some point, but it is not urgent.

Again, I can not reproduce the ICE. But I have noticed that I am getting ICE when I compile using -m64 flag when there are .gpi files compiled using -m32. So, I wonder if you used clean directory for 64-bit compilation (it looks that you re-used build directory directory, did you remove old .gpi files?).

Thanks for looking into this.

Initially, my attempt to rebuild libgpc.a failed (see below), so I tried various ways to build the compiler with -m64 (pass env CC="gcc -m64" to configure or add -m64 to CFLAGS during make or make bootstrap). This all resulted in the error above (that was in a fresh build directory).

However, I now found out why my initial attempt to simply rebuild libgpc.a in build/gcc/p/rts failed. I typed

[G5:gcc/p/rts] adriaan% rm *.o *.gpi [G5:gcc/p/rts] adriaan% make

or

[G5:gcc/p/rts] adriaan% rm *.o *.gpi [G5:gcc/p/rts] adriaan% make CFLAGS="-O2 -m64"

and this results in

`echo /Users/adriaan/gpc/gpc-20060325/gcc-4/build/gcc/xgcc -B/Users/adriaan/gpc/gpc-20060325/gcc-4/build/gcc/ -B/Developer/Pascal/gpc403d1/powerpc-apple-darwin8/bin/ -B/Developer/Pascal/gpc403d1/powerpc-apple-darwin8/lib/ -isystem /Developer/Pascal/gpc403d1/powerpc-apple-darwin8/include -isystem /Developer/Pascal/gpc403d1/powerpc-apple-darwin8/sys-include | sed 's,^([^ ]*[/][^/]*)gcc,\1gpc,;s/^gcc$/gpc/' ` -c -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations -O2 --unit-path=/Users/adriaan/gpc/gpc-20060325/gcc-4/gcc-4.0.3/gcc/p/rts --automake -DRTS_RELEASE_STRING="'`cat /Users/adriaan/gpc/gpc-20060325/gcc-4/gcc-4.0.3/gcc/p/rts/rts- version`'" -DGCC_VERSION="'unknown'" --no-automake "/Users/adriaan/gpc/gpc-20060325/gcc-4/gcc-4.0.3/gcc/p/rts/heap.pas" /Users/adriaan/gpc/gpc-20060325/gcc-4/gcc-4.0.3/gcc/p/rts/heap.pas:38: error: module/unit interface `Error' could not be imported make: *** [heap.o] Error 1

I should have typed

[G5:gcc/p/rts] adriaan% make clean [G5:gcc/p/rts] adriaan% make

or

[G5:gcc/p/rts] adriaan% make clean [G5:gcc/p/rts] adriaan% make CFLAGS="-O2 -m64"

and building a 64-bit libgpc.a works !

With lipo, the 32-bit and 64-bit libgpc.a can be combined into one "fat" libgpc.a.

[G5:~/gpc/testgpc/adriaan] adriaan% gpc hello.pas -m64 can't find atom for N_GSYM stabs Fakehighletters:G(0,7) in /Developer/Pascal/gpc403d1/lib/gcc/powerpc-apple-darwin8/4.0.3/ libgpc.a(rtsc.o) ld64 failed: in /Developer/Pascal/gpc403d1/lib/gcc/powerpc-apple-darwin8/4.0.3/ libgcc.a(_fixtfdi.o), not a valid ppc64 mach-o file collect2: ld returned 1 exit status

So, next I will try to build a 64-bit libgcc and combine the 32-bit and 64-bit libgcc.a into a "fat" libgcc.a

Regards,

Adriaan van Os

...

[G5:~/gpc/testgpc/adriaan] adriaan% gpc hello.pas -m64 can't find atom for N_GSYM stabs Fakehighletters:G(0,7) in /Developer/Pascal/gpc403d1/lib/gcc/powerpc-apple-darwin8/4.0.3/ libgpc.a(rtsc.o) ld64 failed: in /Developer/Pascal/gpc403d1/lib/gcc/powerpc-apple-darwin8/4.0.3/ libgcc.a(_fixtfdi.o), not a valid ppc64 mach-o file collect2: ld returned 1 exit status

So, next I will try to build a 64-bit libgcc and combine the 32-bit and 64-bit libgcc.a into a "fat" libgcc.a

At least, it says hello to the world when using the system-installed dynamic libgcc.

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.

Regards,

Adriaan van Os

------

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 chief35b.pas: failed foo4 43 2251795518715392 43

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 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 ?

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)

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 fsc22.pas: failed

TEST fsc24.pas: failed

TEST gpc_c_p.pas: 10c10 < PascalUnitVariable is now 4294967338. ---

PascalUnitVariable is now 43.

16c16 < PascalProgramVariable is now 53021371269137. ---

PascalProgramVariable is now 12345.

failed TEST gpcu_c_u.pas: 11c11 < PascalUnitVariable is now 4294967338. ---

PascalUnitVariable is now 43.

failed

*** 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)

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

TEST toby2.pas: failed: ./toby2.pas:2: internal compiler error: in mseek, at p/module.c:355 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions.

TEST writeb.pas: Run #2: LongInt `-7890123456789012345' was not indented, but should be. ... Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. ...

TEST writec.pas: SP: LongInt `-7890123456789012345' was not indented, but should be. ... Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. ...

TEST writee.pas: EP: LongInt `-7890123456789012345' was not indented, but should be. ... Run #1: LongInt `-7890123456789012345' was not indented, but should be. ... Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. ...

TEST writeg.pas: Run #2: LongInt `-7890123456789012345' was not indented, but should be. ... Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. ...

Frank Heckenbach wrote:

Adriaan van Os wrote:

...

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?

It's included.

...

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.

Yes, the test program is wrong, I just hinted at $R- for constants.

Regards,

Adriaan van Os

Frank Heckenbach wrote:

Waldek, what's the status WRT 128 bit integer types? Is it realistic to support them in the foreseeable future (or with which backend version)?

I think so. I have adapted older gpc version to use 128 bit integer types on 64-bit targets. That patch triggered multiple backed bugs. Most of them was fixed in the meantime. I felt that other problems were more urgent so I did not look at this recently.

Concerning backends: backporting fixes to backends earlier that 3.3 probably requires too much work. 3.3 and later should be doable with a little effort.

Frank Heckenbach wrote:

I'm still testing with 3.2.3 too, but I also thought about dropping it recently. Since the external preprocessor was the last obstacle in adopting 3.3 and 3.4, I think we can drop 3.2.x officially (i.e., remove the 3.2.x diffs in the next release). Objections anyone? (If 3.3 turns out problematic, I wouldn't mind dropping it also.)

I check that snapshot build with all supported backends (including 2.8.1, 2.95.3 and 3.2.3). However gcc-20060325 when build with one of those backend prints a depreciation message and waits for a newline. My plan is to keep the message for the next few snapshots and then really limit support.

BTW. I think the we should drop not only support for 3.2.3 but also for 2.8.1 and 2.95.3. There are some reasons to keep support for 2.8.1 and 2.95.3 longer than support for 3.2.3, but OTOH 2.8.1 and 2.95.3 require more work to support than 3.2.3. Also, IIRC in the last two years we did not have any bug reports involving recent frontends and 2.x backend. Since most reported bugs were reproducible with such combination, I think that nobody reading gpc mailing list is using modern gpc with old backends.

No further objections from me. When I have time to upgrade GPC again, I'll fight through the GCC upgrades at the same time).

--------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)865-5723 | --------------------------|

On Thu, 20 Apr 2006, Frank Heckenbach wrote:

Waldek Hebisch wrote:

...

Frank Heckenbach wrote:

...

I'm still testing with 3.2.3 too, but I also thought about dropping it recently. Since the external preprocessor was the last obstacle in adopting 3.3 and 3.4, I think we can drop 3.2.x officially (i.e., remove the 3.2.x diffs in the next release). Objections anyone? (If 3.3 turns out problematic, I wouldn't mind dropping it also.)

I check that snapshot build with all supported backends (including 2.8.1, 2.95.3 and 3.2.3). However gcc-20060325 when build with one of those backend prints a depreciation message and waits for a newline. My plan is to keep the message for the next few snapshots and then really limit support.

I agree.

Of course, this will be final then, as dropping support, especially for gcc-2.x, means not only removing the diffs from the distribution, but also removing conditionals all over the place in the GPC source, and reintroducing them later will be quite unfeasible. So anyone objecting to dopping these versions shall speak up now or remain silent forever. ;-)

BTW, in a recent (Feb) thread about dropping gcc-2 (subject: "RTS and thread safety"), the only objection came from John L. Ries:

: Actually, I'm still running GCC 2.95 on several of my older UNIX boxes : because my efforts to compile newer versions there have failed. Not that : I need a new GPC on any of them, but it goes to show 2.95 is still in : active use in at least a few places. : : That said, I think you can safely drop support for GCC versions prior to : 2.95.

I doesn't make much sense to drop 2.8.1 and not 2.95, so I'll guess you (John) will have to face trying to build with gcc-3.4.x again (if you want current GPC versions on them). When there are problems, please report them here, so we can hopefully solve them. But you'll have at least a few months from now ...

...

BTW. I think the we should drop not only support for 3.2.3 but also for 2.8.1 and 2.95.3. There are some reasons to keep support for 2.8.1 and 2.95.3 longer than support for 3.2.3, but OTOH 2.8.1 and 2.95.3 require more work to support than 3.2.3. Also, IIRC in the last two years we did not have any bug reports involving recent frontends and 2.x backend. Since most reported bugs were reproducible with such combination, I think that nobody reading gpc mailing list is using modern gpc with old backends.

Well, actually I am ;-), but I'm going to change it. (The main problem is that the build system has changed quite a bit between gcc-2 and gcc-3, especially in Cross-Compiler, Cross-Build and Canadian-Cross situations, which I have a few, so I might have to rewrite some of my build/install scripts quite a bit, but I expect no serious problems in the end.)

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

Waldek Hebisch wrote:

Adriaan van Os wrote:

...

Frank Heckenbach wrote:

...

Adriaan van Os wrote:

...

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?

It's included.

Thanks, applied.

Somehow, I forgot gpcu_c_u.pas in the diffs. Additional patch included.

Regards,

Adriaan van Os