I have uploaded a new beta version of GPC to http://www.gnu-pascal.de!
The main changes are fixes for 64 bit platforms that were partly broken with 20041017 (some tests still fail on these platforms, but these are mostly problems with the tests themselves), and slightly improved compatibility to Mac Pascal dialects.
In detail, new features:
- `Exit' with an argument (non-local exits not yet supported) (fjf988*.pas) (U)
- new options `--[no-]propagate-units' (on by default with `--mac-pascal', off in other dialects) (fjf987*.pas) (M)
- enable `Pointer' in `--mac-pascal' mode (Mac Pascal has a `Pointer' function which does the same as a type-cast to `Pointer'; though adding `Pointer' as a type allows more, it's backward-compatible) (M)
- `&' and `|' (shortcut `and' and `or') (fjf981*.pas) (M)
- `Leave' and `Cycle' (equivalent to `Break' and `Continue') (avo3.pas) (M)
- optimize `WriteLn (... string_constant') and `Write (... string_constant, string_constant ...)'
- `BindingType' is now a packed record as EP demands (fjf975a.pas) (E)
Fixed bugs:
- accessing components of a constant (EP) constructor (indexed by a constant for arrays) must yield a constant again (dave3*.pas)
- GPC crashes when using two variables with identically-named fields in a single `with' statement (withbug.pas)
- GPC doesn't accept `case' statements without case-list-elements (fjf982*.pas)
- gcc-3.x: options are wrongly reordered (so, e.g., `--gnu-pascal -Wno-underscore' doesn't work as expected) (avo7.pas)
- applying `not' to a function result in parentheses doesn't work (avo6.pas)
- packed array indices containing `mod' don't work (avo4.pas)
- GPC sometimes prints `???' instead of the actual file name in messages
- function results (of record type) must not be allowed as `with' elements (only a warning in `--delphi' and `--mac-pascal' modes for compatibility); fields of non-lvalue `with' elements must not be lvalues either (fjf493*.pas)
- value parameters of type `String' (undiscriminated) must take the capacity of the actual parameter, according to EP (waldek11*.pas)
- initialized types in arrays (fjf233.pas, fjf974*.pas)
- initializers are ignored in `New' and `Initialize' (fjf967[j-l].pas)
- the address of global routines is not allowed in initializers (avo2*.pas)
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 NEW! GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8
Frank Heckenbach wrote:
- new options `--[no-]propagate-units' (on by default with `--mac-pascal', off in other dialects) (fjf987*.pas) (M)
Here are some additional notes about the --[no-]propagate-units flag.
1. Compilation speed
In GPC, loading .gpi files is a recursive process of order O (2). This means that:
- the more units, the slower GPC becomes - in large projects with many units, most time is spent in loading and reloading of .gpi files.
The workaroud is to:
(a) activate --propagate-units (this copies .gpi data of used units into the .gpi file of the compiled unit) (b) remove all USES clause entries for units that are no longer needed (because they are not used at all or because of the --propagate-units flag) (c) use gp instead of gpc (gp works very well and doesn't have the bugs of --automake)
This will lead to a dramatic increase in compilation speed for large GPC projects.
2. Master units
Suppose, we have a program P that uses units tb1, tb2, tb3, tb4, representing a custom toolbox, plus some other units
program P; uses tb1, tb2, tb3, tb4, util1, util2; ...
Now, we can put toolbox units tb1, tb2, tb3 and tb4 in a master "toolbox" unit
unit toolbox; interface uses tb1, tb2, tb3, tb4; end.
and use it in P instead of tb1 ... tb4
program P; uses toolbox, util1, util2; ...
We have gained the freedom to make interface changes to tb1 .. tb4, without the need of changes at a higher level (e.g. you can add a unit tb5 or move a routine from one tb unit to another).
3. Local use
The compiler directives {$propagate-units} and {$no-propagate-units} can be used for fine-tuning or selective unit-propagation.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
- new options `--[no-]propagate-units' (on by default with `--mac-pascal', off in other dialects) (fjf987*.pas) (M)
Here are some additional notes about the --[no-]propagate-units flag.
- Compilation speed
In GPC, loading .gpi files is a recursive process of order O (2). This means that:
Please note that this applies to the number of units, not the number of declarations. So it's mainly a problem for projects with hundreds of units (which seems to be common on Mac Pascal for historical reasons, but which I don't see often elsewhere).
And, BTW, it's recursive only when using automake. With GP (or any self-made Makefile etc.) it's iterative. Of course, this doesn't change the O(n^2) time requirements, but cuts down on memory requirements (which are, I think O(n^2) with automake in the worst case, mostly(*) O(n) otherwise, again measured in the number of units).
(*) which means there is a very small O(n^2) factor in GP for the dependency information, but there don't have to be O(n^2) gpi file contents in memory at one time, as can happen with recursive automake (O(n) compilations running, each loading O(n) interfaces)
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
- Compilation speed
In GPC, loading .gpi files is a recursive process of order O (2). This means that:
Please note that this applies to the number of units, not the number of declarations. So it's mainly a problem for projects with hundreds of units (which seems to be common on Mac Pascal for historical reasons, but which I don't see often elsewhere).
I think the increase in compilation speed will be quite noticeable with regular projects of 20-100 units also (e.g. projects with about 60.000 to 300.000 lines of Pascal).
Regards,
Adriaan van Os
Frank,
I have uploaded a new beta version of GPC to http://www.gnu-pascal.de!
Builds and runs on Mac OS X. The testsuite passes, apart from known Mac OS X problems.
--
[G4:gcc/p/test] adriaan% make PC=gpc335d2 EXTRA_PFLAGS=--longjmp-all-nonlocal-labels 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="gpc335d2" PFLAGS=" --autobuild -g -O3 -W -Wall -Wno-unused --longjmp-all-nonlocal-labels " PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused --longjmp-all-nonlocal-labels " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | tee test_log | "./test_sum" -d Test Run By adriaan on 2004-12-19 12:39:59 Native configuration is powerpc-apple-darwin (G4.local.)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas UNSUPPORTED: asmtest.pas UNSUPPORTED: fjf165a.pas UNSUPPORTED: gmptest.pas UNSUPPORTED: longr2.pas FAIL: nonloc2goto.pas FAIL: nonloc4goto.pas FAIL: systemtest.pas
=== gpc Summary ===
# of tests 4112 # of expected passes 4102 # of unexpected failures 3 # of unsupported tests 7
gpc335d2 version 20041218, based on gcc-3.3.5
--
I used the gcc-3.3.4.diff, which applies, apart from one hunk. I looks as if this hunk is no longer needed with gcc-3.3.5.
*** gcc/emit-rtl.c.orig Wed Dec 10 18:37:18 2003 --- gcc/emit-rtl.c Sun Oct 24 11:26:55 2004 *************** *** 301,309 **** --- 301,313 ---- if (alias == 0 && expr == 0 && offset == 0 && (size == 0 || (mode != BLKmode && GET_MODE_SIZE (mode) == INTVAL (size))) + #ifndef GPC && (align == BITS_PER_UNIT || (STRICT_ALIGNMENT && mode != BLKmode && align == GET_MODE_ALIGNMENT (mode)))) + #else + && (align == MEM_ALIGN0 (mode))) + #endif return 0;
attrs.alias = alias;
Regards,
Adriaan van Os
On 19 Dec 2004 at 3:01, Frank Heckenbach wrote:
I have uploaded a new beta version of GPC to http://www.gnu-pascal.de!
[...]
I have built it for Mingw on the gcc-3.3.5 sources. The patch for gcc- 3.3.4 seems okay but for one "rej" in emit-rtl.c (attached). It doesn't seem to have resulted in any obvious problem, but then I wouldn't really know - so I am attaching the rej file in case there is something serious there.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
*************** *** 301,309 **** if (alias == 0 && expr == 0 && offset == 0 && (size == 0 || (mode != BLKmode && GET_MODE_SIZE (mode) == INTVAL (size))) && (align == BITS_PER_UNIT || (STRICT_ALIGNMENT && mode != BLKmode && align == GET_MODE_ALIGNMENT (mode)))) return 0;
attrs.alias = alias; --- 301,313 ---- if (alias == 0 && expr == 0 && offset == 0 && (size == 0 || (mode != BLKmode && GET_MODE_SIZE (mode) == INTVAL (size))) + #ifndef GPC && (align == BITS_PER_UNIT || (STRICT_ALIGNMENT && mode != BLKmode && align == GET_MODE_ALIGNMENT (mode)))) + #else + && (align == MEM_ALIGN0 (mode))) + #endif return 0;
attrs.alias = alias;
Prof A Olowofoyeku (The African Chief) wrote:
I have built it for Mingw on the gcc-3.3.5 sources. The patch for gcc- 3.3.4 seems okay but for one "rej" in emit-rtl.c (attached). It doesn't seem to have resulted in any obvious problem, but then I wouldn't really know - so I am attaching the rej file in case there is something serious there.
Sorry if I'm dumb, but what's the status of gcc-3.3.5 anyway?
http://www.gnu.org/software/gcc/ says it was released 2004-09-30, but points to a page that only mentions 3.3.4 (and older).
ftp://ftp.gnu.org/gnu/gcc/ also doesn't contain 3.3.5 (that's AFAICS -- I remember that 3.3.3 was "hidden" in a subdirectory `releases' for whatever reasons, but I've looked there as well and no 3.3.5).
Therefore I had assumed (and maybe still do ...? ;-) that 3.3.5 wasn't quite finished yet, so I didn't include a patch for it. However, the 3.3.4 patch without that rejected hunk should probably work fine.
Frank
Frank Heckenbach wrote:
Sorry if I'm dumb, but what's the status of gcc-3.3.5 anyway?
http://www.gnu.org/software/gcc/ says it was released 2004-09-30, but points to a page that only mentions 3.3.4 (and older).
ftp://ftp.gnu.org/gnu/gcc/ also doesn't contain 3.3.5 (that's AFAICS -- I remember that 3.3.3 was "hidden" in a subdirectory `releases' for whatever reasons, but I've looked there as well and no 3.3.5).
Therefore I had assumed (and maybe still do ...? ;-) that 3.3.5 wasn't quite finished yet, so I didn't include a patch for it. However, the 3.3.4 patch without that rejected hunk should probably work fine.
That is "known problem" with 3.3.5. It seems that poeple having permission to update web pages forgot to do it.
I have checked that the hunk is rejected because eqivalent patch is already applied.
Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
I have built it for Mingw on the gcc-3.3.5 sources. The patch for gcc- 3.3.4 seems okay but for one "rej" in emit-rtl.c (attached). It doesn't seem to have resulted in any obvious problem, but then I wouldn't really know - so I am attaching the rej file in case there is something serious there.
Sorry if I'm dumb, but what's the status of gcc-3.3.5 anyway?
I found it here: ftp://ftp.mirrorservice.org/sites/sources.redhat.com/pub/gcc/releases/gc c-3.3.5/
[...]
However, the 3.3.4 patch without that rejected hunk should probably work fine.
The compiler that I have built (Mingw) passes the gpc testsuite, and also passes my own tests. Great work!
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Hello
I now have the situation where I can build gpc based on any number of gcc versions. I have, until now, used gcc-3.2.3 for Mingw binary releases, but I have now ascertained that the latest betas also work perfectly fine with gcc-3.3.3 and gcc-3.3.5. The question now is - is there any reason (other than convenience, etc.) for using one gcc version rather than another? Should I keep using gcc-3.2.3 or move to gcc-3.3.5? Choosing one rather than the other does not seem to make any difference to the robustness of the gpc compiler or the code generated by it.
Thanks.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.greatchief.plus.com/
"Prof. A Olowofoyeku (The African Chief)" wrote:
I now have the situation where I can build gpc based on any number of gcc versions. I have, until now, used gcc-3.2.3 for Mingw binary releases, but I have now ascertained that the latest betas also work perfectly fine with gcc-3.3.3 and gcc-3.3.5. The question now is - is there any reason (other than convenience, etc.) for using one gcc version rather than another? Should I keep using gcc-3.2.3 or move to gcc-3.3.5? Choosing one rather than the other does not seem to make any difference to the robustness of the gpc compiler or the code generated by it.
IMO all those binaries should be available. I am inhibited from upgrading my DJGPP installation gcc / gdb versions because there is no corresponding gpc version.
On 20 Dec 2004 at 6:17, CBFalconer wrote:
"Prof. A Olowofoyeku (The African Chief)" wrote:
I now have the situation where I can build gpc based on any number of gcc versions. I have, until now, used gcc-3.2.3 for Mingw binary releases, but I have now ascertained that the latest betas also work perfectly fine with gcc-3.3.3 and gcc-3.3.5. The question now is - is there any reason (other than convenience, etc.) for using one gcc version rather than another? Should I keep using gcc-3.2.3 or move to gcc-3.3.5? Choosing one rather than the other does not seem to make any difference to the robustness of the gpc compiler or the code generated by it.
IMO all those binaries should be available.
This would mean building several different versions of the same GPC compiler, based on different gcc backends. This would be a tedious exercise to say the least.
I am inhibited from upgrading my DJGPP installation gcc / gdb versions because there is no corresponding gpc version.
Wouldn't this always be the case until gpc is integrated into gcc? AFAICS, gpc is currently restricted to gcc-3.x backends and doesn't generall support gcc-3.4.x.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.greatchief.plus.com/
Prof. A Olowofoyeku (The African Chief) wrote:
AFAICS, gpc is currently restricted to gcc-3.x backends and doesn't generall support gcc-3.4.x.
ATM gpc does not support coming gcc-4.0. I am in the process of updating 3.4 patch to gpc-20041218 (it is in "works for me" state).
Waldek Hebisch wrote:
Prof. A Olowofoyeku (The African Chief) wrote:
AFAICS, gpc is currently restricted to gcc-3.x backends and doesn't generall support gcc-3.4.x.
ATM gpc does not support coming gcc-4.0. I am in the process of updating 3.4 patch to gpc-20041218 (it is in "works for me" state).
The updated gcc-3.4 patch is really good news (I read it after sending my previous email).
Regards,
Adriaan van Os
Prof. A Olowofoyeku (The African Chief) wrote:
I now have the situation where I can build gpc based on any number of gcc versions. I have, until now, used gcc-3.2.3 for Mingw binary releases, but I have now ascertained that the latest betas also work perfectly fine with gcc-3.3.3 and gcc-3.3.5. The question now is - is there any reason (other than convenience, etc.) for using one gcc version rather than another? Should I keep using gcc-3.2.3 or move to gcc-3.3.5? Choosing one rather than the other does not seem to make any difference to the robustness of the gpc compiler or the code generated by it.
Except for the problem with system conditionals (which is worked around while building GPC itself and running the test suite, and when compiling with GP or using `--print-needed-options' manually, but may still fail otherwise with GPC based on gcc-3.3.x).
Frank
I have uploaded a new beta version of GPC to http://www.gnu-pascal.de!
The main changes are fixes for 64 bit platforms that were partly broken with 20041017 (some tests still fail on these platforms, but these are mostly problems with the tests themselves), and slightly improved compatibility to Mac Pascal dialects.
I would really like to update the sources and binaries for Mac OS X, based on this version, but there are two issues that have refrained me (so far) from doing so:
* inaccurate line numbers in debug info (see http://www.gnu-pascal.de/crystal/gpc/en/mail10675.html). This worked with gpc version-20030830.
* building with gcc-3.4. Waldek's patches for gcc-3.4.0 worked well with gpc version 20030830. Are patches planned for gpc-20041218 ? On Mac OS X, we have little choice but to follow the latest changes in gcc, as they reflect the changes in a fast evolving OS - Apple is doing quite a lot of work in the gcc team.
Regards,
Adriaan van Os
Adriaan van Os wrote:
- inaccurate line numbers in debug info (see
http://www.gnu-pascal.de/crystal/gpc/en/mail10675.html). This worked with gpc version-20030830.
Unfortunately, line numbers are still generally inaccurate. There may have been some temporary improvement that broke by other changes, but it's a bit of luck now. I'll have to really fix this sometime ...
Frank
Hello
I have released Mingw (MS Windows) binaries for gpc-20041218. The release is based on gcc-3.2.3. You can get a copy here: http://www.gnu-pascal.de/contrib/chief/win32/mingw32/
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Hello
I have built gpc-20041218 for AMD-64 (Fedora Core 2). Attached is the result of the testsuite. Is it worth releasing these binaries?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.
---- File information ----------- File: amd64.log Date: 23 Dec 2004, 15:03 Size: 1619 bytes. Type: Unknown
Prof A Olowofoyeku (The African Chief) wrote:
Hello
I have built gpc-20041218 for AMD-64 (Fedora Core 2). Attached is the result of the testsuite. Is it worth releasing these binaries?
The main problems (that gpc-20041017 had) is fixed now. The thest failures come form three sources:
1) bit-packed arrays do not work 2) the compiler sometimes can not detect overflow in constant expressions 3) some tests make assumptions that are not longer valid with 64-bit Integer.
Problems 1) and 2) were present in gpc-20040526. 3) gives bad impression, but is only a minor problem. So the result is no worse then AMD gpc-20040526.
On the other hand, 1) work in 3.4 (and the 3.4 patch also fixes packed arrays with 3.3). I am still testing 3.4 patch (mostly for installation problems). I will be out of town for Christmas, so I will release the patch probably in the next year.
On 23 Dec 2004 at 17:21, Waldek Hebisch wrote:
Prof A Olowofoyeku (The African Chief) wrote:
Hello
I have built gpc-20041218 for AMD-64 (Fedora Core 2). Attached is the result of the testsuite. Is it worth releasing these binaries?
The main problems (that gpc-20041017 had) is fixed now. The thest failures come form three sources:
- bit-packed arrays do not work
- the compiler sometimes can not detect overflow in constant
expressions 3) some tests make assumptions that are not longer valid with 64-bit Integer.
Problems 1) and 2) were present in gpc-20040526. 3) gives bad impression, but is only a minor problem. So the result is no worse then AMD gpc-20040526.
On the other hand, 1) work in 3.4 (and the 3.4 patch also fixes packed arrays with 3.3). I am still testing 3.4 patch (mostly for installation problems). I will be out of town for Christmas, so I will release the patch probably in the next year.
I think I'll wait until the 3.4 patch then (or better still, until when it becomes merged with the main GPC).
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
-
Adriaan van Os -
CBFalconer -
Frank Heckenbach -
Frank Heckenbach -
Prof A Olowofoyeku (The African Chief) -
Prof. A Olowofoyeku (The African Chief)
-
Waldek Hebisch