I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
You will hate this release ... at least if you make heavy use of external declarations or other directives. We all knew that some backward-incompatible changes in this area would have to be made, now that's happened. PLEASE READ THE NOTES BELOW FOR DETAILS.
Changes that affect building GPC: =================================
- Dwarf2 debug info (the default under Linux and many other systems with gcc-3) finally works. This means you can now build GPC with gcc-3 without `-g0' or `-gstabs'.
- Building GPC no more requires gperf (those who maintain build dependencies please note this).
- Besides the source distributions as before, there is now also a "minimal" distribution. This is compressed with bzip2 instead of gzip and does not contain any generated files. These files will be generated automatically when building GPC, but you need some additional tools installed:
bzip2, bash, *GNU* sed, GNU awk, GNU m4, bison, flex, autoconf, help2man, makeinfo (at least version 4.1).
Other changes: ==============
- Forward referencing pointers generate proper debug info now.
- Discriminant identifiers are allowed as variant record selectors.
- `export Foo = all (...)' (fjf811*.pas)
- Delphi-compatible `initialization', `finalization' (chief43*.pas)
- Type-casts are BP compatible now, in particular, value type-casts between ordinal and real or complex types don't work anymore.
- All non-ISO-7185 keywords can be used as identifiers (with two small exceptions). (fjf440.pas)
- `pack-struct' does not imply bit-level packing anymore (only explicit `packed' records and arrays do).
- New options `--[no-]ignore-packed' (`--ignore-packed' is the default in BP mode). (fjf796*.pas)
- New option `--maximum-field-alignment=N'
- `{$[no-]pack-struct}' as a compiler directive
- New options `-W[no-]local-external' (implied by `-Wall')
- New options `--vax-pascal', `--mac-pascal'
- Mac Pascal directives `definec', `macro', `undefc', `ifc', `ifoptc', `elsec', `elifc', `endc', `errorc'
- Units without `implementation' part
- When passing a schema variable as an untyped argument, the whole schema, including the discriminants is passed. (fjf798.pas)
- `TimeZone' in `TimeStamp' counts seconds *east* of UTC now (not west, as before). (datetimedemo.pas)
- Some bug fixes related to operator overloading.
- Variables declared in interfaces of modules are now initialized (capacity of strings etc.). (daj3.pas, sven14c.pas, nick1.pas)
- Various other bug fixes.
Directives and attributes: ==========================
- `external name' works (BP compatible). So
procedure Foo; external; asmname 'bar';
or (equivalent previously)
procedure Foo; asmname 'bar';
can be changed to
procedure Foo; external name 'bar';
GPC also accepts
procedure Foo; external 'libname' name 'bar';
but ignores 'libname'. It could be supported via automake, but since automake is to be replaced by gp, anyway, it seems pointless to do it now.
- `name' works as an attribute.
- `attribute's with single parameters can be written with `=', so
attribute (name ('foo'))
and
attribute (name = 'foo')
are equivalent.
- Linker names (whether by `external name' or as an `attribute') can be string constant expressions now (e.g., involving declared string constants and `+'). The same applies to module/unit file names specified with `in'.
- `asmname' is deprecated (and will be dropped in a future version).
* External `asmname' constructions can be changed as shown above.
* In a unit interface, change
procedure Foo; asmname 'bar';
to
procedure Foo; external name 'bar';
*if* the routine is really external (e.g. implemented in a C file or library); otherwise to
procedure Foo; attribute (name = 'bar');
(previously, GPC didn't care, but now you have to distinguish these cases).
- `external' without an asmname (whether by `external name' or as an `attribute') defaults to all-lowercase linker names now. GPC will give a warning now (because of the change). This warning will disappear in the future (but the change will remain in effect, of course).
Routines without `external' or asmname still use first-uppercase linker names, for those who care. But it's not recommended to rely on this.
So change
procedure Foo; external;
to
procedure Foo; external name 'Foo';
(or change the corresponding C code to `foo' if that's under your control).
- All of the above applies to variables as well.
- `c', `c_language' are also deprecated. Instead of
procedure Foo; c;
or
procedure Foo; c_language;
write
procedure Foo; external;
(if you don't mind the warning for now), or
procedure Foo; external name 'foo';
(if you prefer to make the linker name more explicit).
- `static', `volatile' and `register' for variables are no prefix directives anymore, but attributes. E.g.
var Foo: static Integer;
becomes
var Foo: Integer; attribute (static);
- Same for `inline' with routines.
inline procedure Foo;
becomes
procedure Foo; attribute (inline);
- A new attribute `const' for variables (really read-only -- unlike BP's "typed constants", and also applicable to external variables).
- `attribute' for routines doesn't imply `forward' anymore, so you don't have to declare routines twice in a program or implementation part when setting the linker name or some other attribute. E.g.
procedure Foo; attribute (noreturn); { forward; -- ignored here before } procedure Foo; begin Halt end;
becomes:
procedure Foo; attribute (noreturn); begin Halt end;
A final example:
procedure Foo; asmname 'bar'; attribute (noreturn); procedure Foo; begin Halt end;
becomes:
procedure Foo; attribute (noreturn, name = 'bar'); begin Halt end;
Frank
Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
It builds on Mac OS X. Testsuite results are as expected (known back-end issues) except that fjf581f.pas writes 'OO' to stdout.
TEST fjf781f.pas: OO
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
It builds on Mac OS X. Testsuite results are as expected (known back-end issues)
That's only the nonlocal goto bug (if you apply the backend patches), or anything else?
I've had the idea that this can maybe be worked-around by using longjmp (as is done for nonlocal gotos into the main program which work AFAIR). I haven't dealt with label internals much, so I don't know how difficult this will be, but I may look into it when I get to it ...
except that fjf581f.pas writes 'OO' to stdout.
TEST fjf781f.pas: OO
Hmm, the test program may be wrong. Try this one.
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
It builds on Mac OS X. Testsuite results are as expected (known back-end issues)
That's only the nonlocal goto bug (if you apply the backend patches), or anything else?
fjf558m.pas Bus error non-local goto bug (gcc) fjf558n.pas Bus error non-local goto bug (gcc) fjf558o.pas Bus error non-local goto bug (gcc) fjf558p.pas Bus error non-local goto bug (gcc) fjf582.pas Segmentation fault stack overflow (solved with "limit stacksize 2048") fjf664.pas Segmentation fault stack overflow (solved with "limit stacksize 2048") fproc.pas Segmentation fault non-local goto bug (gcc) goto5.pas Bus error non-local goto bug (gcc) nlgpp.pas Bus error non-local goto bug (gcc) nlgpp2.pas Bus error non-local goto bug (gcc) systemtest.pas malloc error malloc bug
I assume, the malloc bug will get fixed in some future release of Mac OS X.
I've had the idea that this can maybe be worked-around by using longjmp (as is done for nonlocal gotos into the main program which work AFAIR). I haven't dealt with label internals much, so I don't know how difficult this will be, but I may look into it when I get to it ...
Are non-local goto's used in C ? If not, do the gcc guys accept Pascal or RTL programs in bug reports ? Is there something like an RTL interpreter, for debugging and to isolate back-end from front-end bugs ?
except that fjf581f.pas writes 'OO' to stdout.
TEST fjf781f.pas: OO
Hmm, the test program may be wrong. Try this one.
It now passes the testsuite.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
It builds on Mac OS X. Testsuite results are as expected (known back-end issues)
That's only the nonlocal goto bug (if you apply the backend patches), or anything else?
fjf582.pas Segmentation fault stack overflow (solved with "limit stacksize 2048")
Still? I thought I'd avoided this by using subroutines, but apparently inlining spoiled this attempt. Try adding:
{ FLAG --no-inline-functions }
fjf664.pas Segmentation fault stack overflow (solved with "limit stacksize 2048")
Try this one.
I've had the idea that this can maybe be worked-around by using longjmp (as is done for nonlocal gotos into the main program which work AFAIR). I haven't dealt with label internals much, so I don't know how difficult this will be, but I may look into it when I get to it ...
Are non-local goto's used in C ?
In GCC, yes (standard C doesn't have nested functions, so the issue doesn't arise).
I think this is the test program I wrote when a similar problem was found on Solaris with gcc-2.95. You can try if it fails in your situation, too.
I may have reported it to the GCC people back then. I don't remember exactly and I don't feel like looking it up in my old mail. It doesn't really matter since they've ignored all my bug reports so far, anyway.
extern int puts (const char *); extern void abort (void);
int main (void) { __label__ l1;
void foo (void) {
void bar (void) { puts ("goto l1"); goto l1; }
bar (); }
foo (); abort (); l1: puts ("label l1"); return 0; }
If not, do the gcc guys accept Pascal or RTL programs in bug reports ?
I guess not.
Is there something like an RTL interpreter, for debugging and to isolate back-end from front-end bugs ?
Not AFAIK.
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
fjf582.pas Segmentation fault stack overflow (solved with "limit stacksize 2048")
Still? I thought I'd avoided this by using subroutines, but apparently inlining spoiled this attempt. Try adding:
{ FLAG --no-inline-functions }
TEST fjf582.orig.pas: ./test_run: line 202: 2647 Segmentation fault ./"$A_OUT" "$1" TEST fjf582.pas: ./test_run: line 202: 2774 Segmentation fault ./"$A_OUT" "$1"
The backtraces look like this:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbff7f9b0
Thread 0 Crashed: #0 0x00002650 in Testproc32 (fjf582.orig.pas:98) #1 0x00002650 in Testproc32 (fjf582.orig.pas:98) #2 0x00002fbc in main (fjf582.orig.pas:105) #3 0x00001f44 in _start (crt.c:267) #4 0x00001dc4 in start
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbff7f9d0
Thread 0 Crashed: #0 0x00002be4 in Testproc32 (fjf582.pas:101) #1 0x00003e40 in pascal_main_program (fjf582.pas:106) #2 0x00003fbc in main (fjf582.pas:108) #3 0x000019f4 in _start (crt.c:267) #4 0x00001874 in start
fjf664.pas Segmentation fault stack overflow (solved with "limit stacksize 2048")
Try this one.
TEST fjf664.pas: gpc: Internal error: Illegal instruction (program gpc1) TEST fjf664.orig.pas: gpc: Internal error: Illegal instruction (program gpc1)
Both produce a gpc internal error (not a Segmentation fault as I reported earlier, I apologize).
For fjf664.pas the backtrace looks like this:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbff7ffd0
Thread 0 Crashed: #0 0x000c4300 in reset_used_flags (emit-rtl.c:2639) #1 0x000c4458 in reset_used_flags (emit-rtl.c:2687) #2 0x000c4458 in reset_used_flags (emit-rtl.c:2687) #3 0x000c4458 in reset_used_flags (emit-rtl.c:2687) #4 0x000c4458 in reset_used_flags (emit-rtl.c:2687) <last line repeats> ....
For fjf664.orig.pas the backtrace looks like this:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbff7ffd0
Thread 0 Crashed: #0 0x000c4300 in reset_used_flags (emit-rtl.c:2639) #1 0x000c4458 in reset_used_flags (emit-rtl.c:2687) #2 0x000c4458 in reset_used_flags (emit-rtl.c:2687) #3 0x000c4458 in reset_used_flags (emit-rtl.c:2687) <last line repeats> .....
Regards,
Adriaan van Os
For fjf664.pas the backtrace looks like this:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbff7ffd0
Thread 0 Crashed: #0 0x000c4300 in reset_used_flags (emit-rtl.c:2639) #1 0x000c4458 in reset_used_flags (emit-rtl.c:2687) #2 0x000c4458 in reset_used_flags (emit-rtl.c:2687) #3 0x000c4458 in reset_used_flags (emit-rtl.c:2687) #4 0x000c4458 in reset_used_flags (emit-rtl.c:2687)
<last line repeats> ....
That was the wrong one. Here is the correct backtrace for fjf664.pas:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbff7ffc0
Thread 0 Crashed: #0 0x000d04b0 in ggc_alloc (ggc-page.c:858) #1 0x000e5ffc in rtx_alloc (rtl.c:334) #2 0x000c4248 in copy_rtx_if_shared (emit-rtl.c:2593) #3 0x000c41c8 in copy_rtx_if_shared (emit-rtl.c:2613) #4 0x000c41c8 in copy_rtx_if_shared (emit-rtl.c:2613) #5 0x000c41c8 in copy_rtx_if_shared (emit-rtl.c:2613) #6 0x000c41c8 in copy_rtx_if_shared (emit-rtl.c:2613) <last line repeats> ......
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
fjf582.pas Segmentation fault stack overflow (solved with "limit stacksize 2048")
Still? I thought I'd avoided this by using subroutines, but apparently inlining spoiled this attempt. Try adding:
{ FLAG --no-inline-functions }
TEST fjf582.orig.pas: ./test_run: line 202: 2647 Segmentation fault ./"$A_OUT" "$1" TEST fjf582.pas: ./test_run: line 202: 2774 Segmentation fault ./"$A_OUT" "$1"
The backtraces look like this:
I see, a single array is too big already. Well, perhaps we should just declare types instead of variables, to leave the stack alone. It's a rather silly issue, anyway.
--- p/test/fjf582.pas.orig Thu Mar 27 18:35:06 2003 +++ p/test/fjf582.pas Thu Mar 27 18:35:32 2003 @@ -16,11 +16,11 @@ can't make it a `for' loop counter or so. So we use a macro here. } {$define PREPARETEST(n) procedure TestProc##n; +type i = packed array [1 .. $8000] of Integer (n); +type c = packed array [1 .. $8000] of Cardinal (n); +type w = packed array [1 .. $8000] of Word (n); +type b = packed array [1 .. $8000] of Boolean (n); begin - var i: packed array [1 .. $8000] of Integer (n); - var c: packed array [1 .. $8000] of Cardinal (n); - var w: packed array [1 .. $8000] of Word (n); - var b: packed array [1 .. $8000] of Boolean (n); Check (SizeOf (i), $1000 * n, 'i', n); Check (SizeOf (c), $1000 * n, 'c', n); Check (SizeOf (w), $1000 * n, 'w', n);
fjf664.pas Segmentation fault stack overflow (solved with "limit stacksize 2048")
Try this one.
TEST fjf664.pas: gpc: Internal error: Illegal instruction (program gpc1) TEST fjf664.orig.pas: gpc: Internal error: Illegal instruction (program gpc1)
Both produce a gpc internal error (not a Segmentation fault as I reported earlier, I apologize).
For fjf664.pas the backtrace looks like this: That was the wrong one. Here is the correct backtrace for fjf664.pas:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbff7ffc0
Thread 0 Crashed: #0 0x000d04b0 in ggc_alloc (ggc-page.c:858) #1 0x000e5ffc in rtx_alloc (rtl.c:334) #2 0x000c4248 in copy_rtx_if_shared (emit-rtl.c:2593) #3 0x000c41c8 in copy_rtx_if_shared (emit-rtl.c:2613) #4 0x000c41c8 in copy_rtx_if_shared (emit-rtl.c:2613) #5 0x000c41c8 in copy_rtx_if_shared (emit-rtl.c:2613) #6 0x000c41c8 in copy_rtx_if_shared (emit-rtl.c:2613)
<last line repeats> ......
Just to be sure, this is also fixed with a bigger stack size? So it's the compiler's stack that overruns this time (in contrast to fjf582 where it was the compiled program's stack).
In this case, the test may just be too big (for the default stack size), and all I could do is to split it up.
Does it make any difference if you remove some of the procedures t1, t2, t3, t4 or some of the lines in the CN macro?
Frank
Frank Heckenbach wrote:
I see, a single array is too big already. Well, perhaps we should just declare types instead of variables, to leave the stack alone. It's a rather silly issue, anyway.
--- p/test/fjf582.pas.orig Thu Mar 27 18:35:06 2003 +++ p/test/fjf582.pas Thu Mar 27 18:35:32 2003 @@ -16,11 +16,11 @@ can't make it a `for' loop counter or so. So we use a macro here. } {$define PREPARETEST(n) procedure TestProc##n; +type i = packed array [1 .. $8000] of Integer (n); +type c = packed array [1 .. $8000] of Cardinal (n); +type w = packed array [1 .. $8000] of Word (n); +type b = packed array [1 .. $8000] of Boolean (n); begin
- var i: packed array [1 .. $8000] of Integer (n);
- var c: packed array [1 .. $8000] of Cardinal (n);
- var w: packed array [1 .. $8000] of Word (n);
- var b: packed array [1 .. $8000] of Boolean (n); Check (SizeOf (i), $1000 * n, 'i', n); Check (SizeOf (c), $1000 * n, 'c', n); Check (SizeOf (w), $1000 * n, 'w', n);
OK, the fjf582.pas test is passed now (with the standard Mac OS X stacksize limit of 512 K).
fjf664.pas Segmentation fault stack overflow (solved with "limit stacksize 2048")
Try this one.
TEST fjf664.pas: gpc: Internal error: Illegal instruction (program gpc1) TEST fjf664.orig.pas: gpc: Internal error: Illegal instruction (program gpc1)
Both produce a gpc internal error (not a Segmentation fault as I reported earlier, I apologize).
Just to be sure, this is also fixed with a bigger stack size? So it's the compiler's stack that overruns this time (in contrast to fjf582 where it was the compiled program's stack).
Yes, limit stacksize 2048 fixes it for the original fjf664.pas, limit stacksize 1024 for the later fjf664.pas.
In this case, the test may just be too big (for the default stack size), and all I could do is to split it up.
Does it make any difference if you remove some of the procedures t1, t2, t3, t4
No, each of t1, t2, t3, t4 alone crashes the compiler.
or some of the lines in the CN macro?
With only these two lines left in the CN macro, the crash has gone, e.g.
{$define CN(NK, MK) CM (NK, MK, 1, 1); CM (NK, MK, 5, 4) }
Regards,
Adriaan van Os
Adriaan van Os wrote:
In this case, the test may just be too big (for the default stack size), and all I could do is to split it up.
Does it make any difference if you remove some of the procedures t1, t2, t3, t4
No, each of t1, t2, t3, t4 alone crashes the compiler.
or some of the lines in the CN macro?
With only these two lines left in the CN macro, the crash has gone, e.g.
{$define CN(NK, MK) CM (NK, MK, 1, 1); CM (NK, MK, 5, 4) }
OK, so subroutines seem to help. Try this.
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
In this case, the test may just be too big (for the default stack size), and all I could do is to split it up.
Does it make any difference if you remove some of the procedures t1, t2, t3, t4
No, each of t1, t2, t3, t4 alone crashes the compiler.
or some of the lines in the CN macro?
With only these two lines left in the CN macro, the crash has gone, e.g.
{$define CN(NK, MK) CM (NK, MK, 1, 1); CM (NK, MK, 5, 4) }
OK, so subroutines seem to help. Try this.
The fjf664.pas test is passed now (with the standard Mac OS X stacksize limit of 512 K).
Thanks,
Adriaan van Os
Frank Heckenbach wrote:
Adriaan van Os wrote:
It builds on Mac OS X. Testsuite results are as expected (known back-end issues)
That's only the nonlocal goto bug (if you apply the backend patches), or anything else?
<snip>
I may have reported it to the GCC people back then. I don't remember exactly and I don't feel like looking it up in my old mail. It doesn't really matter since they've ignored all my bug reports so far, anyway.
extern int puts (const char *); extern void abort (void);
int main (void) { __label__ l1;
void foo (void) {
void bar (void) { puts ("goto l1"); goto l1; } bar ();}
foo (); abort (); l1: puts ("label l1"); return 0; }
Good news ! I forwarded it to the gcc-bugs@gcc.gnu.org mailing list and got the following reply:
Geoff Keating wrote:
Adriaan van Os writes:
Does anyone know what the status is of the following problems, encountered with gcc-3.2.1/3.2.2 on Darwin/Mac OS X ?
(1) trampolines crash (I have a patch to fix it)
(2) longjumps crash (I have a patch to fix it also)
(3) non-local goto's don't work, e.g.
These are all fixed in GCC 3.3.
(4) compiling any .c source with -ggdb or -gdwarf-2 (instead of -gstabs or -g) produces the following output: Internal compiler error in default_no_named_section, at varasm.c:5305
Darwin doesn't really support dwarf2 at present.
--
- Geoffrey Keating geoffk@geoffk.org
So, this gets solved when gcc-3.3 is released.
Regards,
Adriaan van Os
I wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
It builds on Mac OS X. Testsuite results are as expected (known back-end issues)
That's only the nonlocal goto bug (if you apply the backend patches), or anything else?
I've had the idea that this can maybe be worked-around by using longjmp (as is done for nonlocal gotos into the main program which work AFAIR). I haven't dealt with label internals much, so I don't know how difficult this will be, but I may look into it when I get to it ...
After some other changes I made, I found that this was rather easy to implement, and the next GPC version will support it with `--longjmp-all-nonlocal-labels'.
Even if it's fixed in gcc-3.3 on Mac OS, this might be useful. Who knows on which other platforms the bug may still exist or what other new bugs gcc-3.3 will bring ...
Frank
Frank Heckenbach a écrit:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
It has been compiled with gcc-2.95.3 and gcc-3.2.2 and uploaded at the usual places
http://gnu-pascal.de/contrib/maurice/gpc-20030323-gcc-2953.i586-pc-msdosdjgp...
http://gnu-pascal.de/contrib/maurice/gpc-20030323-gcc-322.i586-pc-msdosdjgpp...
As always the last gpc compiled are under the fixed symlinks
http://gnu-pascal.de/contrib/maurice/gpc2953b.zip
http://gnu-pascal.de/contrib/maurice/gpc322b.zip
gcc-3.2.1 is no more compiled.
The next to last version remains in this directory in case of problems. The 20030209 will probably remain more time than usual, to enable everybody to make the incompatible changes on his own programs.
When running the test suite
- no error with gcc-2.95.3
- Five errors with gc-3.2.2 and dwarf debugging (no EXTRA_TEST_PFLAGS)
TEST dialec3.pas: c:\djgpp\tmp/ccodgYIF.s: Assembler messages: c:\djgpp\tmp/ccodgYIF.s:176: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccodgYIF.s:326: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccodgYIF.s:422: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccodgYIF.s:639: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccodgYIF.s:715: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccodgYIF.s:788: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccodgYIF.s:861: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccodgYIF.s:934: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccodgYIF.s:996: Error: symbol `LFE0' is already defined gpc1.exe: c:/djgpp/b/gnu/build.gcc/gcc/xgpc.exe exited with status 1 failed TEST dialec5.pas: c:\djgpp\tmp/ccym5bKT.s: Assembler messages: c:\djgpp\tmp/ccym5bKT.s:176: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccym5bKT.s:326: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccym5bKT.s:422: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccym5bKT.s:639: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccym5bKT.s:715: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccym5bKT.s:788: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccym5bKT.s:861: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccym5bKT.s:934: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccym5bKT.s:996: Error: symbol `LFE0' is already defined gpc1.exe: c:/djgpp/b/gnu/build.gcc/gcc/xgpc.exe exited with status 1 failed TEST dialec6.pas: c:\djgpp\tmp/cc2WrsXc.s: Assembler messages: c:\djgpp\tmp/cc2WrsXc.s:176: Error: symbol `LFE0' is already defined c:\djgpp\tmp/cc2WrsXc.s:326: Error: symbol `LFE0' is already defined c:\djgpp\tmp/cc2WrsXc.s:422: Error: symbol `LFE0' is already defined c:\djgpp\tmp/cc2WrsXc.s:639: Error: symbol `LFE0' is already defined c:\djgpp\tmp/cc2WrsXc.s:715: Error: symbol `LFE0' is already defined c:\djgpp\tmp/cc2WrsXc.s:788: Error: symbol `LFE0' is already defined c:\djgpp\tmp/cc2WrsXc.s:861: Error: symbol `LFE0' is already defined c:\djgpp\tmp/cc2WrsXc.s:934: Error: symbol `LFE0' is already defined c:\djgpp\tmp/cc2WrsXc.s:996: Error: symbol `LFE0' is already defined gpc1.exe: c:/djgpp/b/gnu/build.gcc/gcc/xgpc.exe exited with status 1 failed TEST fjf165a.pas: SKIPPED: German locale not installed TEST longr2.pas: SKIPPED: no LongReal math routines available TEST windtes2.pas: c:\djgpp\tmp/cc6h6aLc.s: Assembler messages: c:\djgpp\tmp/cc6h6aLc.s:186: Error: symbol `LFE0' is already defined c:\djgpp\tmp/cc6h6aLc.s:336: Error: symbol `LFE0' is already defined c:\djgpp\tmp/cc6h6aLc.s:432: Error: symbol `LFE0' is already defined c:\djgpp\tmp/cc6h6aLc.s:643: Error: symbol `LFE0' is already defined c:\djgpp\tmp/cc6h6aLc.s:719: Error: symbol `LFE0' is already defined c:\djgpp\tmp/cc6h6aLc.s:792: Error: symbol `LFE0' is already defined c:\djgpp\tmp/cc6h6aLc.s:865: Error: symbol `LFE0' is already defined c:\djgpp\tmp/cc6h6aLc.s:938: Error: symbol `LFE0' is already defined c:\djgpp\tmp/cc6h6aLc.s:1006: Error: symbol `LFE0' is already defined gpc1.exe: c:/djgpp/b/gnu/build.gcc/gcc/xgpc.exe exited with status 1 failed TEST windtest.pas: c:\djgpp\tmp/ccO4SFg9.s: Assembler messages: c:\djgpp\tmp/ccO4SFg9.s:176: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:326: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:422: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:639: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:715: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:788: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:861: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:934: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:996: Error: symbol `LFE0' is already defined gpc1.exe: c:/djgpp/b/gnu/build.gcc/gcc/xgpc.exe exited with status 1 failed
# of GPC tests 3323 # of GPC tests passed 3316 # of GPC tests skipped 2 # of GPC tests failed 5
-They all disappear with EXTRA_TEST_PFLAGS=-gstabs
Maurice
Maurice Lombardi wrote:
- Five errors with gc-3.2.2 and dwarf debugging (no EXTRA_TEST_PFLAGS)
OK, that's all the same issue (most likely).
TEST windtest.pas: c:\djgpp\tmp/ccO4SFg9.s: Assembler messages: c:\djgpp\tmp/ccO4SFg9.s:176: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:326: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:422: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:639: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:715: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:788: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:861: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:934: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:996: Error: symbol `LFE0' is already defined gpc1.exe: c:/djgpp/b/gnu/build.gcc/gcc/xgpc.exe exited with status 1 failed
I don't get this error when cross-compiling from Linux to DJGPP with
i386-pc-msdosdjgpp-gpc --automake -O3 -gdwarf-2 windtest.pas
(I haven't cross-built a DJGPP hosted compiler yet, so I can't easily run the test suite directly).
Can you try to find out which unit (and which declaration in it) causes the error? Then perhaps send the assembler output. Do any options (e.g., inlining) have any influence?
Frank
Frank Heckenbach a écrit:
Maurice Lombardi wrote:
- Five errors with gc-3.2.2 and dwarf debugging (no EXTRA_TEST_PFLAGS)
OK, that's all the same issue (most likely).
TEST windtest.pas: c:\djgpp\tmp/ccO4SFg9.s: Assembler messages: c:\djgpp\tmp/ccO4SFg9.s:176: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:326: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:422: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:639: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:715: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:788: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:861: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:934: Error: symbol `LFE0' is already defined c:\djgpp\tmp/ccO4SFg9.s:996: Error: symbol `LFE0' is already defined gpc1.exe: c:/djgpp/b/gnu/build.gcc/gcc/xgpc.exe exited with status 1 failed
I don't get this error when cross-compiling from Linux to DJGPP with
i386-pc-msdosdjgpp-gpc --automake -O3 -gdwarf-2 windtest.pas
(I haven't cross-built a DJGPP hosted compiler yet, so I can't easily run the test suite directly).
Can you try to find out which unit (and which declaration in it) causes the error? Then perhaps send the assembler output. Do any options (e.g., inlining) have any influence?
Compiling with -v option I see that it is when assembling windos.pas. The listing assembly is attached, produced with
gpc -c -S -O3 -gdwarf-2 c:\djgpp\lib\gcc-lib\djgpp\3.22\units\windos.pas
LFEO: is indeed present at many places
Maurice
Maurice Lombardi wrote:
LFEO: is indeed present at many places
I see that the WinDos unit contains:
: {$ifdef DJGPP} : {$local W-} {$no-debug-info} {$endlocal} : {$endif}
Apparently this work-around is itself causing trouble with dwarf. (The issue is that the Dos and WinDos contain some routines of the same name, but with different implementations. COFF doesn't seem to like that.) Try this:
--- p/options.c.orig Wed Mar 26 09:44:12 2003 +++ p/options.c Wed Mar 26 09:44:14 2003 @@ -409,7 +409,8 @@ else if (OPT ("-fno-debug-info")) { warning ("`--no-debug-info' is a temporary work-around; it may disappear in the future"); - write_symbols = NO_DEBUG; + if (write_symbols == SDB_DEBUG) /* Not all debug formats like to be reset */ + write_symbols = NO_DEBUG; debug_info_level = DINFO_LEVEL_NONE; use_gnu_debug_info_extensions = 0; }
Frank
Frank Heckenbach a écrit:
Maurice Lombardi wrote:
LFEO: is indeed present at many places
I see that the WinDos unit contains:
: {$ifdef DJGPP} : {$local W-} {$no-debug-info} {$endlocal} : {$endif}
Apparently this work-around is itself causing trouble with dwarf. (The issue is that the Dos and WinDos contain some routines of the same name, but with different implementations. COFF doesn't seem to like that.) Try this:
--- p/options.c.orig Wed Mar 26 09:44:12 2003 +++ p/options.c Wed Mar 26 09:44:14 2003 @@ -409,7 +409,8 @@ else if (OPT ("-fno-debug-info")) { warning ("`--no-debug-info' is a temporary work-around; it may disappear in the future");
write_symbols = NO_DEBUG;
if (write_symbols == SDB_DEBUG) /* Not all debug formats like to be reset */write_symbols = NO_DEBUG; debug_info_level = DINFO_LEVEL_NONE; use_gnu_debug_info_extensions = 0;
OK. Everything is correct now !
TEST fjf165a.pas: SKIPPED: German locale not installed TEST longr2.pas: SKIPPED: no LongReal math routines available
# of GPC tests 3324 # of GPC tests passed 3322 # of GPC tests skipped 2 # of GPC tests failed 0
I have upgraded the binary on gnu-pascal
Maurice
Frank Heckenbach wrote:
- Dwarf2 debug info (the default under Linux and many other systems with gcc-3) finally works. This means you can now build GPC with gcc-3 without `-g0' or `-gstabs'.
Maurice Lombardi wrote:
- Five errors with gc-3.2.2 and dwarf debugging (no EXTRA_TEST_PFLAGS)
On Mac OS X, stabs debugging info is the default, but out of curiosity I tried the other formats:
-ggdb dummy.pas:0: Internal compiler error in default_no_named_section, at varasm.c:5305 -gdwarf gpc1: warning: `dwarf': unknown or unsupported -g option -gdwarf-1 gpc1: warning: `dwarf': unknown or unsupported -g option -gdwarf-2 dummy.pas:0: Internal compiler error in default_no_named_section, at varasm.c:5305 -gstabs OK -gstabs+ OK -gxcoff gpc1: warning: `dwarf': unknown or unsupported -g option -gxcoff+ gpc1: warning: `dwarf': unknown or unsupported -g option -gvms gpc1: warning: `dwarf': unknown or unsupported -g option -g OK -g1 OK -g2 OK -g3 OK
Regards,
Adriaan van Os
---------------------
G4:~/gnu/testgpc/test-20030323] adriaan% make EXTRA_TEST_PFLAGS=-ggdb
Testing gpc 20030323, based on gcc-3.2.1 (powerpc-apple-darwin6.3) (G4.local.) echo "gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused -ggdb" gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused -ggdb PC="gpc" PFLAGS="--autobuild -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused -ggdb" SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | "./test_sum" dummy.pas:0: Internal compiler error in default_no_named_section, at varasm.c:5305 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. ./test_run: fatal: cannot compile a simple program Nothing was run.
[G4:~/gnu/testgpc/test-20030323] adriaan% make EXTRA_TEST_PFLAGS=-gdwarf-2
Running the GPC Test Suite. This may take a while ...
Testing gpc 20030323, based on gcc-3.2.1 (powerpc-apple-darwin6.3) (G4.local.) echo "gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused -gdwarf-2" gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused -gdwarf-2 PC="gpc" PFLAGS="--autobuild -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused -gdwarf-2" SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | "./test_sum" dummy.pas:0: Internal compiler error in default_no_named_section, at varasm.c:5305 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. ./test_run: fatal: cannot compile a simple program Nothing was run.
Adriaan van Os wrote:
On Mac OS X, stabs debugging info is the default, but out of curiosity I tried the other formats:
-gdwarf-2 dummy.pas:0: Internal compiler error in default_no_named_section, at varasm.c:5305
[G4:~/gnu/testgpc/test-20030323] adriaan% make EXTRA_TEST_PFLAGS=-gdwarf-2
Running the GPC Test Suite. This may take a while ...
Testing gpc 20030323, based on gcc-3.2.1 (powerpc-apple-darwin6.3) (G4.local.) echo "gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused -gdwarf-2" gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused -gdwarf-2 PC="gpc" PFLAGS="--autobuild -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused -gdwarf-2" SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | "./test_sum" dummy.pas:0: Internal compiler error in default_no_named_section, at varasm.c:5305 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. ./test_run: fatal: cannot compile a simple program Nothing was run.
I'm not sure if dwarf2 is supported at all on this target (does it work in C?), or if I can do anything about it, but maybe you can provide a stack trace (in gdb, set a breakpoint, and when it gets there do `i s').
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
On Mac OS X, stabs debugging info is the default, but out of curiosity I tried the other formats:
-gdwarf-2 dummy.pas:0: Internal compiler error in default_no_named_section, at varasm.c:5305
I'm not sure if dwarf2 is supported at all on this target (does it work in C?), or if I can do anything about it, but maybe you can provide a stack trace (in gdb, set a breakpoint, and when it gets there do `i s').
The fsf-gcc-3.2.1 compiler produces precisely the same error on Mac OS X ! So, it must be a gcc problem, although the source code at varasm.c:5305 tries to suggest otherwise:
void default_no_named_section (name, flags) const char *name ATTRIBUTE_UNUSED; unsigned int flags ATTRIBUTE_UNUSED; { /* Some object formats don't support named sections at all. The front-end should already have flagged this as an error. */ abort (); }
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
On Mac OS X, stabs debugging info is the default, but out of curiosity I tried the other formats:
-gdwarf-2 dummy.pas:0: Internal compiler error in default_no_named_section, at varasm.c:5305
I'm not sure if dwarf2 is supported at all on this target (does it work in C?), or if I can do anything about it, but maybe you can provide a stack trace (in gdb, set a breakpoint, and when it gets there do `i s').
The fsf-gcc-3.2.1 compiler produces precisely the same error on Mac OS X ! So, it must be a gcc problem, although the source code at varasm.c:5305 tries to suggest otherwise:
void default_no_named_section (name, flags) const char *name ATTRIBUTE_UNUSED; unsigned int flags ATTRIBUTE_UNUSED; { /* Some object formats don't support named sections at all. The front-end should already have flagged this as an error. */ abort (); }
It is most likely a gcc problem, but as I said, a stack trace could perhaps tell me something about where it comes from.
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
On Mac OS X, stabs debugging info is the default, but out of curiosity I tried the other formats:
-gdwarf-2 dummy.pas:0: Internal compiler error in default_no_named_section, at varasm.c:5305
I'm not sure if dwarf2 is supported at all on this target (does it work in C?), or if I can do anything about it, but maybe you can provide a stack trace (in gdb, set a breakpoint, and when it gets there do `i s').
The fsf-gcc-3.2.1 compiler produces precisely the same error on Mac OS X ! So, it must be a gcc problem, although the source code at varasm.c:5305 tries to suggest otherwise:
void default_no_named_section (name, flags) const char *name ATTRIBUTE_UNUSED; unsigned int flags ATTRIBUTE_UNUSED; { /* Some object formats don't support named sections at all. The front-end should already have flagged this as an error. */ abort (); }
It is most likely a gcc problem, but as I said, a stack trace could perhaps tell me something about where it comes from.
When running gcc ...
(gdb) backtrace #0 default_no_named_section (name=0x28fcd8 ".debug_abbrev", flags=1024) at ../../gpc-20030323/gcc/varasm.c:5305 #1 0x00042ee8 in named_section_flags (name=0x28fcd8 ".debug_abbrev", flags=1024) at ../../gpc-20030323/gcc/varasm.c:414 #2 0x001f2c48 in dwarf2out_init (main_input_filename=0x7eddf0 "callc.c") at ../../gpc-20030323/gcc/dwarf2out.c:12099 #3 0x0006d8d4 in lang_dependent_init (name=0x7eddf0 "callc.c") at ../../gpc-20030323/gcc/toplev.c:5136 #4 0x0006dae0 in do_compile () at ../../gpc-20030323/gcc/toplev.c:5217 #5 0x0006dbc0 in toplev_main (argc=3, argv=0x2adb30) at ../../gpc-20030323/gcc/toplev.c:5250 #6 0x000418f0 in main (argc=2686168, argv=0x400) at ../../gpc-20030323/gcc/main.c:35 #7 0x00002050 in _start (argc=3, argv=0xbffffd84, envp=0xbffffd94) at /SourceCache/Csu/Csu-45/crt.c:267 #8 0x00001ed0 in start ()
When running gpc ...
(gdb) backtrace #0 fancy_abort (file=0x28fe84 "../../gpc-20030323/gcc/varasm.c", line=5305, function=0x2909bc "default_no_named_section") at ../../gpc-20030323/gcc/diagnostic.c:1452 #1 0x000db524 in default_no_named_section (name=0x28fe84 "../../gpc-20030323/gcc/varasm.c", flags=5305) at ../../gpc-20030323/gcc/varasm.c:5305 #2 0x000d2bbc in named_section_flags (name=0x285d6c ".debug_abbrev", flags=1024) at ../../gpc-20030323/gcc/varasm.c:414 #3 0x00065710 in dwarf2out_init (main_input_filename=0x7d7378 "callc.c") at ../../gpc-20030323/gcc/dwarf2out.c:12099 #4 0x000aa0a4 in lang_dependent_init (name=0x7d7378 "callc.c") at ../../gpc-20030323/gcc/toplev.c:5136 #5 0x000aa2b0 in do_compile () at ../../gpc-20030323/gcc/toplev.c:5217 #6 0x000aa390 in toplev_main (argc=3, argv=0x2ba300) at ../../gpc-20030323/gcc/toplev.c:5250 #7 0x000b5ee8 in main (argc=2686596, argv=0x14b9) at ../../gpc-20030323/gcc/main.c:35 #8 0x00002380 in _start (argc=3, argv=0xbffffd84, envp=0xbffffd94) at /SourceCache/Csu/Csu-45/crt.c:267 #9 0x00002200 in start ()
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
On Mac OS X, stabs debugging info is the default, but out of curiosity I tried the other formats:
-gdwarf-2 dummy.pas:0: Internal compiler error in default_no_named_section, at varasm.c:5305
I'm not sure if dwarf2 is supported at all on this target (does it work in C?), or if I can do anything about it, but maybe you can provide a stack trace (in gdb, set a breakpoint, and when it gets there do `i s').
The fsf-gcc-3.2.1 compiler produces precisely the same error on Mac OS X ! So, it must be a gcc problem, although the source code at varasm.c:5305 tries to suggest otherwise:
void default_no_named_section (name, flags) const char *name ATTRIBUTE_UNUSED; unsigned int flags ATTRIBUTE_UNUSED; { /* Some object formats don't support named sections at all. The front-end should already have flagged this as an error. */ abort (); }
It is most likely a gcc problem, but as I said, a stack trace could perhaps tell me something about where it comes from.
When running gcc ...
(gdb) backtrace #0 default_no_named_section (name=0x28fcd8 ".debug_abbrev", flags=1024) at ../../gpc-20030323/gcc/varasm.c:5305
OK, as far as I understand it, dwarf2 debug info is stored in "named sections" in the assembler code (dwarf2out.c:3679). Some object formats support names sections, and some don't (default_no_named_section and the following 3 functions in varasm.c).
The Darwin backend claims to support dwarf2 (config/darwin.h:128), but doesn't set TARGET_ASM_NAMED_SECTION (either by omission, or correctly because its object format really doesn't support named sections).
So I think the error is in the Darwin backend. It should either set TARGET_ASM_NAMED_SECTION (if that's possible) or not set DWARF2_DEBUGGING_INFO.
Feel free to forward this mail to whomever it may concern.
Frank
Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
- New option `--maximum-field-alignment=N'
Also as a compiler directive $maximum-field-alignment=N.
It works great, for example the following data structure
type word8 = cardinal( 8); word16 = cardinal( 16); word32 = cardinal( 32); rec = record a, b, c: word8; d: word16; e: word32 end;
returns different sizes (in bytes) for different aligments (in bits):
N=0 size=12 N=32 size=12 N=16 size=10 N=8 size=9
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
- New option `--maximum-field-alignment=N'
Also as a compiler directive $maximum-field-alignment=N.
It works great, for example the following data structure
type word8 = cardinal( 8); word16 = cardinal( 16); word32 = cardinal( 32); rec = record a, b, c: word8; d: word16; e: word32 end;
returns different sizes (in bytes) for different aligments (in bits):
N=0 size=12 N=32 size=12 N=16 size=10 N=8 size=9
Huh? By my reckoning everything is fouled. N=32 should yield 20, n=16 --> 12, n=8 seems ok.
CBFalconer wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
- New option `--maximum-field-alignment=N'
Also as a compiler directive $maximum-field-alignment=N.
It works great, for example the following data structure
type word8 = cardinal( 8); word16 = cardinal( 16); word32 = cardinal( 32); rec = record a, b, c: word8; d: word16; e: word32 end;
returns different sizes (in bytes) for different aligments (in bits):
N=0 size=12 N=32 size=12 N=16 size=10 N=8 size=9
Huh? By my reckoning everything is fouled. N=32 should yield 20, n=16 --> 12, n=8 seems ok.
I haven't looked into the actual implementation, but if the directive just ties into the back-end's stor-layout.c maximum_field_alignment useage (as discussed a while back in the pack struct thread), then the size and field offsets obtained with $maximum-field-alignment=N depends upon the target configuration settings.
If I'm not mistaken, the some of the target dependencies are:
1. Natural integer size (e.g., 16, 32, 64, etc. bits)
2. Memory packing policies for various types and type sizes (e.g., are sub-integer size types packed into natural integer size memory chunks?)
3. Where does the next memory field start in natural integer size bit offset terms. (I believe this has to be within the bit range of the natural integer size. If it is outside the range it reverts to bit 0.)
The above three items are factored in when determining the actual memory offset used for each field. (Note: Floating point fields have additional considerations.)
For the PPC, Darwin, Mach-o target (i.e., gpc/gcc for Mac OS X) the natural integer size is 32 bits, sub-integer types are packed into natural integer sized memory chucks if the type doesn't spill across a natural integer size boundary, and by default the next memory non-packed field start is bit 0 ( in left to right ascending bit numbering scheme).
Using $maximum-field-alignment to change the default for item 3 (as I think it probably does) for the values of N listed should yield the record sizes Adriaan has reported for Mac OS X GPC.
For N=0 or 32 (which actually gets reverted to 0), the first three (8 bit) fields are packed into the first 32 bit memory chunk with 8 bits of padding since the next field is too large for the remaining bits and next field start setting is bit 0, the forth (16 bit) field is in the second 32 bit memory chunk with 16 bits of padding (next field too large etc.), and the last, remaining (32 bit) field is in the third and last 32 bit menory chunk.
For N=16, the too-large-fit next field starting bit offsets are 0 or 16 bits thus the 16 bit pad is eliminated. For N=8, the offsets are 0, 8, 16, and 24 bits thus both the 8 bit and 16 bit pads are eliminated.
Hopefully the above will help clarify the intend useage of the $maximum-field-alignment directive. It isn't used to specify the minimum size for each specific field in a record; rather, it is more of a padding and inter-machine-word field splitting control for combinations of multiple, varying sized fields.
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
CBFalconer wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
- New option `--maximum-field-alignment=N'
Also as a compiler directive $maximum-field-alignment=N.
I don't mention this usually since generally all GPC specific options work also as compiler directives.
It works great, for example the following data structure
type word8 = cardinal( 8); word16 = cardinal( 16); word32 = cardinal( 32); rec = record a, b, c: word8; d: word16; e: word32 end;
returns different sizes (in bytes) for different aligments (in bits):
N=0 size=12 N=32 size=12 N=16 size=10 N=8 size=9
Huh? By my reckoning everything is fouled. N=32 should yield 20, n=16 --> 12, n=8 seems ok.
I haven't looked into the actual implementation, but if the directive just ties into the back-end's stor-layout.c maximum_field_alignment useage (as discussed a while back in the pack struct thread), then the size and field offsets obtained with $maximum-field-alignment=N depends upon the target configuration settings.
If I'm not mistaken, the some of the target dependencies are:
- Natural integer size (e.g., 16, 32, 64, etc. bits)
(Which don't come into play in this example since the sizes are explicitly given.)
Hopefully the above will help clarify the intend useage of the $maximum-field-alignment directive. It isn't used to specify the minimum size for each specific field in a record; rather, it is more of a padding and inter-machine-word field splitting control for combinations of multiple, varying sized fields.
I think your explanation (and the numbers given by GPC) are correct. That's why it's called *maximum* field alignment. ;-) BTW, I get the same numbers on Linux/IA32, and I guess on many (but not necessarily all) other targets ...
Frank
Adriaan van Os wrote:
Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
- New option `--maximum-field-alignment=N'
Also as a compiler directive $maximum-field-alignment=N.
Is there an easy way to save and restore the maximum-field-alignment setting?
Something like other Mac Pascal dialect implementations' $PUSH and $POP compiler directives for a compiler directive variable setting save/restore stack would be desireable for Pascal interface translations of Apple's Mach-o Mac OS X C interfaces. (For Macho-o, some C interfaces have Mac68K alignment pragmas, some don't, and Apple makes use of the C pragma settings stack to keep the alignment setting straight across all interface combinations.)
It works great, for example the following data structure
How does it work for a mixture of alignments and with single (32 bit) and double (64 bit) floating point thrown into mixture?
Also, it would be a good idea to test more than just record sizes in a single code block. Things like actual field offsets and composite types with a mixture of alignments composed through uses clauses and import specifications should be part of the tests. In other words, stress tests to ensure there are no surprises/bugs in the implementation for all the various ways it might be used in general use.
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
Adriaan van Os wrote:
It works great, for example the following data structure
How does it work for a mixture of alignments and with single (32 bit) and double (64 bit) floating point thrown into mixture?
On Mac OS X, the maximum alignment seems to be 32-bits, not 64-bits. So the size in bytes of a "record a: single; b: double end;" on the platform is 12 bytes with any alignment.
Also, it would be a good idea to test more than just record sizes in a single code block. Things like actual field offsets and composite types with a mixture of alignments composed through uses clauses and import specifications should be part of the tests. In other words, stress tests to ensure there are no surprises/bugs in the implementation for all the various ways it might be used in general use.
Well, if you want to write the test programs (preferably useable on all platforms), they could be added to the gpc testsuite.
Regards,
Adriaan van Os
Gale Paeper wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
- New option `--maximum-field-alignment=N'
Also as a compiler directive $maximum-field-alignment=N.
Is there an easy way to save and restore the maximum-field-alignment setting?
Something like other Mac Pascal dialect implementations' $PUSH and $POP compiler directives for a compiler directive variable setting save/restore stack would be desireable for Pascal interface translations of Apple's Mach-o Mac OS X C interfaces.
GPC has `{$local}' and `{$endlocal}', but currently only for "Boolean" options. Perhaps I can make it work with field-alignment as well. (Currently it's handled in the preprocessor, so it's not so easy, but perhaps after the preprocessor is integrated into the compiler.)
It works great, for example the following data structure
How does it work for a mixture of alignments and with single (32 bit) and double (64 bit) floating point thrown into mixture?
Also, it would be a good idea to test more than just record sizes in a single code block. Things like actual field offsets and composite types with a mixture of alignments composed through uses clauses and import specifications should be part of the tests. In other words, stress tests to ensure there are no surprises/bugs in the implementation for all the various ways it might be used in general use.
Yes, this would be useful.
Frank
Gale Paeper wrote:
Also, it would be a good idea to test more than just record sizes in a single code block. Things like actual field offsets and composite types with a mixture of alignments composed through uses clauses and import specifications should be part of the tests. In other words, stress tests to ensure there are no surprises/bugs in the implementation for all the various ways it might be used in general use.
I ran the gpc testsuite, with the added option EXTRA_TEST_PFLAGS="--maximum-field-alignment=8". Below are the results, skipping the previously mentioned back-end problems.
Regards,
Adriaan van Os
--------
[G4:~/gnu/testgpc/test-20030323] adriaan% make EXTRA_TEST_PFLAGS="--maximum-field-alignment=8"
Running the GPC Test Suite. This may take a while ...
rm -f *.dat *.o *.s *.gpm *.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/*.gpm todo/*.gpi todo/*.gpd todo/core { gpc --version | head -1; gpc --print-search-dirs | grep install | head -1; hostname || echo "unknown host"; } | \ sed -e 's,^,Testing ,;N;s,\n.*gcc-lib[/], (,;s,[/].*,),;N;s,\n, (,;s,$,),' Testing gpc 20030323, based on gcc-3.2.1 (powerpc-apple-darwin6.3) (G4.local.) echo "gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused --maximum-field-alignment=8" gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused --maximum-field-alignment=8 PC="gpc" PFLAGS="--autobuild -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused --maximum-field-alignment=8" SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | "./test_sum"
TEST bill6.pas: ./test_run: line 202: 3134 Segmentation fault ./"$A_OUT" "$1"
TEST chief31.pas: gpc1: warnings being treated as errors ./chief31.pas:6: warning: too few initializers for array failed
TEST ciriaco1.pas: ./test_run: line 202: 6238 Segmentation fault ./"$A_OUT" "$1"
TEST files3.pas: ./test_run: line 202: 9394 Segmentation fault ./"$A_OUT" "$1"
TEST fjf193.pas: ./test_run: line 202: 11572 Segmentation fault ./"$A_OUT" "$1"
TEST fjf193b.pas: ./a.out: error when writing to file `a' bound to file handle #8 (Bad file descriptor) (error #466 at 1ebf)
TEST fjf294a.pas: gpc1: warnings being treated as errors ./fjf294a.pas:7: warning: too few initializers for array failed
TEST fjf528a.pas: gpc1: warnings being treated as errors ./fjf528a.pas:7: warning: too few initializers for array failed
TEST fjf528b.pas: gpc1: warnings being treated as errors ./fjf528b.pas:7: warning: too few initializers for array failed
TEST fjf589a.pas: gpc1: warnings being treated as errors ./fjf589a.pas: In main program: ./fjf589a.pas:46: warning: cast increases required alignment of target type ./fjf589a.pas:47: warning: cast increases required alignment of target type failed
TEST fjf638.pas: gpc1: warnings being treated as errors ./fjf638.pas:9: warning: too few initializers for array failed
TEST fjf670.pas: ./test_run: line 202: 9963 Segmentation fault ./"$A_OUT" "$1"
TEST fjf755.pas: ./a.out: error when reading from file `Foo' bound to file handle #6 (Bad file descriptor) (error #464 at 1def)
TEST formattimetest.pas: ./strftime.cmp: line 34: 17561 Segmentation fault ./"$A_OUT"
TEST getopt1.pas: 1c1,14 < ./getopt1.run: line 3: 17711 Segmentation fault ./"$A_OUT" --optarg -r foo -x -o -nobar --noarg --reqarg foo --optarg=bar --abc baz qux ---
long option `optarg' option `r' with argument `foo' dummy: unrecognized option `-x' (incorrect long option) option `o' option `n' option `o' with argument `bar' long option `noarg' long option `reqarg' with argument `foo' long option `optarg' with argument `bar' option `x' Remaining arguments: baz qux
failed
TEST getopt2.pas: 1c1,13 < ./getopt2.run: line 3: 17738 Segmentation fault ./"$A_OUT" --optarg -r foo -x -o -nobar --noarg --reqarg foo --optarg=bar --abc baz qux ---
long option `optarg' option `r' with argument `foo' option `x' option `o' option `n' option `o' with argument `bar' long option `noarg' long option `reqarg' with argument `foo' long option `optarg' with argument `bar' option `x' Remaining arguments: baz qux
failed
TEST getopt3.pas: 1c1,13 < ./getopt3.run: line 3: 17765 Segmentation fault ./"$A_OUT" --optarg -r foo -x -o -nobar --noarg --reqarg foo --optarg=bar --abc baz qux ---
option `o' option `r' with argument `foo' option `x' option `o' option `n' option `o' with argument `bar' option `n' option `r' with argument `foo' option `o' with argument `bar' option `x' Remaining arguments: baz qux
failed
TEST gpctest.pas: warning: strange time zone 24.00 -1 86400 943841988 True True 0 1999 131006464 11 720896 29 1835008 1 0 2 131072 19 1245184 48 3145728 0 Error in UnixTimeToTimeStamp
TEST kevin10.pas: ./test_run: line 202: 19221 Segmentation fault ./"$A_OUT" "$1"
TEST kevin11.pas: ./test_run: line 202: 19241 Segmentation fault ./"$A_OUT" "$1"
TEST kevin12.pas: ./test_run: line 202: 19261 Segmentation fault ./"$A_OUT" "$1"
TEST pat4.pas: gpc1: warnings being treated as errors ./pat4.pas:17: warning: too few initializers for array failed
TEST pipetes2.pas: gpc1: warnings being treated as errors ./pipetes2.pas:15: warning: too few initializers for array failed
TEST pipetest.pas: gpc1: warnings being treated as errors ./pipetest.pas:15: warning: too few initializers for array failed
TEST russell1.pas: ./a.out: error when writing to file `MyFile' bound to file handle #8 (Bad file descriptor) (error #466 at 28e3)
TEST schema2a.pas: failed
TEST size.pas: gpc1: warnings being treated as errors ./size.pas:14: warning: too few initializers for array failed
TEST strindex.pas: gpc1: warnings being treated as errors ./strindex.pas:6: warning: too few initializers for array failed
TEST sven4.pas: gpc1: warnings being treated as errors ./sven4.pas:15: warning: too few initializers for array failed
TEST y2k.pas: failed 537067520 4178575360
# of GPC tests 3324 # of GPC tests passed 3268 # of GPC tests skipped 15 # of GPC tests failed 41
-------
I can provide more information, as needed. Many, but not all, backtraces look like this:
Thread 0 Crashed: #0 0x00005064 in _p_Bind (file.c:404) #1 0x00001cd8 in init_Bill6ubar (bill6u.pas:11) #2 0x00001f44 in init_pascal_main_program (bill6.pas:16) #3 0x00001fb0 in main (bill6.pas:16) #4 0x00001b0c in _start (crt.c:267) #5 0x0000198c in start
-------
Adriaan van Os wrote:
Gale Paeper wrote:
Also, it would be a good idea to test more than just record sizes in a single code block. Things like actual field offsets and composite types with a mixture of alignments composed through uses clauses and import specifications should be part of the tests. In other words, stress tests to ensure there are no surprises/bugs in the implementation for all the various ways it might be used in general use.
I ran the gpc testsuite, with the added option EXTRA_TEST_PFLAGS="--maximum-field-alignment=8".
Interesting idea, but you can't actually expect it to work. The option affects all structures, including those used in the RTS and defined in gpc.pas or built-in. This includes the internal file structure which seems to be responsible for most of the failures.
I expected the option to be used for specific declarations (system interfaces etc.). Of course, this means that the command-line option is not really a good idea (for now).
To solve this, we could deactivate the option while defining the bulit-in structures (in the compiler), and while compiling gpc.pas (by putting a `0' compiler directive in it -- you might want to try this, this might fix some of the failures, but probably not msot of them since the file structure is built-in).
Still, there will be problems if (a) some regular unit is compiled with this option and its users not or vice versa, (b) some ("non-system") C interface unit is compiled with it, (c) code that relies on specific alignment is compiled with it. This might not be too many problems, but might still be some failures when running the test suite with `--maximum-field-alignment=8'.
Still I wonder if the command-line option is actually useful, and if we shouldn't drop it and only allow it as a compiler directive.
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
I ran the gpc testsuite, with the added option EXTRA_TEST_PFLAGS="--maximum-field-alignment=8".
Interesting idea, but you can't actually expect it to work. The option affects all structures, including those used in the RTS and defined in gpc.pas or built-in. This includes the internal file structure which seems to be responsible for most of the failures.
I expected the option to be used for specific declarations (system interfaces etc.). Of course, this means that the command-line option is not really a good idea (for now).
To solve this, we could deactivate the option while defining the bulit-in structures (in the compiler), and while compiling gpc.pas (by putting a `0' compiler directive in it -- you might want to try this, this might fix some of the failures, but probably not msot of them since the file structure is built-in).
Still, there will be problems if (a) some regular unit is compiled with this option and its users not or vice versa, (b) some ("non-system") C interface unit is compiled with it, (c) code that relies on specific alignment is compiled with it. This might not be too many problems, but might still be some failures when running the test suite with `--maximum-field-alignment=8'.
Still I wonder if the command-line option is actually useful, and if we shouldn't drop it and only allow it as a compiler directive.
Running the testsuite with EXTRA_TEST_PFLAGS="--pack-struct" causes similar problems .... Dropping both --maximum-field-alignment and --pack-struct as command-line options is a solution (and I don't object if they are dropped) but my personal preference is in keeping them and adding compiler directives to compiler-internal and runtime-library data structures.
Regards,
Adriaan van Os
Frank Heckenbach wrote:
Adriaan van Os wrote:
I ran the gpc testsuite, with the added option EXTRA_TEST_PFLAGS="--maximum-field-alignment=8".
<snip>
Still I wonder if the command-line option is actually useful, and if we shouldn't drop it and only allow it as a compiler directive.
Running the testsuite with EXTRA_TEST_PFLAGS="--pack-struct" causes similar problems .... Dropping both --maximum-field-alignment and --pack-struct as command-line options is a solution (and I don't object if they are dropped) but my personal preference is in keeping them and adding compiler directives to compiler-internal and runtime-library data structures.
I recall how we defined BP compatibility ....
You migth say that it allows compilation of some BP (and maybe other dialect) programs which do use packed fields as `var' parameters (non-standard, since BP ignores `packed' completely). But it wouldn't work in general. A general solution to *this* problem would be a new option `ignore-packed' which is also easy to implement. Then BP compatibility would use `--pack-struct --ignore-packed'. :-)
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
I ran the gpc testsuite, with the added option EXTRA_TEST_PFLAGS="--maximum-field-alignment=8".
Interesting idea, but you can't actually expect it to work. The option affects all structures, including those used in the RTS and defined in gpc.pas or built-in. This includes the internal file structure which seems to be responsible for most of the failures.
I expected the option to be used for specific declarations (system interfaces etc.). Of course, this means that the command-line option is not really a good idea (for now).
To solve this, we could deactivate the option while defining the bulit-in structures (in the compiler), and while compiling gpc.pas (by putting a `0' compiler directive in it -- you might want to try this, this might fix some of the failures, but probably not msot of them since the file structure is built-in).
Still, there will be problems if (a) some regular unit is compiled with this option and its users not or vice versa, (b) some ("non-system") C interface unit is compiled with it, (c) code that relies on specific alignment is compiled with it. This might not be too many problems, but might still be some failures when running the test suite with `--maximum-field-alignment=8'.
Still I wonder if the command-line option is actually useful, and if we shouldn't drop it and only allow it as a compiler directive.
Running the testsuite with EXTRA_TEST_PFLAGS="--pack-struct" causes similar problems .... Dropping both --maximum-field-alignment and --pack-struct as command-line options is a solution (and I don't object if they are dropped) but my personal preference is in keeping them and adding compiler directives to compiler-internal and runtime-library data structures.
I recall how we defined BP compatibility ....
Right. I'm doing this now, so in the next release the test suite should work with these options.
Frank
Hi Frank
I still can't run the testsuite under Mingw. I get this output:
"Running the GPC Test Suite. This may take a while ...
rm -f *.dat *.o *.s *.gpm *.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/*.gpm todo/*.gpi todo/*.gpd todo/core { gpc --version | head -1; gpc --print-search-dirs | grep install | head -1; hostname || echo "unknown host"; date "+%Y-%m-%d %H:%M:%S"; } | \ sed -e 's,^,Testing ,;N;s,\n.*gcc-lib[/], (,;s,[/].*,),;N;s,\n, (,;s,$,),;N;s/\n/, /' Testing gpc.exe 20030323, based on gcc-3.2.2 (mingw special 20030208-1) (mingw32), 2003-03-25 21:02:57 echo "gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused " gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused PC="gpc" PFLAGS="--autobuild -g -O3 -W -Wall -Wundef -Wpointer-arith - Wno-unused " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" *.pas | tee test_log | "./test_sum" | tee test_summary ./test_run: fatal: `--print-needed-options' yields: ./test_run: /mingw/bin/gpc: Invalid argument Nothing was run."
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
Hi Frank
I still can't run the testsuite under Mingw. I get this output:
"Running the GPC Test Suite. This may take a while ...
rm -f *.dat *.o *.s *.gpm *.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/*.gpm todo/*.gpi todo/*.gpd todo/core { gpc --version | head -1; gpc --print-search-dirs | grep install | head -1; hostname || echo "unknown host"; date "+%Y-%m-%d %H:%M:%S"; } | \ sed -e 's,^,Testing ,;N;s,\n.*gcc-lib[/], (,;s,[/].*,),;N;s,\n, (,;s,$,),;N;s/\n/, /' Testing gpc.exe 20030323, based on gcc-3.2.2 (mingw special 20030208-1) (mingw32), 2003-03-25 21:02:57 echo "gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused " gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused PC="gpc" PFLAGS="--autobuild -g -O3 -W -Wall -Wundef -Wpointer-arith - Wno-unused " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" *.pas | tee test_log | "./test_sum" | tee test_summary ./test_run: fatal: `--print-needed-options' yields: ./test_run: /mingw/bin/gpc: Invalid argument Nothing was run."
Looks like an installation problem. What happens if you insert
echo "$PC $PFLAGS --print-needed-options dummy.pas" >&2
in test_run before the needed-options stuff, and execute the command that is shown manually (or from bash)? Is /mingw/bin/gpc the GPC executable?
Frank
On 23 Mar 2003 at 20:54, Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
You will hate this release ... at least if you make heavy use of external declarations or other directives. We all knew that some backward-incompatible changes in this area would have to be made, now that's happened. PLEASE READ THE NOTES BELOW FOR DETAILS.
[...]
The compiler builds okay, under Mingw (no errors or anything like that). But there are problems - the testsuite won't run at all (and many trivial programs won't compile). I have just started investigating this. The first thing that comes up is the new syntax for asmname and stuff.
For example, in system.pas, this code: "procedure GlobalMemoryStatus (var Buffer: TMemoryStatus); attribute (stdcall, name = 'GlobalMemoryStatus');"
produces this result; c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/units/system.pas: In procedure `GlobalMemoryStatus': c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/units/system.pas:791: parse error before `to' c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/units/system.pas:328: unresolved forward declaration `DefaultAssertErrorProc' c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/units/system.pas:326: unresolved forward declaration `Assert' c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/units/system.pas:323: unresolved forward declaration `DoubleToComp' c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/units/system.pas:322: unresolved forward declaration `CompToDouble' c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/units/system.pas:321: unresolved forward declaration `MaxAvail' c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/units/system.pas:317: unresolved forward declaration `MemAvail' gpc1.exe: gpc exited with status 1
Now, if I change the code to: "procedure GlobalMemoryStatus (var Buffer: TMemoryStatus); external name 'GlobalMemoryStatus'; attribute (stdcall);"
or: "procedure GlobalMemoryStatus (var Buffer: TMemoryStatus); attribute (stdcall, name = 'GlobalMemoryStatus');external;"
the problem disappears. The important word here is "external". But the error message generated when it is missing seems misleading.
In dos.pas, the code: "{$define WINAPI(X) external name = X; attribute (stdcall)}"
produces this result: c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/units/dos.pas:697: parse error before `=' c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/units/dos.pas:152: unresolved forward declaration `SetVerify' c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/units/dos.pas:151: unresolved forward declaration `GetVerify' c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/units/dos.pas:150: unresolved forward declaration `SetCBreak' c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/units/dos.pas:146: unresolved forward declaration `GetCBreak' gpc1.exe: gpc exited with status 1
If I change it to: "{$define WINAPI(X) external name X; attribute (stdcall)}"
the problem goes away. So, the problem here is with the construct "external name = foo". If you remove the "=" and change it to "external name foo" then there is no problem.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
For example, in system.pas, this code: "procedure GlobalMemoryStatus (var Buffer: TMemoryStatus); attribute (stdcall, name = 'GlobalMemoryStatus');"
produces this result; c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/units/system.pas: In procedure `GlobalMemoryStatus': c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/units/system.pas:791: parse error before `to'
Now, if I change the code to: "procedure GlobalMemoryStatus (var Buffer: TMemoryStatus); external name 'GlobalMemoryStatus'; attribute (stdcall);"
or: "procedure GlobalMemoryStatus (var Buffer: TMemoryStatus); attribute (stdcall, name = 'GlobalMemoryStatus');external;"
the problem disappears. The important word here is "external".
You're right. (I couldn't test this case, obviously, and since previously external and non-external weren't properly distinguished, such confusions were to be expected.)
But the error message generated when it is missing seems misleading.
Not at all. The code defines a regular procedure which has some local subroutines `MemAvail' etc., and where the `begin' of the procedure should follow, `to begin do' is found. Up to this point, the source is valid (though not as intended, but the compiler can't guess that).
In dos.pas, the code: "{$define WINAPI(X) external name = X; attribute (stdcall)}"
produces this result: c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/units/dos.pas:697: parse error before `='
If I change it to: "{$define WINAPI(X) external name X; attribute (stdcall)}"
the problem goes away. So, the problem here is with the construct "external name = foo". If you remove the "=" and change it to "external name foo" then there is no problem.
Right.
Frank
Frank Heckenbach wrote:
GPC also accepts
procedure Foo; external 'libname' name 'bar';but ignores 'libname'. It could be supported via automake, but since automake is to be replaced by gp, anyway, it seems pointless to do it now.
The 'libname' is also useful in supporting 'two-level namespaces', where external references record the names of symbols expected to be found in a library along with the library name. This provides an elegant solution for the situation where symbols with the same name are present in different libraries, either at link-time or at run-time.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
GPC also accepts
procedure Foo; external 'libname' name 'bar';but ignores 'libname'. It could be supported via automake, but since automake is to be replaced by gp, anyway, it seems pointless to do it now.
The 'libname' is also useful in supporting 'two-level namespaces', where external references record the names of symbols expected to be found in a library along with the library name. This provides an elegant solution for the situation where symbols with the same name are present in different libraries, either at link-time or at run-time.
If you know a way to achieve it, just go ahead. You might need to hack the linker, though ...
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
GPC also accepts
procedure Foo; external 'libname' name 'bar';but ignores 'libname'. It could be supported via automake, but since automake is to be replaced by gp, anyway, it seems pointless to do it now.
The 'libname' is also useful in supporting 'two-level namespaces', where external references record the names of symbols expected to be found in a library along with the library name. This provides an elegant solution for the situation where symbols with the same name are present in different libraries, either at link-time or at run-time.
If you know a way to achieve it, just go ahead. You might need to hack the linker, though ...
There is no need to hack the linker, as the Mac OS X runtime environment and its "ld" linker explicitely support 'two-level namespaces'. What I don't know, but will study, is how this relates to the compiler front-end.
Regards,
Adriaan van Os
Hi Frank
Trying to compile some object oriented code that compiles without problem under all previous versions of GPC (and Delphi, FreePascal and Virtual Pascal) produces this result:
"d:/src/gcc-3.2.2/gcc/p/objects.c:438:finish_object_type: failed assertion `method' cdialogs.pas:381: Internal compiler error. Please submit a full bug report to the GPC mailing list gpc@gnu.de. See URL:http://www.gnu-pascal.de/todo.html for details. gpc1.exe: gpc exited with status 1 gpc1.exe: gpc exited with status 1"
It is impossible to reduce the code that caused this to a small program - but this is the relevant part of "cdialogs.pas": TYPE pMemo = ^TMemo; MemoStrings = ^TMemoStrings; TMemoStrings = OBJECT ( TStrings ) Memo : pMemo; CONSTRUCTOR Create ( Owner : pMemo ); DESTRUCTOR Done; VIRTUAL; FUNCTION LoadFromFile ( CONST FName : String ) : Longint; VIRTUAL; END; { <--- this is line 381 }
TMemo = OBJECT ( TEdit ) Buffer : pChar; BufferHandle : hGlobal; .... ....
There is no reason that I can see why this code should cause the compiler to crash - but perhaps something has changed in the OOP handling parts of the compiler ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
Trying to compile some object oriented code that compiles without problem under all previous versions of GPC (and Delphi, FreePascal and Virtual Pascal) produces this result:
"d:/src/gcc-3.2.2/gcc/p/objects.c:438:finish_object_type: failed assertion `method' cdialogs.pas:381: Internal compiler error. Please submit a full bug report to the GPC mailing list gpc@gnu.de. See URL:http://www.gnu-pascal.de/todo.html for details. gpc1.exe: gpc exited with status 1 gpc1.exe: gpc exited with status 1"
It is impossible to reduce the code that caused this to a small program
Never say impossible ...
program Chief44;
uses Chief44u;
type TMemoStrings = abstract object (TStrings) end;
begin WriteLn ('OK') end.
unit Chief44u;
interface
type TStrings = abstract object procedure foo; abstract; end;
implementation
end.
--- p/gpc-decl.c.orig Tue Mar 25 13:33:12 2003 +++ p/gpc-decl.c Wed Mar 26 08:48:09 2003 @@ -2696,12 +2696,9 @@ PASCAL_STRUCTOR_METHOD (d) = PASCAL_STRUCTOR_METHOD (heading); PASCAL_OPERATOR_FUNCTION (d) = PASCAL_OPERATOR_FUNCTION (heading); DECL_LANG_OPERATOR_DECL (d) = operator_decl; - if (context != 6) - { - handle_autoexport (name); - if (operator_decl) - handle_autoexport (DECL_NAME (operator_decl)); - } + handle_autoexport (name); + if (operator_decl) + handle_autoexport (DECL_NAME (operator_decl)); }
return d;
There is no reason that I can see why this code should cause the compiler to crash - but perhaps something has changed in the OOP handling parts of the compiler ...
Well, many things have changed in (almost) all parts of the compiler ... ;-)
Frank
Is there any way to combine .o files together to form a single object file that can still be linked in?
The reason I'd like this is that the Mac interfaces are made up of about 350 units, and each of them produce a .o file containing the init code (even though there is no implementation section). As far as I'm aware, there is no way to make GPC not produce the implementation code or not call it. I thought that if I called it like:
gpc -I/Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces -funit-path=/Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces --automake -o testrecord testrecord.pas
it would automatically include all the necessary units, but apparently not (did this change, I think it worked before but I might have compiled it slightly differently).
I obviously can't add /Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces/*.o to the end because the command line would be way longer than allowed.
So the best I can think of is to combine all the .o files in /Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces/*.o into a macos.o object file that could be included.
Does anyone know how to do that or does anyone have any better idea?
One alternative is to change from unit "uses" to include files (which the Mac interfaces support anyway for reasons I've never understood), and just make a single really really big unit including all the interfaces. However that would be quite large and I don't know how happy GPC will be with a single unit with 300,000 lines in it, or how slow it will be for users to use it once the .gpi has been created.
I'll try some experiments, but if anyone has any suggestions, I'm all ears.
Thanks, Peter.
Peter N Lewis wrote:
Is there any way to combine .o files together to form a single object file that can still be linked in?
There are several ways to combine .o files into static libraries. Examples of such libraries are the gpc (libgpc.a) and gcc (libgcc.a) runtime libraries. See (1) page 22-23 of MachORuntime.pdf and (2) "man ld".
The reason I'd like this is that the Mac interfaces are made up of about 350 units, and each of them produce a .o file containing the init code (even though there is no implementation section).
The init code worries me also (see the thread about smart-linking). It would be interesting to know if the initialisation code does anything essential in an interfacing unit that only declares types, functions and procedures and that has no objects, no variables, no implementation section, etcetera.
Regards,
Adriaan van Os
Adriaan van Os wrote:
The init code worries me also (see the thread about smart-linking). It would be interesting to know if the initialisation code does anything essential in an interfacing unit that only declares types, functions and procedures and that has no objects, no variables, no implementation section, etcetera.
If there are also no imported units (whose initializers it would call) or finalization (which the initializer would install), it does in fact not do anythign serious.
Frank
On 26 Mar 2003 at 17:20, Peter N Lewis wrote:
Is there any way to combine .o files together to form a single object file that can still be linked in?
Perhaps you should try putting them into a ".a" library archive (e.g., libmac.a), and then you can link the library with "-l". This is more or less what GPC does with libgpc.a. Others can tell you more about the mechanics of this.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/
Peter N Lewis wrote:
Is there any way to combine .o files together to form a single object file that can still be linked in?
The reason I'd like this is that the Mac interfaces are made up of about 350 units, and each of them produce a .o file containing the init code (even though there is no implementation section). As far as I'm aware, there is no way to make GPC not produce the implementation code or not call it. I thought that if I called it like:
gpc -I/Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces -funit-path=/Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces --automake -o testrecord testrecord.pas
it would automatically include all the necessary units, but apparently not (did this change, I think it worked before but I might have compiled it slightly differently).
This should work. Since you don't say what happens, I can't tell more.
I obviously can't add /Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces/*.o to the end because the command line would be way longer than allowed.
This might be a reason why the above doesn't work since it's also passed on the command-line.
One alternative is to change from unit "uses" to include files (which the Mac interfaces support anyway for reasons I've never understood), and just make a single really really big unit including all the interfaces. However that would be quite large and I don't know how happy GPC will be with a single unit with 300,000 lines in it, or how slow it will be for users to use it once the .gpi has been created.
300000 lines sounds very much. It's more than on my Linux system the total of all headers of the system, X11 various libraries etc.
I don't know what all this stuff is, but if it includes all those things, it might be useful (also for the user) to split it according to functionality ("real" system, GUI, etc.) and make it one or a few units each.
This doesn't mean that GPC will necessarily fail on such a large unit (I haven't tried this, except for pathetic cases). If there are no O(n^2) cases anymore, it might work, but it might take a lot of memory ...
Frank
gpc -I/Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces -funit-path=/Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces --automake -o testrecord testrecord.pas
it would automatically include all the necessary units, but apparently not (did this change, I think it worked before but I might have compiled it slightly differently).
This should work. Since you don't say what happens, I can't tell more.
/usr/local/bin/ld: Undefined symbols: _init_Adsp _init_Aedatamodel _init_Aehelpers _init_Aeinteraction _init_Aemach _init_Aeobjects _init_Aepackobject _init_Aeregistry ... collect2: ld returned 1 exit status make: *** [testrecord] Error 1
One alternative is to change from unit "uses" to include files (which the Mac interfaces support anyway for reasons I've never understood), and just make a single really really big unit including all the interfaces. However that would be quite large and I don't know how happy GPC will be with a single unit with 300,000 lines in it, or how slow it will be for users to use it once the .gpi has been created.
300000 lines sounds very much. It's more than on my Linux system the total of all headers of the system, X11 various libraries etc.
There's a lot of stuff in there. And probably a fair amount of it is comments (a little hard for wc -l to tell me that though ;)
This doesn't mean that GPC will necessarily fail on such a large unit (I haven't tried this, except for pathetic cases). If there are no O(n^2) cases anymore, it might work, but it might take a lot of memory ...
Ok, well, I have a couple options to try anyway, I'll try various of them out and see what works, but if you have an idea why the compile above fails, that'd be handy.
Thanks, Peter.
Peter N Lewis wrote:
gpc -I/Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces -funit-path=/Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces --automake -o testrecord testrecord.pas
it would automatically include all the necessary units, but apparently not (did this change, I think it worked before but I might have compiled it slightly differently).
This should work. Since you don't say what happens, I can't tell more.
/usr/local/bin/ld: Undefined symbols: _init_Adsp _init_Aedatamodel _init_Aehelpers _init_Aeinteraction _init_Aemach _init_Aeobjects _init_Aepackobject _init_Aeregistry ... collect2: ld returned 1 exit status make: *** [testrecord] Error 1
I need more information (e.g., the output of a `-v' run -- if it's very long, send it privately, or put it on the web and send an URL).
One guess though: Since the names seems to be alphabetically ordered and start with `Ad', it might in fact be a truncation due to command line length limits. In this case, reducing the number of units might be the only recurse.
Frank
At 23:10 +0100 26/3/03, Frank Heckenbach wrote:
Peter N Lewis wrote:
gpc -I/Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces -funit-path=/Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces --automake -o testrecord testrecord.pas
it would automatically include all the necessary units, but apparently not (did this change, I think it worked before but I might have compiled it slightly differently).
This should work. Since you don't say what happens, I can't tell more.
/usr/local/bin/ld: Undefined symbols: _init_Adsp _init_Aedatamodel _init_Aehelpers
I figured it out:
- Units without `implementation' part
I have removed the implementation keyword after seeing that comment in the release notes (since they are all interfaces and have no implementation and the keyword is not needed on the Mac in this case). But it appears if this is removed, then the init routine is not included in the .o file even though it appears still to be needed when you import the file:
With no implementation keyword:
% gpc -c -I. ConditionalMacros.pas % hdump.pl <conditionalmacros.o 000000: FE ED FA CE 00 00 00 12 00 00 00 00 00 00 00 01 ................ 000010: 00 00 00 01 00 00 00 7C 00 00 00 00 00 00 00 01 .......|........ 000020: 00 00 00 7C 00 00 00 00 00 00 00 00 00 00 00 00 ...|............ 000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 98 ................ 000040: 00 00 00 00 00 00 00 07 00 00 00 07 00 00 00 01 ................ 000050: 00 00 00 00 5F 5F 74 65 78 74 00 00 00 00 00 00 ....__text...... 000060: 00 00 00 00 5F 5F 54 45 58 54 00 00 00 00 00 00 ....__TEXT...... 000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 98 ................ 000080: 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00 ................ 000090: 00 00 00 00 00 00 00 00 ........
After adding the implementation keyword: % gpc -c -I. ConditionalMacros.pas % hdump.pl < conditionalmacros.o 000000: FE ED FA CE 00 00 00 12 00 00 00 00 00 00 00 01 ................ 000010: 00 00 00 03 00 00 01 F4 00 00 00 00 00 00 00 01 ................ 000020: 00 00 01 8C 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000030: 00 00 00 00 00 00 00 00 00 00 00 AC 00 00 02 10 ................ 000040: 00 00 00 AC 00 00 00 07 00 00 00 07 00 00 00 05 ................ 000050: 00 00 00 00 5F 5F 74 65 78 74 00 00 00 00 00 00 ....__text...... 000060: 00 00 00 00 5F 5F 54 45 58 54 00 00 00 00 00 00 ....__TEXT...... 000070: 00 00 00 00 00 00 00 00 00 00 00 7C 00 00 02 10 ...........|.... 000080: 00 00 00 02 00 00 02 BC 00 00 00 0D 80 00 04 00 ................ 000090: 00 00 00 00 00 00 00 00 5F 5F 64 61 74 61 00 00 ........__data.. 0000A0: 00 00 00 00 00 00 00 00 5F 5F 44 41 54 41 00 00 ........__DATA.. 0000B0: 00 00 00 00 00 00 00 00 00 00 00 7C 00 00 00 01 ...........|.... 0000C0: 00 00 02 8C 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000D0: 00 00 00 00 00 00 00 00 00 00 00 00 5F 5F 70 69 ............__pi 0000E0: 63 73 79 6D 62 6F 6C 5F 73 74 75 62 5F 5F 54 45 csymbol_stub__TE 0000F0: 58 54 00 00 00 00 00 00 00 00 00 00 00 00 00 80 XT.............. 000100: 00 00 00 24 00 00 02 90 00 00 00 02 00 00 03 24 ...$...........$ 000110: 00 00 00 06 80 00 04 08 00 00 00 00 00 00 00 24 ...............$ 000120: 5F 5F 6C 61 5F 73 79 6D 62 6F 6C 5F 70 74 72 00 __la_symbol_ptr. 000130: 5F 5F 44 41 54 41 00 00 00 00 00 00 00 00 00 00 __DATA.......... 000140: 00 00 00 A4 00 00 00 04 00 00 02 B4 00 00 00 02 ................ 000150: 00 00 03 54 00 00 00 01 00 00 00 07 00 00 00 01 ...T............ 000160: 00 00 00 00 5F 5F 6E 6C 5F 73 79 6D 62 6F 6C 5F ....__nl_symbol_ 000170: 70 74 72 00 5F 5F 44 41 54 41 00 00 00 00 00 00 ptr.__DATA...... 000180: 00 00 00 00 00 00 00 A8 00 00 00 04 00 00 02 B8 ................ 000190: 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 06 ................ 0001A0: 00 00 00 02 00 00 00 00 00 00 00 02 00 00 00 18 ................ 0001B0: 00 00 03 68 00 00 00 05 00 00 03 A4 00 00 00 74 ...h...........t 0001C0: 00 00 00 0B 00 00 00 50 00 00 00 00 00 00 00 01 .......P........ 0001D0: 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 02 ................ 0001E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0001F0: 00 00 00 00 00 00 00 00 00 00 03 5C 00 00 00 03 ............... 000200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000210: 7C 08 02 A6 BF C1 FF F8 90 01 00 08 94 21 FF B0 |............!.. 000220: 7C 3E 0B 78 42 9F 00 05 7F E8 02 A6 3D 3F 00 00 |>.xB.......=?.. 000230: 39 29 00 64 88 09 00 00 54 00 06 3E 2C 00 00 00 9).d....T..>,... 000240: 41 82 00 20 3D 3F 00 00 39 29 00 64 38 00 00 00 A.. =?..9).d8... 000250: 98 09 00 00 3D 3F 00 00 80 69 00 90 48 00 00 35 ....=?...i..H..5 000260: 80 21 00 00 80 01 00 08 7C 08 03 A6 BB C1 FF F8 .!......|....... 000270: 4E 80 00 20 BF C1 FF F8 94 21 FF D0 7C 3E 0B 78 N.. .....!..|>.x 000280: 80 21 00 00 BB C1 FF F8 4E 80 00 20 01 00 00 00 .!......N.. .... 000290: 7C 08 02 A6 42 9F 00 05 7D 68 02 A6 3D 6B 00 00 |...B...}h..=k.. 0002A0: 7C 08 03 A6 81 8B 00 1C 7D 89 03 A6 39 6B 00 1C |.......}...9k.. 0002B0: 4E 80 04 20 00 00 00 00 00 00 00 00 00 00 00 4C N.. ...........L 0002C0: 00 00 03 C3 AB 00 00 48 00 00 00 A8 A1 00 00 00 .......H........ 0002D0: 00 00 00 18 AC 00 00 44 00 00 00 A8 A1 00 00 90 .......D........ 0002E0: 00 00 00 18 AB 00 00 38 00 00 00 7C A1 00 00 00 .......8...|.... 0002F0: 00 00 00 18 AC 00 00 34 00 00 00 7C A1 00 00 64 .......4...|...d 000300: 00 00 00 18 AB 00 00 20 00 00 00 7C A1 00 00 00 ....... ...|.... 000310: 00 00 00 18 AC 00 00 1C 00 00 00 7C A1 00 00 64 ...........|...d 000320: 00 00 00 18 AB 00 00 1C 00 00 00 A4 A1 00 00 00 ................ 000330: 00 00 00 88 AB 00 00 14 00 00 00 A4 A1 00 00 00 ................ 000340: 00 00 00 88 AC 00 00 0C 00 00 00 A4 A1 00 00 1C ................ 000350: 00 00 00 88 00 00 00 00 00 00 04 50 00 00 00 03 ...........P.... 000360: 00 00 00 03 00 00 00 01 00 00 00 55 0E 02 00 00 ...........U.... 000370: 00 00 00 7C 00 00 00 19 0F 01 00 00 00 00 00 64 ...|...........d 000380: 00 00 00 01 0F 01 00 00 00 00 00 00 00 00 00 4A ...............J 000390: 01 00 00 01 00 00 00 00 00 00 00 31 01 00 00 00 ...........1.... 0003A0: 00 00 00 00 00 5F 69 6E 69 74 5F 43 6F 6E 64 69 ....._init_Condi 0003B0: 74 69 6F 6E 61 6C 6D 61 63 72 6F 73 00 5F 66 69 tionalmacros._fi 0003C0: 6E 69 5F 43 6F 6E 64 69 74 69 6F 6E 61 6C 6D 61 ni_Conditionalma 0003D0: 63 72 6F 73 00 64 79 6C 64 5F 73 74 75 62 5F 62 cros.dyld_stub_b 0003E0: 69 6E 64 69 6E 67 5F 68 65 6C 70 65 72 00 5F 5F inding_helper.__ 0003F0: 70 5F 41 74 45 78 69 74 00 5F 5F 5F 63 74 6F 72 p_AtExit.___ctor 000400: 5F 72 75 6E 5F 63 6F 6E 64 69 74 69 6F 6E 5F 30 _run_condition_0 000410: 5F 5F 2E 30 00 00 00 00 __.0....
Is the keyword needed then, or is this a bug?
Thanks, Peter.
Peter N Lewis wrote:
At 23:10 +0100 26/3/03, Frank Heckenbach wrote:
Peter N Lewis wrote:
gpc -I/Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces -funit-path=/Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces --automake -o testrecord testrecord.pas
it would automatically include all the necessary units, but apparently not (did this change, I think it worked before but I might have compiled it slightly differently).
This should work. Since you don't say what happens, I can't tell more.
/usr/local/bin/ld: Undefined symbols: _init_Adsp _init_Aedatamodel _init_Aehelpers
I figured it out:
- Units without `implementation' part
I have removed the implementation keyword after seeing that comment in the release notes (since they are all interfaces and have no implementation and the keyword is not needed on the Mac in this case). But it appears if this is removed, then the init routine is not included in the .o file even though it appears still to be needed when you import the file:
With no implementation keyword:
No calls to implicit_module_constructor or implicit_module_destructor calls are made which generates the necessary hidden functions used for a unit/module's initialization and finalization code. Those calls are necessary for the implictly created chain of calls that are generated by uses and imports.
After adding the implementation keyword:
And calls to implicit_module_constructor or implicit_module_destructor calls are made so the necessary hidden functions are created.
Is the keyword needed then, or is this a bug?
It looks like a bug to me.
Frank, I believe the problem is in the optional_unit_implementation production in the empty alternative. I think just adding implicit_module_constructor and implicit_module_destructor functions calls in the code block containing the "CHK_DIALECT" macro would fix the problem.
A larger issue, though, is why are "pure" interface units (and modules) included in the initialization and finialization call chains. By pure, I mean they are strictly interface declarations for external code which isn't going to be in the Pascal language initialization and finalization context. These are what ISO 10206 would refer to as an externaal interface. Paragraph 6.1.5, Interface-directives has a note which covers this:
"NOTE --- A processor may provide, as an extension, the interface-directive external, which is used to specify that the module-block corresponding to the module-heading containing the interface-directive is in some form other than an Extended Pascal module-block (e.g., it is implemented in some other language). When providing such an extension, a processor should enforce the rules of Extended Pascal pertaining to type compatibility."
The Mac OS X interface units Peter and others are working on is exactly the case the note is describing. There are no corresponding Pascal module-block or unit-implemenation-part for the interfaces.
Based on quick look, I think you should be able to handle purely external interfaces in the same manner as the standard interfaces are handled in creation of the call chain from import/uses. If an import/uses of a purely external interface is encountered, just skip adding it to the intializer chain which would eliminate the necessity for generating the hidden functions for "pure" external interfaces.
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
It looks like a bug to me.
Frank, I believe the problem is in the optional_unit_implementation production in the empty alternative. I think just adding implicit_module_constructor and implicit_module_destructor functions calls in the code block containing the "CHK_DIALECT" macro would fix the problem.
Indeed. (Our mails just crossed each other. :-)
A larger issue, though, is why are "pure" interface units (and modules) included in the initialization and finialization call chains. By pure, I mean they are strictly interface declarations for external code which isn't going to be in the Pascal language initialization and finalization context. These are what ISO 10206 would refer to as an externaal interface. Paragraph 6.1.5, Interface-directives has a note which covers this:
"NOTE --- A processor may provide, as an extension, the interface-directive external, which is used to specify that the module-block corresponding to the module-heading containing the interface-directive is in some form other than an Extended Pascal module-block (e.g., it is implemented in some other language). When providing such an extension, a processor should enforce the rules of Extended Pascal pertaining to type compatibility."
Well, it "may provide", but doesn't have to. ;-) In my experience it's often useful to have a lot of external declarations and some Pascal ones, e.g. to make some interfaces easier to use from Pascal or add some functionality. Examples of this are the GMP and RegEx units that come with GPC, the two Pascal units in the GRX library, or the MySQL unit by Eike Lange.
The Mac OS X interface units Peter and others are working on is exactly the case the note is describing. There are no corresponding Pascal module-block or unit-implemenation-part for the interfaces.
Perhaps it will turn out useful to add some. :-)
Based on quick look, I think you should be able to handle purely external interfaces in the same manner as the standard interfaces are handled in creation of the call chain from import/uses. If an import/uses of a purely external interface is encountered, just skip adding it to the intializer chain which would eliminate the necessity for generating the hidden functions for "pure" external interfaces.
It might be possible in this case (though not in cases where `implementation' is given, but no explicit initializer since there are problems with circulare references). You'll have to check whether the unit uses any other units with intializers or contains auto-initialized variables (because then it does need an initializer).
If you (or someone else) wants to do it, just go ahead. I have more important things to work on (since this is neither a bug, nor a missing feature, only a (very minor) performance issue, it's very low on my priorities) ...
Frank
Peter N Lewis wrote:
- Units without `implementation' part
I have removed the implementation keyword after seeing that comment in the release notes (since they are all interfaces and have no implementation and the keyword is not needed on the Mac in this case). But it appears if this is removed, then the init routine is not included in the .o file even though it appears still to be needed when you import the file:
[...]
Is the keyword needed then, or is this a bug?
Bug.
--- p/parse.y.orig Wed Mar 26 12:36:24 2003 +++ p/parse.y Thu Mar 27 11:43:32 2003 @@ -496,7 +496,7 @@ /* Modules and units */
optional_unit_implementation: - /* empty */ + implicit_module_constructor implicit_module_destructor { CHK_DIALECT (MAC_PASCAL, "units without `implementation' part are a Mac Pascal extension."); } | p_implementation declarations_and_uses optional_unit_init_and_final_part { } ;
Lesson for the future: When new features are added, always submit some test programs. This would have made me notice the bug immediately. (In this case, I now wrote one, so no need to ...)
PS: Tools like nm and objdump are better suited for dumping object files than hex dumps.
Frank
I see that I can pack a subrange to make it fit into a byte, but it appears I cannot pack an enumerated type directly.
That is:
TYPE Month = packed 1..12;
works ok, but
TYPE Pref = packed (No, Yes);
does not.
I can do:
TYPE PrefX = (No, Yes); Pref = packed No..Yes;
Is there any reason that enumerated types could not be packed directly like subranges?
Thanks, Peter.
Peter N Lewis wrote:
I see that I can pack a subrange to make it fit into a byte, but it appears I cannot pack an enumerated type directly.
That is:
TYPE Month = packed 1..12;
works ok, but
TYPE Pref = packed (No, Yes);
does not.
I can do:
TYPE PrefX = (No, Yes); Pref = packed No..Yes;
Is there any reason that enumerated types could not be packed directly like subranges?
Packed subranges are a GPC extension not found in any other dialect or standard (AFAIK). So far, there apparently hasn't been a need for packed enums. I suppose they'd be rather easy to implement, but I'd have to check in detail if needed.
Frank
Packed subranges are a GPC extension not found in any other dialect or standard (AFAIK). So far, there apparently hasn't been a need for packed enums. I suppose they'd be rather easy to implement, but I'd have to check in detail if needed.
Mostly it just seems like a good place for better consistency.
On a related not, is it possible to define a set that fits inside a Byte? Traditionally the text Style in Mac OS has been defined as something like
set of (bold,italic,underlined)
and fits inside a byte. But of course the poor C folks can't do this so they just use a byte and do all that bit twiddling. But it seems GPC requires 4 bytes for this, even if both the set and the subrange are packed. Is that correct? I presume there is no way to work around this (and no, I'm not asking for it as a feature, just double checking that it is not possible currently).
Thanks, Peter.
On Fri, Mar 28, 2003 at 11:30:05AM +0800, Peter N Lewis wrote:
set of (bold,italic,underlined) and fits inside a byte. But of course the poor C folks can't do this so they just use a byte and do all that bit twiddling. But it seems GPC requires 4 bytes for this, even if both the set and the subrange are packed. Is that correct?
Yes. Sets are mostly treated as Integers.
I presume there is no way to work around this (and no, I'm not asking for it as a feature, just double checking that it is not possible currently).
Could the following help you?
program Bar; type TFace = packed record Bold, Italic, Underlined: Boolean end; var x: TFace; begin WriteLn (SizeOf (x)) { 1 Byte } end.
Eike
Peter N Lewis wrote:
Packed subranges are a GPC extension not found in any other dialect or standard (AFAIK). So far, there apparently hasn't been a need for packed enums. I suppose they'd be rather easy to implement, but I'd have to check in detail if needed.
Mostly it just seems like a good place for better consistency.
Well, I don't mind either way.
On a related not, is it possible to define a set that fits inside a Byte? Traditionally the text Style in Mac OS has been defined as something like
set of (bold,italic,underlined)
and fits inside a byte. But of course the poor C folks can't do this so they just use a byte and do all that bit twiddling. But it seems GPC requires 4 bytes for this, even if both the set and the subrange are packed. Is that correct? I presume there is no way to work around this (and no, I'm not asking for it as a feature, just double checking that it is not possible currently).
The sets routines operate on `MedWord' entities (= unsigned long in C). It can be changed to Bytes (`TSetElement' in rts/sets.pas, but also some bits in the compiler itself), but at the cost of efficiency with larger sets.
Supporting both in parallel, depending on the set size is, of course, not impossible, but extra work (you need 3-4 versions of each routine -- big/big, big/small, small/small, for the nonsymmetric ones also small/big), or let the compiler implicitly convert small sets to one word before calling an RTS routine (like it converts chars to strings when necessary, e.g.).
FWIW, we've thought about a more general set implementation, including sparse representations for huge sets (so, e.g. `set of Integer' would be possible). But at least for me (and apparently most other people), that's not very important. (When talking about various internal formats, strings are certainly much more important.)
Frank
Peter N Lewis wrote:
[snip]
One alternative is to change from unit "uses" to include files (which the Mac interfaces support anyway for reasons I've never understood),
It is to get behavior similar to THINK Pascal's uses propagation. The includes bring in all the declarations needed to effectively use the unit's interface without having to list the indirectly dependent units in the uses clause.
In essense, it is a combination of C header mechanisms with Pascal's unit mechanics. In effect, it is a poorman's implementation of Extended Pascal's import and export parts without all the fine grained control features like renaming and selective imports and exports. To make it work, though, the compiler has to be able to propagate compiler variable defines through the uses clause chain to avoid a boatload of redunant compiles and multiple redeclarations. I have the impression that GPC doesn't support that sort of compiler variable propagation so Apple's unit and include file methods and organization isn't going to work.
and just make a single really really big unit including all the interfaces. However that would be quite large and I don't know how happy GPC will be with a single unit with 300,000 lines in it, or how slow it will be for users to use it once the .gpi has been created.
I don't think it would be much different than using the Carbon framework with CodeWarrior. The initial compile (on the order of 170,000 lines) is noticeable but not inordinately slow. From then on you're using a cached precompiled unit similar to a .gpi and it isn't even noticeable.
I'll try some experiments, but if anyone has any suggestions, I'm all ears.
You might wamt to see how it effects linking and dynamic library loading also. I sure wouldn't want to hit every framework library just for a simple sysbeep call.
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
In essense, it is a combination of C header mechanisms with Pascal's unit mechanics. In effect, it is a poorman's implementation of Extended Pascal's import and export parts without all the fine grained control features like renaming and selective imports and exports. To make it work, though, the compiler has to be able to propagate compiler variable defines through the uses clause chain to avoid a boatload of redunant compiles and multiple redeclarations. I have the impression that GPC doesn't support that sort of compiler variable propagation so Apple's unit and include file methods and organization isn't going to work.
I don't understand what you mean, so I can't answer your question. Variable declarations in units surely work -- but that's nothing special. Uses propagation (whether routines or variables) doesn't work in GPC as you know. So I suppose you mean something different.
Frank
Frank Heckenbach wrote:
Gale Paeper wrote:
In essense, it is a combination of C header mechanisms with Pascal's unit mechanics. In effect, it is a poorman's implementation of Extended Pascal's import and export parts without all the fine grained control features like renaming and selective imports and exports. To make it work, though, the compiler has to be able to propagate compiler variable defines through the uses clause chain to avoid a boatload of redunant compiles and multiple redeclarations. I have the impression that GPC doesn't support that sort of compiler variable propagation so Apple's unit and include file methods and organization isn't going to work.
I don't understand what you mean, so I can't answer your question. Variable declarations in units surely work -- but that's nothing special. Uses propagation (whether routines or variables) doesn't work in GPC as you know. So I suppose you mean something different.
The point is, I think, that in GPC conditional compiler defines (macros set with $define) don't extend unit boundaries, where in traditional Macintosh Pascal compilers they do extend unit boundaries. I understand why this is so in GPC and for the Apple Interfaces it is not a big issue. We have found ways around it to make both "include" and "uses" mode work for the Apple Pascal Interfaces that we are porting to GPC.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
Gale Paeper wrote:
In essense, it is a combination of C header mechanisms with Pascal's unit mechanics. In effect, it is a poorman's implementation of Extended Pascal's import and export parts without all the fine grained control features like renaming and selective imports and exports. To make it work, though, the compiler has to be able to propagate compiler variable defines through the uses clause chain to avoid a boatload of redunant compiles and multiple redeclarations. I have the impression that GPC doesn't support that sort of compiler variable propagation so Apple's unit and include file methods and organization isn't going to work.
I don't understand what you mean, so I can't answer your question. Variable declarations in units surely work -- but that's nothing special. Uses propagation (whether routines or variables) doesn't work in GPC as you know. So I suppose you mean something different.
As Adriaan indicates, there are some differences in terminology in use between GPC and Macintosh Pascal dialects' compiler directive descriptions. From the GPC documentation, 6.9 Compiler Directives And The Preprocessor:
"BPs conditional definitions ({$define Foo}) go into another name space than the programs definitions. Therefore you can define conditionals and check them via {$ifdef Foo}, but the program will not see them as an identifier Foo ..."
In Macintosh Pascal dialects, Foo would be called a compiler variable (actually compile-time variable is the precisely correct term used in the Macintosh Pascal dialects' documentation) and they also go into different name space than the program's Pascal language declarations/definitions. (The supported syntax is also more elaborate supporting constant integer and boolean expressions [referred to as compile-time expressions] with assignments to compile-time variables supported.)
I think this difference in terminal may have lead to a few misinterpretations of various people's statements in the recent thread on CodeWarrior and THINK Pascal's propagating uses feature. (It doesn't help either when people [including myself] use imprecise terminology.)
The point is, I think, that in GPC conditional compiler defines (macros set with $define)
They aren't really macros since they don't have the macro text editting effect. What GPC's documentation refers to as "conditionals" are distinctly different from macros.
don't extend unit boundaries, where in traditional Macintosh Pascal compilers they do extend unit boundaries. I understand why this is so in GPC and for the Apple Interfaces it is not a big issue. We have found ways around it to make both "include" and "uses" mode work for the Apple Pascal Interfaces that we are porting to GPC.
Agreed, it isn't a big issue especially so in light of GPC's more extensive language support in the unit/module interface area. All things considered, it is probably best to avoid getting into compile-time variable propagation features since it is somewhat of a bucket of worms which no Macintosh Pascal compilers' documentation actually describes the behavior of. (It wasn't until the late '80s that MPW Pascal even allowed include file directives in a unit's interface part and the documentation was never revised to indicate the change. THINK Pascal has never supported include file directives and compile-time variables don't propagate to used units [I know they don't in the non-propagating uses case but I've never checked the progating uses case to see what happens.] CodeWarrior Pascal can charitably be described as an amazingly unique implementation with a treasure trove of undocumented surprises and gotcha's in the compile-time variable, unit interfacing, and include file areas.)
Although it would be pretty difficult to accomplish for the Macintosh interfaces especially so without support tools, Extended Pascal's interface-specification-part (i.e., export) seems to be the best way to construct a comprehensive, everything-that's-needed interface for a module/unit since it avoids all the problematic issues inherent in unit/include file combinations.
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
The point is, I think, that in GPC conditional compiler defines (macros set with $define)
They aren't really macros since they don't have the macro text editting effect. What GPC's documentation refers to as "conditionals" are distinctly different from macros.
They *can* be macros, see section 6.9 of the gpc manual:
{$define loop while True do}
define ‘loop’ to be ‘while True do’ or as a macro like in C. The name of the {$CIDefine loop ...} macro is case-insensitive. Note: Macros are disabled in ‘--borland-pascal’ mode because BP doesn’t support macros.
Regards,
Adriaan van Os
Gale Paeper wrote:
As Adriaan indicates, there are some differences in terminology in use between GPC and Macintosh Pascal dialects' compiler directive descriptions. From the GPC documentation, 6.9 Compiler Directives And The Preprocessor:
"BPÂs conditional definitions (Â{$define Foo}Â) go into another name space than the programÂs definitions. Therefore you can define conditionals and check them via {$ifdef Foo}, but the program will not see them as an identifier ÂFoo ..."
In Macintosh Pascal dialects, Foo would be called a compiler variable (actually compile-time variable is the precisely correct term used in the Macintosh Pascal dialects' documentation) and they also go into different name space than the program's Pascal language declarations/definitions. (The supported syntax is also more elaborate supporting constant integer and boolean expressions [referred to as compile-time expressions] with assignments to compile-time variables supported.)
I think this difference in terminal may have lead to a few misinterpretations of various people's statements in the recent thread on CodeWarrior and THINK Pascal's propagating uses feature. (It doesn't help either when people [including myself] use imprecise terminology.)
So we're now at the point where not only the compiler, but also ourselves have to work with a mixture of various dialects in terminology. :-(
Since compatibility issues don't matter so much in natural language discussions (only habits do), I'd prefer, however, to try to keep some kind of common language for better mutual understanding.
In this case, I think "variable" is an unfortunate term since it has a well-defined meaning in Pascal which is not this one. "Compiler" [in "compiler variable"] is also questionable to me. If we consider the usual parts of the language processor (preprocessor, parser, compiler proper, assembler, linker, etc.), this would belong to the preprocessor stage (i.e., do some substitutions before the result is actually treated as Pascal code) -- BTW, that's independent of whether there actually is a separate preprocessor (as in GPC currently) or if that's done implicitly during the other steps (as I plan to do it). So "compiler" would be misleading. OTOH, if you consider everything together as the compiler, then the addition of "compiler" in the phrase really doesn't mean anything because everything is handled by the "compiler".
Now, "compile-time variable" sounds a bit better, but I'm still skeptical about the "variable" part because of danger of confusing it with real variables.
The point is, I think, that in GPC conditional compiler defines (macros set with $define)
They aren't really macros since they don't have the macro text editting effect. What GPC's documentation refers to as "conditionals" are distinctly different from macros.
They're actually the same as macros without parameters. E.g.:
{$define Foo 42} var a: array [1 .. Foo] of Integer;
means just
var a: array [1 .. 42] of Integer;
Or, perhaps making things clearer:
{$define Foo 1 + 2}
var a: array [1 .. 3 * Foo] of Integer;
means
var a: array [1 .. 3 * 1 + 2] of Integer;
Sic, no parentheses! So it's really just text substitution.
Conditionals are evaluated by substituting all macros they contain (just like anywhere else) and evaluating the expression. So:
{$define Foo 42} {$if Foo > 40}
becomes
{$if 42 > 40}
which yields true.
And, of course, there's `ifdef' etc., but this also works the same for macros with and without arguments.
Agreed, it isn't a big issue especially so in light of GPC's more extensive language support in the unit/module interface area. All things considered, it is probably best to avoid getting into compile-time variable propagation features since it is somewhat of a bucket of worms which no Macintosh Pascal compilers' documentation actually describes the behavior of.
I'm not surprised. When I thought about the ramifications of macros across units, I came to some pretty strange cases, too. So I'd also prefer to stay away from it.
Frank
-
Adriaan van Os -
CBFalconer -
Eike Lange -
Frank Heckenbach -
Gale Paeper -
Maurice Lombardi -
Peter N Lewis -
Prof A Olowofoyeku (The African Chief) -
Prof. A Olowofoyeku (The African Chief)