I have put patches which allow compiling gpc-20041218 with gcc-3.4.3. Note that the patch also contains support for qualified identifiers and a few fixes to structured value constructors.
The patch should work with all supported backends 2.8.1, 2.95.3, 3.2.3 3.3.x, 3.4.3 (for 2.8.1 you need an extra backend patch) -- it should just give you qualified identifiers support.
I would recommend the patch for AMD64, since gcc-3.3 on AMD64 has a number of problems which are fixed in gcc-3.4.3. Also, the patch works around packed array problem with gcc-3.3 on AMD64 (they did not work, with the patch the main problem is fixed).
Waldek Hebisch wrote:
I have put patches which allow compiling gpc-20041218 with gcc-3.4.3. Note that the patch also contains support for qualified identifiers and a few fixes to structured value constructors.
Thanks a lot Waldek for these patches !
FAIL: avo7.pas
Running the testsuite, I found one (new) problem. The back-end patch file doesn't have the recent diff that solves the "avo7.pas" problem (see http://www.gnu-pascal.de/crystal/gpc/en/mail11092.html).
*** gcc/gcc.c.orig Thu Apr 1 18:55:17 2004 --- gcc/gcc.c Thu Nov 25 14:06:13 2004 *************** *** 733,740 **** "%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}}\ %1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*}\ %{c|S:%{o*:-auxbase-strip %*}%{!o*:-auxbase %b}}%{!c:%{!S:-auxbase %b}}\ ! %{g*} %{O*} %{W*&pedantic*} %{w} %{std*} %{ansi}\ ! %{v:-version} %{pg:-p} %{p} %{f*} %{undef}\ %{Qn:-fno-ident} %{--help:--help}\ %{--target-help:--target-help}\ %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}}\ --- 733,740 ---- "%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}}\ %1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*}\ %{c|S:%{o*:-auxbase-strip %*}%{!o*:-auxbase %b}}%{!c:%{!S:-auxbase %b}}\ ! %{g*} %{O*} %{f*&W*&pedantic*&w} %{std*} %{ansi}\ ! %{v:-version} %{pg:-p} %{p} %{undef}\ %{Qn:-fno-ident} %{--help:--help}\ %{--target-help:--target-help}\ %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}}\
[G4:gcc/p/test] adriaan% cat avo7.pas { FLAG --gnu-pascal -Wno-underscore }
program NoUnderscore;
procedure _Run; begin writeln('OK') end;
begin _Run end.
Regards,
Adriaan van Os
Adriaan van Os wrote:
FAIL: avo7.pas
Running the testsuite, I found one (new) problem. The back-end patch file doesn't have the recent diff that solves the "avo7.pas" problem (see http://www.gnu-pascal.de/crystal/gpc/en/mail11092.html).
I know about the problem. I have reverted the `gcc.c' patch since with the patch applied (and with gcc-3.4) I got failure in `fjf203.pas'. I feel that we should examine the problem more carefully, before we choose a solution.
Waldek Hebisch wrote:
Adriaan van Os wrote:
FAIL: avo7.pas
Running the testsuite, I found one (new) problem. The back-end patch file doesn't have the recent diff that solves the "avo7.pas" problem (see http://www.gnu-pascal.de/crystal/gpc/en/mail11092.html).
I know about the problem. I have reverted the `gcc.c' patch since with the patch applied (and with gcc-3.4) I got failure in `fjf203.pas'. I feel that we should examine the problem more carefully, before we choose a solution.
With the patch applied, both tests pass on powerpc-apple-darwin:
[G4:gcc/p/test] adriaan% make MASK="fjf203.pas avo7.pas" rm -f *.dat *.o *.s *.i *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.i todo/*.gpi todo/*.gpd todo/core PC="gpc" PFLAGS=" --autobuild -g -O3 -W -Wall -Wno-unused " PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" fjf203.pas avo7.pas | tee test_log | "./test_sum" -d Test Run By adriaan on 2005-01-11 11:01:58 Native configuration is powerpc-apple-darwin (G4.local.)
=== gpc tests ===
Running target any Running testsuite ...
=== gpc Summary ===
# of tests 2 # of expected passes 2
gpc version 20041218, based on gcc-3.4.3
Regards,
Adriaan van Os
Waldek Hebisch wrote:
I have put patches which allow compiling gpc-20041218 with gcc-3.4.3. Note that the patch also contains support for qualified identifiers and a few fixes to structured value constructors.
Thanks a lot Waldek for these patches !
FAIL: avo7.pas
Running the testsuite, I found one (new) problem. The back-end patch file doesn't have the recent diff that solves the "avo7.pas" problem (see http://www.gnu-pascal.de/crystal/gpc/en/mail11092.html).
There is another problem, probably related to qualified identifiers.
In the GNU Pascal Interfaces for Mac OS X, based on Apple's PInterfaces, we have a unit CGError. It defines a type CGError (a signed 32-bit integer).
unit CGError; interface .... uses MacTypes,CGBase; .... type CGError = SInt32;
Another unit uses both the type and the unit CGError:
unit CGDirectDisplay; interface .... uses MacTypes,CGBase,CGGeometry,CGError,CFArray,CFString,CFDictionary; .... --> type CGDisplayErr = CGError;
This results in an error message
cgdirectdisplay.pas:89: error: type name expected, `CGError' given
Regards,
Adriaan van Os
Adriaan van Os wrote:
There is another problem, probably related to qualified identifiers.
In the GNU Pascal Interfaces for Mac OS X, based on Apple's PInterfaces, we have a unit CGError. It defines a type CGError (a signed 32-bit integer).
unit CGError; interface .... uses MacTypes,CGBase; .... type CGError = SInt32;
We probably should warn here that the type will usually be shadowed by unit name.
Another unit uses both the type and the unit CGError:
unit CGDirectDisplay; interface .... uses MacTypes,CGBase,CGGeometry,CGError,CFArray,CFString,CFDictionary; .... --> type CGDisplayErr = CGError;
This results in an error message
cgdirectdisplay.pas:89: error: type name expected, `CGError' given
I do not not how Apple Pascal behaved, but in most Pascal dialects the code above is considered incorrect. Namely, in qualified identifiers unit names can appear in the same places where records can appear. Logically (unles one uses some _very_ strange overloading) unit names conflict with ordinary identifiers. For Borland compatibility GPC does not signal error when unit `CGError' is defined or used, but only when one tries to use `CGError' defined in the unit. Similar problems appeared in GPC standard units and is now fixed by renaming units.
Is the unit name (`CGError') part of established interface? Would renaming the unit cause serious problems?
Waldek Hebisch wrote:
Adriaan van Os wrote:
There is another problem, probably related to qualified identifiers.
In the GNU Pascal Interfaces for Mac OS X, based on Apple's PInterfaces, we have a unit CGError. It defines a type CGError (a signed 32-bit integer).
unit CGError; interface .... uses MacTypes,CGBase; .... type CGError = SInt32;
We probably should warn here that the type will usually be shadowed by unit name.
Another unit uses both the type and the unit CGError:
unit CGDirectDisplay; interface .... uses MacTypes,CGBase,CGGeometry,CGError,CFArray,CFString,CFDictionary; .... --> type CGDisplayErr = CGError;
This results in an error message
cgdirectdisplay.pas:89: error: type name expected, `CGError' given
I do not not how Apple Pascal behaved, but in most Pascal dialects the code above is considered incorrect. Namely, in qualified identifiers unit names can appear in the same places where records can appear. Logically (unles one uses some _very_ strange overloading) unit names conflict with ordinary identifiers. For Borland compatibility GPC does not signal error when unit `CGError' is defined or used, but only when one tries to use `CGError' defined in the unit. Similar problems appeared in GPC standard units and is now fixed by renaming units.
Is the unit name (`CGError') part of established interface? Would renaming the unit cause serious problems?
It is part of established interface, so renaming the unit breaks compatibilty. For any change we make, we have to think twice. Also, there are similar problems in other units.
The parser accepts
type CGDisplayErr = CGError.CGError;
so, why shouldn't it accept
type CGDisplayErr = CGError;
Regards,
Adriaan van Os
On 12 Jan 2005 at 14:36, Adriaan van Os wrote:
Waldek Hebisch wrote:
Adriaan van Os wrote:
There is another problem, probably related to qualified identifiers.
In the GNU Pascal Interfaces for Mac OS X, based on Apple's PInterfaces, we have a unit CGError. It defines a type CGError (a signed 32-bit integer).
unit CGError; interface .... uses MacTypes,CGBase; .... type CGError = SInt32;
We probably should warn here that the type will usually be shadowed by unit name.
Another unit uses both the type and the unit CGError:
unit CGDirectDisplay; interface .... uses MacTypes,CGBase,CGGeometry,CGError,CFArray,CFString,CFDictionary; .... --> type CGDisplayErr = CGError;
This results in an error message
cgdirectdisplay.pas:89: error: type name expected, `CGError' given
I do not not how Apple Pascal behaved, but in most Pascal dialects the code above is considered incorrect. Namely, in qualified identifiers unit names can appear in the same places where records can appear. Logically (unles one uses some _very_ strange overloading) unit names conflict with ordinary identifiers. For Borland compatibility GPC does not signal error when unit `CGError' is defined or used, but only when one tries to use `CGError' defined in the unit. Similar problems appeared in GPC standard units and is now fixed by renaming units.
Is the unit name (`CGError') part of established interface? Would renaming the unit cause serious problems?
It is part of established interface, so renaming the unit breaks compatibilty. For any change we make, we have to think twice. Also, there are similar problems in other units.
The parser accepts
type CGDisplayErr = CGError.CGError;
so, why shouldn't it accept
type CGDisplayErr = CGError;
Because there are two CGError's. Which of them is being referred to?
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.greatchief.plus.com/
Adriaan van Os wrote:
The parser accepts
type CGDisplayErr = CGError.CGError;
so, why shouldn't it accept
type CGDisplayErr = CGError;
Consider:
type rt = record CGError : integer end; var CGError : rt; i : integer; rv : rt;
then the compiler accepts:
rv := CGError; i := CGError.CGError;
but rejects:
i := CGError;
Imagine now that `CGError' variable is defined in `CGError' unit. What does it mean then:
i := CGError.CGError;
Is it record `CGError' form unit `CGError' or is it field `CGError' from the `CGError' record?
By the way, does Apple Pascal support qualified identifiers?
Waldek Hebisch wrote:
Adriaan van Os wrote:
There is another problem, probably related to qualified identifiers.
In the GNU Pascal Interfaces for Mac OS X, based on Apple's PInterfaces, we have a unit CGError. It defines a type CGError (a signed 32-bit integer).
unit CGError; interface .... uses MacTypes,CGBase; .... type CGError = SInt32;
We probably should warn here that the type will usually be shadowed by unit name.
But what if a type T is defined in another unit, independent of a unit T with the same name ? Then it might be a bit difficult to issue a warning.
Consider:
type rt = record CGError : integer end; var CGError : rt; i : integer; rv : rt;
then the compiler accepts:
rv := CGError; i := CGError.CGError;
but rejects:
i := CGError;
Imagine now that `CGError' variable is defined in `CGError' unit. What does it mean then:
i := CGError.CGError;
Is it record `CGError' form unit `CGError' or is it field `CGError' from the `CGError' record?
Hm, yes, that is a problem, so I guess there is no other solution than changing the interface names. Peter ? Gale ? I thought about a command-line switch --no-qualified-identifiers, but even if there were such an option, we would like the interfaces to compile with programs that have qualified identifiers enabled, don't we ?
By the way, does Apple Pascal support qualified identifiers?
MPW Pascal and Think Pascal don't. MW Pascal does so (according to the docs) but in reality it only supports "System.xxx" to differentiate between a built-in runtime routine "xxx" and another routine "xxx".
Best regards,
Adriaan van Os