I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/ The major incompatibility, compared to the previous release is that types liks `Integer (16)' have to be changed to `Integer attribute (Size = 16)' (as discussed recently).
New features:
* `Integer (16)' etc. changed to `Integer attribute (Size = 16)' (works for integer and Boolean types) (fjf861.pas) (@)
* types can have attributes (note: no preceding `;') (fjf860*.pas)
* object methods can have attributes (fjf826*.pas)
* new attributes `iocritical' (fjf824*.pas), `ignorable' (fjf839*.pas) for routines
* field names and array indices in initalizers are recognized (waldek5*.pas) (options `-W[no-]field-name-problem' removed, @)
* object directives `published', `public' (both equivalent), `protected' (scope limited to object type and derived object types), `private' (scope limited to current unit/module) (fjf864*.pas) (options `-W[no-]object-directives' removed, @)
* new options `-W[no-]parentheses' (fjf848*.pas)
* new type `AnyFile' for parameters and pointer targets (fjf821*.pas)
* Mac Pascal specific features are supported according to the dialect options (M)
* GPC doesn't use `gpm' files anymore (instead, each module has an implicit `MODULENAME-all.gpi' interface which is a regular `gpi' file)
* trimming string relations as functions (`EQPad' etc.) (fjf873.pas)
* new options `-W[no-]interface-file-name'
* `SeekEOF' and `SeekEOLn' use `Input' implicitly when no file is given (fjf871.pas) (B)
* tagging for `with' statements (Sun Pascal) (tom6.pas)
* new option `--sun-pascal'
* the operator precedence and associativity of `+' and `-' is now as defined in EP by default (and as in BP with `--borland-pascal') Pine.LNX.4.44.0210251249500.6181-100000@duch.mimuw.edu.pl (fjf863*.pas) (@)
* dynamic object methods (fjf859.pas) (B)
* in `--borland-pascal' mode, `Assign' unconditionally (re-)initializes its file parameter (fjf858.pas)
* make the program/module/unit finalizers non-public (`static' in C sense), omit them if easily possible
* non-`interface' modules with empty implementation part (pmod1.pas, fjf843.pas)
* `maximum-field-alignment' and `[no-]field-widths' work as local compiler directives now (fjf842.pas)
* dropped `{$debug-statement}' (should not be necessary anymore, now that debug info mostly works)
* new options `--[no-]longjmp-all-nonlocal-labels'
* dropped computed `goto' (never worked for nonlocal `goto' into the main program, implementing it would be quite difficult, probably not worth it) (@)
* `TimeStamp' is now a packed record (E)
* `--interface-only' does not require `-S' or `-c' anymore (and does not create an object file)
Fixed bugs:
* some functions in boolean shortcuts are always called (fjf226*.pas)
* possible stack overflow when using string concatenation in a loop (fjf419*.pas, fjf345e.pas, fjf460b.pas) - breaks berend3.pas (less important because strange test case, and just another instance of existing contourbug.pas)
* declarations of a module interface are not visible in the implementation (kevin13.pas, mod12.pas) Pine.BSI.3.96.971110210330.7570A-100000@malasada.lava.net
* check parameter and result variable names in repeated forward etc. declarations 20010321204051.A611@plato (fjf284.pas, markus8.pas, fjf850*.pas)
* initialized object variables don't work (fjf445*.pas)
* the parser does not always recover well after a parse error 199911040915.KAA11168@humulus.daimi.au.dk (fixed the case given in this report; if there are other cases, please report)
* packed array/record fields don't work in `Read' etc. (tom5.pas)
* file parameters must not automatically be bindable in `--extended-pascal' (fjf193[c-e].pas)
* give an error rather than a warning when casting between types of different size in `{$X-}'
* simplify code generated to compute size of dynamical variables if no bitfields are involved (ok with gcc-3)
* detect invalid array slice access with constant indices at compile-time (peter2*.pas)
* automatically close dynamically allocated files on `Dispose' and files declared in a statement block at the end of the statement block 6r9ir5$7v5$1@nntpd.lkg.dec.com (fjf219[a-d].pas, fjf502.pas)
* initialize local static variables in the main constructor, not in each routine call (fjf458*.pas)
* modifying `for'-loop counters within the loop or in a subroutine is not allowed 200005240807.EAA05355@mail.bcpl.net, Pine.LNX.4.44.0210281004000.31943-100000@duch.mimuw.edu.pl (az47.pas, fjf837*.pas)
* label declarations must not be allowed in unit/module interfaces and module implementations (but in unit implementations, BP compatible, though we don't allow nonlocal `goto's into the constructor) (fjf835*.pas)
Frank
On 7 May 2003 at 20:22, Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/ The major incompatibility, compared to the previous release is that types liks `Integer (16)' have to be changed to `Integer attribute (Size = 16)' (as discussed recently).
Trying to compile (with gcc-3.2.3 sources) under Mingw produced this:
"In file included from d:/src/mingw/gcc-3.2.3/gcc/p/declarations.c:29: d:/src/mingw/gcc-3.2.3/gcc/p/gpc.h:1132: conflicting types for `mark_addressable' d:/src/mingw/gcc-3.2.3/gcc/tree.h:3084: previous declaration of `mark_addressable' d:/src/mingw/gcc-3.2.3/gcc/p/declarations.c: In function `builtin_function': d:/src/mingw/gcc-3.2.3/gcc/p/declarations.c:1483: number of arguments doesn't match prototype d:/src/mingw/gcc-3.2.3/gcc/tree.h:2781: prototype declaration d:/src/mingw/gcc-3.2.3/gcc/p/declarations.c:3032:31: gt-p- declarations.h: No such file or directory make[1]: *** [p/declarations.o] Error 1 make[1]: Leaving directory `/src/mingw/gcc' make: *** [all-gcc] Error 2"
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Dnia - czwartek 08 maj 2003, o 21:03:29 +0100 - Prof A Olowofoyeku (The African Chief) napisaÂł(-a):
On 7 May 2003 at 20:22, Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/ The major incompatibility, compared to the previous release is that types liks `Integer (16)' have to be changed to `Integer attribute (Size = 16)' (as discussed recently).
Trying to compile (with gcc-3.2.3 sources) under Mingw produced this:
Under Linix, too
"In file included from d:/src/mingw/gcc-3.2.3/gcc/p/declarations.c:29: d:/src/mingw/gcc-3.2.3/gcc/p/gpc.h:1132: conflicting types for `mark_addressable' d:/src/mingw/gcc-3.2.3/gcc/tree.h:3084: previous declaration of `mark_addressable'
[...]
Small change in 'config-lang.in' line 42: - if echo $version | grep '3.2.[3-9]' > /dev/null [...] ^^^^___ this + if echo $version | grep '3.2.[4-9]' > /dev/null [...]
Best regards, Jarek
Jaroslaw J. Pyszny wrote:
Small change in 'config-lang.in' line 42:
- if echo $version | grep '3.2.[3-9]' > /dev/null [...] ^^^^___ this
- if echo $version | grep '3.2.[4-9]' > /dev/null [...]
OK, thanks. BTW, GPC with gcc-3.2.3 is not well tested yet (the warnings you get in your test run might be due to this). Waldek and Matthias are working on it. For a "production" compiler still gcc 3.2.1 or 3.2.2 is recommended.
Frank
Frank Heckenbach wrote:
Jaroslaw J. Pyszny wrote:
Small change in 'config-lang.in' line 42:
- if echo $version | grep '3.2.[3-9]' > /dev/null [...] ^^^^___ this
- if echo $version | grep '3.2.[4-9]' > /dev/null [...]
OK, thanks. BTW, GPC with gcc-3.2.3 is not well tested yet (the warnings you get in your test run might be due to this). Waldek and Matthias are working on it. For a "production" compiler still gcc 3.2.1 or 3.2.2 is recommended.
Some problems are appearing with gcc 3.2 on the DJGPP-workers mail list. It is hoped to be resolved by 3.3. It has to do with generating 386 code, and I haven't been paying much attention.
CBFalconer wrote:
Frank Heckenbach wrote:
Jaroslaw J. Pyszny wrote:
Small change in 'config-lang.in' line 42:
- if echo $version | grep '3.2.[3-9]' > /dev/null [...] ^^^^___ this
- if echo $version | grep '3.2.[4-9]' > /dev/null [...]
OK, thanks. BTW, GPC with gcc-3.2.3 is not well tested yet (the warnings you get in your test run might be due to this). Waldek and Matthias are working on it. For a "production" compiler still gcc 3.2.1 or 3.2.2 is recommended.
Some problems are appearing with gcc 3.2 on the DJGPP-workers mail list. It is hoped to be resolved by 3.3. It has to do with generating 386 code, and I haven't been paying much attention.
That's quite unspecific, so I can't tell much.
Anyway, it seems that all GCC versions have some bugs, especially platform specific ones. That's one reason why GPC supports so many of them, so chances are you find a usable one on each platform.
However, at some point we'll have to drop gcc-2 support because carrying it around causes some extra work. My current plans are to deprecate it in gpc-2.2 and remove it shortly after it.
Frank
Frank Heckenbach wrote:
CBFalconer wrote:
... snip ...
Some problems are appearing with gcc 3.2 on the DJGPP-workers mail list. It is hoped to be resolved by 3.3. It has to do with generating 386 code, and I haven't been paying much attention.
That's quite unspecific, so I can't tell much.
Anyway, it seems that all GCC versions have some bugs, especially platform specific ones. That's one reason why GPC supports so many of them, so chances are you find a usable one on each platform.
IIRC it has to do with returning records in registers. I suggest you visit the DJGPP archive of the djgpp-workers mail list.
CBFalconer wrote:
Frank Heckenbach wrote:
CBFalconer wrote:
... snip ...
Some problems are appearing with gcc 3.2 on the DJGPP-workers mail list. It is hoped to be resolved by 3.3. It has to do with generating 386 code, and I haven't been paying much attention.
That's quite unspecific, so I can't tell much.
Anyway, it seems that all GCC versions have some bugs, especially platform specific ones. That's one reason why GPC supports so many of them, so chances are you find a usable one on each platform.
IIRC it has to do with returning records in registers. I suggest you visit the DJGPP archive of the djgpp-workers mail list.
Sorry, no, I don't plan to debug DJGPP specific backend bugs. I've really got enough to do with the Pascal compiler.
Frank
Frank Heckenbach wrote:
- `Integer (16)' etc. changed to `Integer attribute (Size = 16)' (works for integer and Boolean types) (fjf861.pas) (@)
What about calling it `Integer attribute (Bitsize = 16)' ? Analog to SizeOf and BitSizeOf.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
- `Integer (16)' etc. changed to `Integer attribute (Size = 16)' (works for integer and Boolean types) (fjf861.pas) (@)
What about calling it `Integer attribute (Bitsize = 16)' ? Analog to SizeOf and BitSizeOf.
May I suggest you get a time machine at your local shop, travel back to last December when it was discussed (you were in the list at that time, BTW) and make your suggestion then? :-/
I don't feel like changing all sources *again*, unless there's a very compelling reason.
Frank
This is what I get, building the new alpha with gcc-3.2.1 on Mac OS X
../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/Users/adriaan/gnu/gpc-20030507/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /Users/adriaan/gnu/gpc-20030507/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.2.1'" /Users/adriaan/gnu/gpc-20030507/gcc/p/rts/filename.pas /Users/adriaan/gnu/gpc-20030507/gcc/p/rts/filename.pas: In function `ConfigFileName': /Users/adriaan/gnu/gpc-20030507/gcc/p/rts/filename.pas:1481: internal error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. make[2]: *** [filename.o] Error 1 make[1]: *** [pascal.rts] Error 2 make: *** [all-gcc] Error 2
The backtrace reads:
Command: gpc1 PID: 5381
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
Thread 0 Crashed: #0 0x000d90d8 in ggc_set_mark (ggc-page.c:437) #1 0x000d8138 in ggc_mark_trees (ggc-common.c:521) #2 0x000d6da0 in ggc_mark_roots (ggc-common.c:261) #3 0x000d97d0 in ggc_collect (ggc-page.c:1437) #4 0x000a4618 in rest_of_compilation (toplev.c:2552) #5 0x00007b08 in finish_routine (declarations.c:2434) #6 0x0002b898 in main_yyparse (parse.c:1739) #7 0x0002dab8 in yyparse (parse.c:2974) #8 0x000a3dd8 in compile_file (toplev.c:2128) #9 0x000a8a3c in do_compile (toplev.c:5218) #10 0x000a8ae0 in toplev_main (toplev.c:5250) #11 0x000b4638 in main (main.c:35) #12 0x00002518 in _start (crt.c:267) #13 0x00002398 in start
PPC Thread State: srr0: 0x000d90d8 srr1: 0x0200d930 vrsave: 0x00000000 xer: 0x20000000 lr: 0x000d908c ctr: 0x000d7f5c mq: 0x00000000 r0: 0x00000008 r1: 0xbfffddb0 r2: 0x28000248 r3: 0x02000000 r4: 0x00001000 r5: 0x00000000 r6: 0x00000001 r7: 0x00000001 r8: 0x00000000 r9: 0x00000fff r10: 0x002d1c20 r11: 0x00000000 r12: 0x44000282 r13: 0x00000008 r14: 0x000000c8 r15: 0xbfffe1d0 r16: 0x00000075 r17: 0x00000000 r18: 0x002b968c r19: 0x002d968c r20: 0x00000001 r21: 0x002d1ca8 r22: 0x002d1b98 r23: 0x00000022 r24: 0x002d72bc r25: 0x002b72bc r26: 0x00000001 r27: 0x0190cc40 r28: 0x00000012 r29: 0x00000000 r30: 0x02000000 r31: 0x000d908c
Adriaan van Os wrote:
This is what I get, building the new alpha with gcc-3.2.1 on Mac OS X
../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/Users/adriaan/gnu/gpc-20030507/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /Users/adriaan/gnu/gpc-20030507/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.2.1'" /Users/adriaan/gnu/gpc-20030507/gcc/p/rts/filename.pas /Users/adriaan/gnu/gpc-20030507/gcc/p/rts/filename.pas: In function `ConfigFileName': /Users/adriaan/gnu/gpc-20030507/gcc/p/rts/filename.pas:1481: internal error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. make[2]: *** [filename.o] Error 1 make[1]: *** [pascal.rts] Error 2 make: *** [all-gcc] Error 2
The backtrace reads:
Command: gpc1 PID: 5381
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
Thread 0 Crashed: #0 0x000d90d8 in ggc_set_mark (ggc-page.c:437) #1 0x000d8138 in ggc_mark_trees (ggc-common.c:521) #2 0x000d6da0 in ggc_mark_roots (ggc-common.c:261) #3 0x000d97d0 in ggc_collect (ggc-page.c:1437) #4 0x000a4618 in rest_of_compilation (toplev.c:2552) #5 0x00007b08 in finish_routine (declarations.c:2434) #6 0x0002b898 in main_yyparse (parse.c:1739) #7 0x0002dab8 in yyparse (parse.c:2974) #8 0x000a3dd8 in compile_file (toplev.c:2128) #9 0x000a8a3c in do_compile (toplev.c:5218) #10 0x000a8ae0 in toplev_main (toplev.c:5250) #11 0x000b4638 in main (main.c:35) #12 0x00002518 in _start (crt.c:267) #13 0x00002398 in start
PPC Thread State: srr0: 0x000d90d8 srr1: 0x0200d930 vrsave: 0x00000000 xer: 0x20000000 lr: 0x000d908c ctr: 0x000d7f5c mq: 0x00000000 r0: 0x00000008 r1: 0xbfffddb0 r2: 0x28000248 r3: 0x02000000 r4: 0x00001000 r5: 0x00000000 r6: 0x00000001 r7: 0x00000001 r8: 0x00000000 r9: 0x00000fff r10: 0x002d1c20 r11: 0x00000000 r12: 0x44000282 r13: 0x00000008 r14: 0x000000c8 r15: 0xbfffe1d0 r16: 0x00000075 r17: 0x00000000 r18: 0x002b968c r19: 0x002d968c r20: 0x00000001 r21: 0x002d1ca8 r22: 0x002d1b98 r23: 0x00000022 r24: 0x002d72bc r25: 0x002b72bc r26: 0x00000001 r27: 0x0190cc40 r28: 0x00000012 r29: 0x00000000 r30: 0x02000000 r31: 0x000d908c
I think I need more information (parameter, variable values) ...
Frank
This is what I get, building the new alpha with gcc-3.2.1 on Mac OS X
../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/Users/adriaan/gnu/gpc-20030507/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /Users/adriaan/gnu/gpc-20030507/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.2.1'" /Users/adriaan/gnu/gpc-20030507/gcc/p/rts/filename.pas /Users/adriaan/gnu/gpc-20030507/gcc/p/rts/filename.pas: In function `ConfigFileName': /Users/adriaan/gnu/gpc-20030507/gcc/p/rts/filename.pas:1481: internal error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. make[2]: *** [filename.o] Error 1 make[1]: *** [pascal.rts] Error 2 make: *** [all-gcc] Error 2
After a reboot, the problem had gone and gpc did build. With the previous alpha also, I often get "strange" compiler messages (mostly assertions). The remedy is then to reboot. I can't say if this is a problem in gpc or in Mac OS X.
Regards,
Adriaan van Os
Adriaan van Os wrote:
This is what I get, building the new alpha with gcc-3.2.1 on Mac OS X
../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/Users/adriaan/gnu/gpc-20030507/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /Users/adriaan/gnu/gpc-20030507/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.2.1'" /Users/adriaan/gnu/gpc-20030507/gcc/p/rts/filename.pas /Users/adriaan/gnu/gpc-20030507/gcc/p/rts/filename.pas: In function `ConfigFileName': /Users/adriaan/gnu/gpc-20030507/gcc/p/rts/filename.pas:1481: internal error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. make[2]: *** [filename.o] Error 1 make[1]: *** [pascal.rts] Error 2 make: *** [all-gcc] Error 2
After a reboot, the problem had gone and gpc did build. With the previous alpha also, I often get "strange" compiler messages (mostly assertions). The remedy is then to reboot. I can't say if this is a problem in gpc or in Mac OS X.
It could be either, and it could also be a hardware problem. I don't know how reliable Mac hardware is in general -- PC hardware isn't so much, and especially on warmer days like these I sometimes get intermittent crashes in longer compilations. The solution is to wait a little time to let the CPU cool down. A reboot might have a similar effect, of course.
Another possibility is that it's related to memory management, i.e., after a reboot the compiler gets a "clean" memory and certain bugs in GPC don't show this way. Again, I don't know much about Mac OS X's memory management. However, most Unix-like systems (and this should include it) use paging and free any newly allocated pages before giving them to a process, so a process should see no difference due to memory fragmentation etc. If that's so, this would rule out this possibility. (At least under Linux I've never seen a problem that could be traced to this cause.)
So I can only speculate. The only way to tell for sure is probably to catch such an error in the debugger and try to investigate what's wrong exactly. But this may be quite difficult, especially if it's not reproducible ...
BTW, if after such a problem, you run exactly the same command again, do you get exactly the same error in the same position? If so, this probably means it's not a hardware problem ...
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
This is what I get, building the new alpha with gcc-3.2.1 on Mac OS X
After a reboot, the problem had gone and gpc did build. With the previous alpha also, I often get "strange" compiler messages (mostly assertions). The remedy is then to reboot. I can't say if this is a problem in gpc or in Mac OS X.
It could be either, and it could also be a hardware problem. I don't know how reliable Mac hardware is in general -- PC hardware isn't so much, and especially on warmer days like these I sometimes get intermittent crashes in longer compilations. The solution is to wait a little time to let the CPU cool down. A reboot might have a similar effect, of course.
Macintosh hardware is usually very reliable. It is real a pleasure to open up the lid of a G4 and look at the electronics.
Another possibility is that it's related to memory management, i.e., after a reboot the compiler gets a "clean" memory and certain bugs in GPC don't show this way. Again, I don't know much about Mac OS X's memory management. However, most Unix-like systems (and this should include it) use paging and free any newly allocated pages before giving them to a process, so a process should see no difference due to memory fragmentation etc. If that's so, this would rule out this possibility. (At least under Linux I've never seen a problem that could be traced to this cause.)
What I know is that Mac OS X is based on BSD 4.2 with a Mach microkernel. But I would have to study the details of memory management to say something useful about it.
So I can only speculate. The only way to tell for sure is probably to catch such an error in the debugger and try to investigate what's wrong exactly. But this may be quite difficult, especially if it's not reproducible ...
BTW, if after such a problem, you run exactly the same command again, do you get exactly the same error in the same position? If so, this probably means it's not a hardware problem ...
Yes, the same problem occurs again in the same position, at least in some cases, maybe all. I will try to do some debugging if it happens again.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Macintosh hardware is usually very reliable. It is real a pleasure to open up the lid of a G4 and look at the electronics.
How can you see the reliability? My PC electronics also *looks* quite nice (if there doesn't happen to be an exploded capacitor lying around ;-), but it probably has some slight thermic problems (too small cooler I suppose) ...
Frank
Test under Linux (RedHat 7.3) OS: Linux 2.4.18 CPU: AMD Duron (Morgan) 1.2GHz GCC: GCC 3.2.3/GPC 20030507 FLAGS: -Wall -O2 -march=athlon-xp -mcpu=athlon-xp -pipe -D__pentium__ -D__pentiumpro__ -D_GNU_SOURCE
TEST fjf386.pas: gpc1: warnings being treated as errors /mnt/dane/buduj/gcc/gcc-3.2.3/gcc/p/test/fjf386.pas: In procedure `baz': /mnt/dane/buduj/gcc/gcc-3.2.3/gcc/p/test/fjf386.pas:11: warning: statement with no effect failed
TEST fjf480a.pas: SKIPPED: librx not installed TEST fjf480b.pas: SKIPPED: librx not installed TEST fjf857.pas: gpc1: warnings being treated as errors
/mnt/dane/buduj/gcc/gcc-3.2.3/gcc/p/test/fjf857.pas: In procedure `g': /mnt/dane/buduj/gcc/gcc-3.2.3/gcc/p/test/fjf857.pas:16: warning: statement with no effect failed
TEST regextest.pas: SKIPPED: librx not installed
TEST sietse3.pas: gpc1: warnings being treated as errors /mnt/dane/buduj/gcc/gcc-3.2.3/gcc/p/test/sietse3m.pas: In procedure `getfilename': /mnt/dane/buduj/gcc/gcc-3.2.3/gcc/p/test/sietse3m.pas:17: warning: statement with no effect gpc1: /mnt/dane/buduj/gcc/gcc-3.2.3/Bud/gcc/xgpc exited with status 1 failed
# of GPC tests 3594 # of GPC tests passed 3588 # of GPC tests skipped 3 # of GPC tests failed 3
Best regards, Jarek
Hi Frank
This program does not compile. Shouldn't it?
Program attribute_bug;
TYPE Int8 = Integer attribute ( Size = 8 );
WordRec : RECORD Lo, Hi : Cardinal attribute ( Size = 8 ); END;
LongRec = PACKED RECORD Lo, Hi : Cardinal attribute ( Size = 16 ); END;
Begin Writeln ('OK'); End.
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:
This program does not compile. Shouldn't it?
Program attribute_bug;
TYPE Int8 = Integer attribute ( Size = 8 );
WordRec : RECORD Lo, Hi : Cardinal attribute ( Size = 8 ); END;
LongRec = PACKED RECORD Lo, Hi : Cardinal attribute ( Size = 16 ); END;
Begin Writeln ('OK'); End.
Attributes currently don't work in record fields etc. It would be extra effort to recognize them (syntactically). But since one can always declare a type with attributes (such as `Int8') and use this in the record, I'm not conviced whether I should do it ...
One reason against it is that it's not possible in arrays, sets and files because then the following would be ambiguous (does the attribute belong to the array of the component type?). So it might be more consistent to not allow it in any structured types.
type foo = array [1 .. 2] of Integer attribute (...);
Frank
On 10 May 2003 at 3:30, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
This program does not compile. Shouldn't it?
Program attribute_bug;
TYPE Int8 = Integer attribute ( Size = 8 );
WordRec : RECORD Lo, Hi : Cardinal attribute ( Size = 8 ); END;
LongRec = PACKED RECORD Lo, Hi : Cardinal attribute ( Size = 16 ); END;
Begin Writeln ('OK'); End.
Attributes currently don't work in record fields etc. It would be extra effort to recognize them (syntactically). But since one can always declare a type with attributes (such as `Int8') and use this in the record, I'm not conviced whether I should do it ...
Ok. Look at this record (in existing WinAPI import units): TYPE tBits = PACKED RECORD BaseMid : Cardinal ( 8 ); Typ : Cardinal ( 5 ); Dpl : Cardinal ( 2 ); Pres : Cardinal ( 1 ); LimitHi : Cardinal ( 4 ); Sys : Cardinal ( 1 ); Reserved_0 : Cardinal ( 1 ); Default_Big : Cardinal ( 1 ); Granularity : Cardinal ( 1 ); BaseHi : Cardinal ( 8 ) END;
I have to change my code to define at least 4 different types for this. Consider many more structures of this kind. Of course the work can be done, even if tedious - but one would then have a proliferation of types just to be able to create one record. I will do the work, but you might want to reconsider this matter.
One reason against it is that it's not possible in arrays, sets and files because then the following would be ambiguous (does the attribute belong to the array of the component type?). So it might be more consistent to not allow it in any structured types.
Perhaps.
I have another problem. This code used to compile:
unit attrbug_2; interface uses GPC; FUNCTION DirectoryExists ( CONST DirName : String ) : Boolean; attribute (name = '_p_DirectoryExists'); external; FUNCTION FileSearch ( CONST FileName, DirList : String ) : TString; attribute (name = '_p_FSearch'); external; implementation end.
Now, it dies with this error: "attributes in forward declared routines are not allowed". If "external" is removed, then you get an error like "unresolved forward declaration `FileSearch'".
This code is taken from the Sysutils unit, which exports some functions that already exist in the GPC unit. In older times, you just asmnamed them. In the penultimate snapshot, that was changed to the above. Now, it doesn't work. I need this to work (or at least I need to have a way to reexport routines from other units). This is reminiscent of the earlier discussions on unit propagation. I am not sure how that discussion was resolved.
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:
On 10 May 2003 at 3:30, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
This program does not compile. Shouldn't it?
Program attribute_bug;
TYPE Int8 = Integer attribute ( Size = 8 );
WordRec : RECORD Lo, Hi : Cardinal attribute ( Size = 8 ); END;
LongRec = PACKED RECORD Lo, Hi : Cardinal attribute ( Size = 16 ); END;
Begin Writeln ('OK'); End.
Attributes currently don't work in record fields etc. It would be extra effort to recognize them (syntactically). But since one can always declare a type with attributes (such as `Int8') and use this in the record, I'm not conviced whether I should do it ...
Ok. Look at this record (in existing WinAPI import units): TYPE tBits = PACKED RECORD BaseMid : Cardinal ( 8 ); Typ : Cardinal ( 5 ); Dpl : Cardinal ( 2 ); Pres : Cardinal ( 1 ); LimitHi : Cardinal ( 4 ); Sys : Cardinal ( 1 ); Reserved_0 : Cardinal ( 1 ); Default_Big : Cardinal ( 1 ); Granularity : Cardinal ( 1 ); BaseHi : Cardinal ( 8 ) END;
I have to change my code to define at least 4 different types for this. Consider many more structures of this kind. Of course the work can be done, even if tedious - but one would then have a proliferation of types just to be able to create one record. I will do the work, but you might want to reconsider this matter.
I've had a few such cases myself. OTOH, there's probably a limited number of types that occur in such situations at all (like 1 .. 8, 16, 32 and 64 bits, maybe one or two more; and probably all of them unsigned, I think C doesn't even allow signed types there). (And some if not all if the 1-bit types can perhaps be replaced by Boolean, BTW.)
I'm still undecided. Basically, the arguments go like this:
- It's not possible (syntactically) to allow attributes in components of certain structures (arrays, sets, files), so we shouldn't allow them in any.
- C allows `:n' in structs and unions, so we should allow attributes in records.
One reason against it is that it's not possible in arrays, sets and files because then the following would be ambiguous (does the attribute belong to the array of the component type?). So it might be more consistent to not allow it in any structured types.
Perhaps.
I have another problem. This code used to compile:
unit attrbug_2; interface uses GPC; FUNCTION DirectoryExists ( CONST DirName : String ) : Boolean; attribute (name = '_p_DirectoryExists'); external; FUNCTION FileSearch ( CONST FileName, DirList : String ) : TString; attribute (name = '_p_FSearch'); external; implementation end.
Now, it dies with this error: "attributes in forward declared routines are not allowed".
There are two issues here:
First, this isn't allowed anymore:
procedure foo; forward;
procedure foo; attribute (name = 'bar'); begin end;
As you can imagine, this never really worked. GPC would silently produce wrong code (calling asmname `Foo' when the procedure was called between the forward declaration and the implementation). Now it rejects it.
Unit interface declarations are much like `forward'.
The second one is the well-known lack of qualified identifiers, so GPC (wrongly) identifies the function DirectoryExists in the GPC unit and in this unit. So the first problem applies.
But there is a solution, which will work now, and is recommended even when QI will have been implemented because it's cleaner, easier and safer (no problem if the routine interface or asmname in the GPC unit changes). This is explicit module re-export:
- Turn your unit into a module. That's quite simple:
unit Foo;
interface
=>
module Foo;
export Foo = all;
and
implementation
=>
end;
and
begin [...] end.
=>
to begin do begin [...] end;
end.
Then just add anything you want to re-export to the export clause, e.g.:
export attrbug_2 = all (DirectoryExists, FileSearch);
Or if you like to change the name (exactly this code is now in the GPCUtil module where the same issue occurred, BTW):
export GPCUtil = all (DirectoryExists => IsDirectory);
If "external" is removed, then you get an error like "unresolved forward declaration `FileSearch'".
That's clear. Without `external', you claim that you'll implement the function in this unit.
This code is taken from the Sysutils unit, which exports some functions that already exist in the GPC unit. In older times, you just asmnamed them. In the penultimate snapshot, that was changed to the above. Now, it doesn't work. I need this to work (or at least I need to have a way to reexport routines from other units). This is reminiscent of the earlier discussions on unit propagation. I am not sure how that discussion was resolved.
There's no "reexport all" feature, but reexporing selected items works as shown above. (I think that's what you need, you don't want to reexport the whole GPC unit.)
Unfortunately, this problem is not only related to unit propagation. I have just tried to compile the Windows unit (that exports thousands of winapi routines, interfacing to the Mingw winapi libraries), and two of those routines are now rejected with the "attributes in forward declared routines are not allowed" error. There is no reason for those two routines to be singled out, and there is no USES problem here.
Probably these routines are declared `forward' or something like it. Generally, it applies when a routine is declared twice.
Frank
On 10 May 2003 at 14:27, Frank Heckenbach wrote:
[...]
This code is taken from the Sysutils unit, which exports some functions that already exist in the GPC unit. In older times, you just asmnamed them. In the penultimate snapshot, that was changed to the above. Now, it doesn't work. I need this to work (or at least I need to have a way to reexport routines from other units). This is reminiscent of the earlier discussions on unit propagation. I am not sure how that discussion was resolved.
There's no "reexport all" feature, but reexporing selected items works as shown above. (I think that's what you need, you don't want to reexport the whole GPC unit.)
Ok, thanks. I guess I'll just have to do the module+selective re- exporting stuff.
Unfortunately, this problem is not only related to unit propagation. I have just tried to compile the Windows unit (that exports thousands of winapi routines, interfacing to the Mingw winapi libraries), and two of those routines are now rejected with the "attributes in forward declared routines are not allowed" error. There is no reason for those two routines to be singled out, and there is no USES problem here.
Probably these routines are declared `forward' or something like it. Generally, it applies when a routine is declared twice.
No, they are not declared "forward" - and they are not declared twice (I have done searches and greps just to verify that). I have since discovered however that it's not just those two (what happened was that the compiler stopped on the second error reported, instead of listing all the affected routines).
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:
Unfortunately, this problem is not only related to unit propagation. I have just tried to compile the Windows unit (that exports thousands of winapi routines, interfacing to the Mingw winapi libraries), and two of those routines are now rejected with the "attributes in forward declared routines are not allowed" error. There is no reason for those two routines to be singled out, and there is no USES problem here.
Probably these routines are declared `forward' or something like it. Generally, it applies when a routine is declared twice.
No, they are not declared "forward" - and they are not declared twice (I have done searches and greps just to verify that). I have since discovered however that it's not just those two (what happened was that the compiler stopped on the second error reported, instead of listing all the affected routines).
Somehow there must be two declarations, whether forward, interface, in different units etc.
If you can't find it out, please send me some example code ...
Frank
On 11 May 2003 at 0:33, Frank Heckenbach wrote:
[...]
No, they are not declared "forward" - and they are not declared twice (I have done searches and greps just to verify that). I have since discovered however that it's not just those two (what happened was that the compiler stopped on the second error reported, instead of listing all the affected routines).
Somehow there must be two declarations, whether forward, interface, in different units etc.
Well, as I said, I have done grep searches, and there are no repeated declarations involved. One example is: FUNCTION InterlockedIncrement ( VAR lpAddend : LongInt ) : LongInt; WINAPI ( 'InterlockedIncrement' ); It is not referred to in any other source file.
WINAPI thus defined: {$define Stdcall attribute(stdcall)} {$define WINAPI(X) external name X; Stdcall}
If you can't find it out, please send me some example code ...
It is not possible to reduce this to any simple example that shows the problem. A simple unit with the above declarations compiles okay. But in the winprocs.pas source, it gives the error. There is no reason why it should. If you want to have a go, perhaps you can download the latest winapi release from contrib/chief/ on the GPC server.
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:
Well, as I said, I have done grep searches, and there are no repeated declarations involved. One example is: FUNCTION InterlockedIncrement ( VAR lpAddend : LongInt ) : LongInt; WINAPI ( 'InterlockedIncrement' ); It is not referred to in any other source file.
WINAPI thus defined: {$define Stdcall attribute(stdcall)} {$define WINAPI(X) external name X; Stdcall}
If you can't find it out, please send me some example code ...
It is not possible to reduce this to any simple example that shows the problem. A simple unit with the above declarations compiles okay. But in the winprocs.pas source, it gives the error. There is no reason why it should. If you want to have a go, perhaps you can download the latest winapi release from contrib/chief/ on the GPC server.
I see. The error was not actually about this function, but the previous one (which is in fact declared twice).
Since GPC needs to read past the terminating `;' of the declaration (in case there are more attributes), it is already at the beginning of the next line when giving the error, so the line number is misleading.
I'll try to fix this, but it might not be too easy. For now, just remember to look in the previous line (for many kinds of errors) ...
Frank
On 11 May 2003 at 15:13, Frank Heckenbach wrote:
[...]
I see. The error was not actually about this function, but the previous one (which is in fact declared twice).
Yes, I see it now. I was searching for the wrong thing ...
Since GPC needs to read past the terminating `;' of the declaration (in case there are more attributes), it is already at the beginning of the next line when giving the error, so the line number is misleading.
I'll try to fix this, but it might not be too easy. For now, just remember to look in the previous line (for many kinds of errors) ...
Ok.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
On 10 May 2003 at 14:27, Frank Heckenbach wrote:
[...]
Turn your unit into a module. That's quite simple:
unit Foo;
interface
=>
module Foo;
export Foo = all;
and
implementation
=>
end;
and
begin [...] end.
=>
to begin do begin [...] end;
end.
I have a problem. I don't want to export everything. I only want to export things in the current interface section (and there are hundreds of them, and a few of them are routines from the GPC unit/module).
I have tried;
module sysutils interface; export sysutils = all; import GPC; system;
blah, blah; end. module sysutils implementation;
blah blah; end.
I am getting errors (such as "unknown identifier `TString'", "unknown identifier `UnixTimeType'", etc).
Any ideas?
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:
I have a problem. I don't want to export everything. I only want to export things in the current interface section (and there are hundreds of them, and a few of them are routines from the GPC unit/module).
I have tried;
module sysutils interface; export sysutils = all; import GPC; system;
blah, blah; end. module sysutils implementation;
blah blah; end.
I am getting errors (such as "unknown identifier `TString'", "unknown identifier `UnixTimeType'", etc).
Any ideas?
Imports in an interface module are not visible in the corresponding implementation module. But they are visible in the implementation when using a "simple" module like this:
module sysutils; export sysutils = all; import GPC; System;
end;
var a: TString;
end.
At least that's GPC's current behaviour. Perhaps the EP experts can confirm whether this is correct?
Frank
Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
I have a problem. I don't want to export everything. I only want to export things in the current interface section (and there are hundreds of them, and a few of them are routines from the GPC unit/module).
I have tried;
module sysutils interface; export sysutils = all; import GPC; system;
blah, blah; end. module sysutils implementation;
blah blah; end.
I am getting errors (such as "unknown identifier `TString'", "unknown identifier `UnixTimeType'", etc).
Any ideas?
Imports in an interface module are not visible in the corresponding implementation module. But they are visible in the implementation when using a "simple" module like this:
module sysutils; export sysutils = all; import GPC; System;
end;
var a: TString;
end.
At least that's GPC's current behaviour. Perhaps the EP experts can confirm whether this is correct?
Unless I'm missing something, I think paragraph 6.2.2.12, "Each defining-point that has as a region a module-heading shall also have as a region the module-block that is associated with that module-heading.", requires imports into a "separated" module-heading to be treated just the same as your "simple" module case.
Since the paragraph 6.11.3 language, "Each defining-point of an imported identifier occurring within an import-specification shall be for the region that is the import-specification, and, if an access-qualifier does not occur in the import- specification, also for the region that is the module-heading, module-block, or block closest-containing the import-specification.", creates defining-points for imported identifiers in the module-heading region including the "separated" module-heading case, 6.2.2.12 will in turn require those defining-points to exist in the "separated" module-block region.
If, as indicated, GPC doesn't make heading imports "visible" in the corresponding implementation block, then GPC isn't in full conformance with ISO 10206 requirements.
As Prof Olowofoyeku's experience indicates, if identifiers visible in the separate module-heading aren't automatically visible in the separate module-block, creating the implementation for an interface becomes more troublesome. I think the most troublesome aspect is not having the imported type-identifiers used in defining the interface automatically visible when defining the corresponding implementation.
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
Imports in an interface module are not visible in the corresponding implementation module. But they are visible in the implementation when using a "simple" module like this:
module sysutils; export sysutils = all; import GPC; System;
end;
var a: TString;
end.
At least that's GPC's current behaviour. Perhaps the EP experts can confirm whether this is correct?
Unless I'm missing something, I think paragraph 6.2.2.12, "Each defining-point that has as a region a module-heading shall also have as a region the module-block that is associated with that module-heading.", requires imports into a "separated" module-heading to be treated just the same as your "simple" module case.
If, as indicated, GPC doesn't make heading imports "visible" in the corresponding implementation block, then GPC isn't in full conformance with ISO 10206 requirements.
I'll fix it in the next release (chief47*.pas).
Frank
Some time ago, I wrote:
Gale Paeper wrote:
Imports in an interface module are not visible in the corresponding implementation module. But they are visible in the implementation when using a "simple" module like this:
module sysutils; export sysutils = all; import GPC; System;
end;
var a: TString;
end.
At least that's GPC's current behaviour. Perhaps the EP experts can confirm whether this is correct?
Unless I'm missing something, I think paragraph 6.2.2.12, "Each defining-point that has as a region a module-heading shall also have as a region the module-block that is associated with that module-heading.", requires imports into a "separated" module-heading to be treated just the same as your "simple" module case.
If, as indicated, GPC doesn't make heading imports "visible" in the corresponding implementation block, then GPC isn't in full conformance with ISO 10206 requirements.
I'll fix it in the next release (chief47*.pas).
While trying to do so, I found the following program in the test suite. That's wrong then, i.e., the second `import' has to be removed, right?
module nick1m2 interface; export nick1m2 = all; import nick1m1;
[...]
end.
module nick1m2 implementation; import nick1m1;
[...]
end.
Frank
Frank Heckenbach wrote:
Some time ago, I wrote:
Gale Paeper wrote:
Imports in an interface module are not visible in the corresponding implementation module. But they are visible in the implementation when using a "simple" module like this:
module sysutils; export sysutils = all; import GPC; System;
end;
var a: TString;
end.
At least that's GPC's current behaviour. Perhaps the EP experts can confirm whether this is correct?
Unless I'm missing something, I think paragraph 6.2.2.12, "Each defining-point that has as a region a module-heading shall also have as a region the module-block that is associated with that module-heading.", requires imports into a "separated" module-heading to be treated just the same as your "simple" module case.
If, as indicated, GPC doesn't make heading imports "visible" in the corresponding implementation block, then GPC isn't in full conformance with ISO 10206 requirements.
I'll fix it in the next release (chief47*.pas).
While trying to do so, I found the following program in the test suite. That's wrong then, i.e., the second `import' has to be removed, right?
module nick1m2 interface; export nick1m2 = all; import nick1m1;
[...]
end.
module nick1m2 implementation; import nick1m1;
[...]
end.
You're correct in that the test program is wrong in having a module-heading imported interface-identifier repeated in the corresponding module-block import-specification. As presently written, the compiler should generate some kind of multiple definition error when it sees the second "nick1m1" import in the module nick1m2 implementation; code block.
Per paragraph 6.11.3, there is a imported-interface-identifier defining point for "nick1m1" in the module-heading region. Since paragraph 6.2.2.12 also puts that defining point in the module-block region, the "only one defining point per identifier spelling per region" requirement of paragraph 6.2.2.7 prohits having a import-specification in the module-block with a interface-identifier with the same speclling as "nick1m1". (Note: Paragraph 6.2.2.7 has an exemption for imported identifiers meeting certain requirements; however, imported-interface-identifiers don't fall within the exemption criteria.)
In fixing the test program, I think it would be a good idea to end up with two test programs. One which is fixed to be a legal Pascal program which performs the intended test of the original program. And a second one which specifically tests that the compiler will detect and fail this sort of module-heading and module-block inport interface-identifier duplication error.
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
Frank Heckenbach wrote:
While trying to do so, I found the following program in the test suite. That's wrong then, i.e., the second `import' has to be removed, right?
module nick1m2 interface; export nick1m2 = all; import nick1m1;
[...]
end.
module nick1m2 implementation; import nick1m1;
[...]
end.
You're correct in that the test program is wrong in having a module-heading imported interface-identifier repeated in the corresponding module-block import-specification. As presently written, the compiler should generate some kind of multiple definition error when it sees the second "nick1m1" import in the module nick1m2 implementation; code block.
It now says:
nick1m2.pas:13: interface `nick1m1' has already been imported
In fixing the test program, I think it would be a good idea to end up with two test programs. One which is fixed to be a legal Pascal program which performs the intended test of the original program. And a second one which specifically tests that the compiler will detect and fail this sort of module-heading and module-block inport interface-identifier duplication error.
Good idea, thanks. (nick1.pas, nick1b.pas)
Frank
The results below are for gpc-20030507 built with a patched gcc-3.2.1. The testsuite was run with run with EXTRA_PFLAGS=--longjmp-all-nonlocal-labels.
[G4:~] adriaan% make EXTRA_PFLAGS=--longjmp-all-nonlocal-labels
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed with 3 *** malloc[20946]: error: Can't allocate region *** malloc: vm_allocate(size=2147483648) failed with 3 *** malloc[20946]: error: Can't allocate region OK
# of GPC tests 3594 # of GPC tests passed 3578 # of GPC tests skipped 15 # of GPC tests failed 1
This only leaves the Mac OS X malloc bug, I will do some more malloc tests and report the results to Apple.
The test results show that the non-local goto gcc bug has been successfully worked around by the new option --longjmp-all-nonlocal-labels.
Regards,
Adriaan van Os.
Adriaan van Os wrote:
The results below are for gpc-20030507 built with a patched gcc-3.2.1. The testsuite was run with run with EXTRA_PFLAGS=--longjmp-all-nonlocal-labels.
[G4:~] adriaan% make EXTRA_PFLAGS=--longjmp-all-nonlocal-labels
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed with 3 *** malloc[20946]: error: Can't allocate region *** malloc: vm_allocate(size=2147483648) failed with 3 *** malloc[20946]: error: Can't allocate region OK
# of GPC tests 3594 # of GPC tests passed 3578 # of GPC tests skipped 15 # of GPC tests failed 1
This only leaves the Mac OS X malloc bug, I will do some more malloc tests and report the results to Apple.
The test results show that the non-local goto gcc bug has been successfully worked around by the new option --longjmp-all-nonlocal-labels.
Great! Thanks for the report.
BTW, did you check that the bug occurs without `--longjmp-all-nonlocal-labels', i.e. that the options really makes the change?
Frank
Frank Heckenbach wrote:
The test results show that the non-local goto gcc bug has been successfully worked around by the new option --longjmp-all-nonlocal-labels.
Great! Thanks for the report.
BTW, did you check that the bug occurs without `--longjmp-all-nonlocal-labels', i.e. that the options really makes the change?
I did, see below.
Regards,
Adriaan van Os.
---------
[G4:~/gnu/testgpc/test-20030507] adriaan% make
TEST fjf558m.pas: O./test_run: line 202: 17822 Bus error ./"$A_OUT" "$1" TEST fjf558n.pas: O./test_run: line 202: 17842 Bus error ./"$A_OUT" "$1" TEST fjf558o.pas: O./test_run: line 202: 17863 Bus error ./"$A_OUT" "$1" TEST fjf558p.pas: O./test_run: line 202: 17883 Bus error ./"$A_OUT" "$1" TEST fproc.pas: 9c9,11 < ./test_run: line 191: 6450 Bus error ./"$A_OUT" "$1" ---
Stack frame: 8 formal print = -1 formal routine = -1 Stack frame: 9 formal print = -1 formal routine = -1 Stack frame: 10 formal print = -1 formal routine = -1
failed TEST goto5.pas: O./test_run: line 202: 6731 Bus error ./"$A_OUT" "$1" TEST nlgpp.pas: ./test_run: line 202: 11509 Bus error ./"$A_OUT" "$1" TEST nlgpp2.pas: 14c14,30 < ./test_run: line 191: 11529 Bus error ./"$A_OUT" "$1" ---
OK Recursive end 3 True Recursive before goto 4 True Recursive end 4 True Recursive before goto 5 True Recursive end 5 True Recursive before goto 6 True Recursive end 6 True Recursive before goto 7 True Recursive end 7 True Recursive before goto 8 True Recursive end 8 True Recursive before goto 9 True Recursive end 9 True Recursive before goto 10 True Recursive end 10 True Main end
failed TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed with 3 *** malloc[17286]: error: Can't allocate region *** malloc: vm_allocate(size=2147483648) failed with 3 *** malloc[17286]: error: Can't allocate region OK
# of GPC tests 3594 # of GPC tests passed 3570 # of GPC tests skipped 15 # of GPC tests failed 9
Adriaan van Os wrote:
Frank Heckenbach wrote:
The test results show that the non-local goto gcc bug has been successfully worked around by the new option --longjmp-all-nonlocal-labels.
Great! Thanks for the report.
BTW, did you check that the bug occurs without `--longjmp-all-nonlocal-labels', i.e. that the options really makes the change?
I did, see below.
OK, so it really achieves what it should. :-) (I couldn't test it in the critical situation, that's why I asked ...)
Frank
Adriaan van Os wrote:
... snip ...
This only leaves the Mac OS X malloc bug, I will do some more malloc tests and report the results to Apple.
I have no idea what the OS X malloc bug is, but I have a malloc system available that only relies on the availability of the sbrk call to function, and assumes byte addressability. I believe it to be highly portable to unices. To inject into something I simply link it before the standard library. You can also have a herd of malloc system debugging abilities. Compiles with gcc, and uses gcc varargs macros. To try it out:
http://cbfalconer.home.att.net/download/nmalloc.zip
(It specifically rejects a malloc request of about 2 Gb up)
I built it because the existing DJGPP malloc makes free and realloc O(N) operations where N is the number of free blocks. This in turn makes freeing a large group of blocks O(N*N). nmalloc changes O(N) to O(1) and ON*N) to O(N). The original became impossible in the 50 to 100k free blocks area. VC6 and LCC-Win32 have the same fault. It also reduces memory movement in realloc. I have had no problems over the past year with it, and a few others have been using it. We hope to get it into the next alpha of DJGPP 2.04.
CBFalconer wrote:
Adriaan van Os wrote:
... snip ...
This only leaves the Mac OS X malloc bug, I will do some more malloc tests and report the results to Apple.
I have no idea what the OS X malloc bug is, but I have a malloc system available that only relies on the availability of the sbrk call to function, and assumes byte addressability. I believe it to be highly portable to unices. To inject into something I simply link it before the standard library. You can also have a herd of malloc system debugging abilities. Compiles with gcc, and uses gcc varargs macros. To try it out:
I have downloaded it and will give it a try.
(It specifically rejects a malloc request of about 2 Gb up)
I built it because the existing DJGPP malloc makes free and realloc O(N) operations where N is the number of free blocks. This in turn makes freeing a large group of blocks O(N*N). nmalloc changes O(N) to O(1) and ON*N) to O(N). The original became impossible in the 50 to 100k free blocks area. VC6 and LCC-Win32 have the same fault. It also reduces memory movement in realloc. I have had no problems over the past year with it, and a few others have been using it. We hope to get it into the next alpha of DJGPP 2.04.
O(N*N) is, of course, inacceptable. Memory allocation in the Win32 API, by the way, is astonishingly slow (which is why Delphi comes with a Runtime Library Memory Manager Unit).
CBFalconer wrote:
Adriaan van Os wrote:
... snip ...
TEST fjf31.pas: failed: 2, 2, 1
TEST pack1.pas: failed
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed
Of course it did. malloc of that size would require a sbrk with a negative size (even though sbrk is specified to take an unsigned). That would reduce the heap space available, and create havoc.
Yeah, 2147483648 = $80000000 and possibly negative, but the original request in systemtest.pas was just below 2GiB. Probably malloc rounds it up to an integral number of pages.
(gdb) bt #0 $90006a34 in mig_get_reply_port () #1 $90008858 in vm_allocate () #2 $9000877c in allocate_pages () #3 $9001012c in large_and_huge_malloc () #4 $90004e98 in szone_malloc () #5 $90004a44 in malloc_zone_malloc () #6 $000036a0 in Bpgetmem (Size=2147483391) at /Developer/Pascal/gpc321d17/lib/gcc-lib/powerpc-apple-darwin6.4/3.2.1/ units/system.pas:546 #7 $000144a0 in _p_New (Size=2147483391) at /Users/adriaan/gnu/gpc-20030507-2/gcc/p/rts/heap.pas:237 #8 $000050b4 in Test () at systemtest.pas:41 #9 $00005280 in pascal_main_program () at systemtest.pas:63 #10 $00005344 in main (argc=1, argv=$bffffdd8, envp=$bffffde0) at <implicit code>:63 #11 $00002724 in _start (argc=1, argv=$bffffdd8, envp=$bffffde0) at /SourceCache/Csu/Csu-45/crt.c:267 #12 $000025a4 in start ()
Regards,
Adriaan van Os
Adriaan van Os wrote:
CBFalconer wrote:
... snip ...
Of course it did. malloc of that size would require a sbrk with a negative size (even though sbrk is specified to take an unsigned). That would reduce the heap space available, and create havoc.
Yeah, 2147483648 = $80000000 and possibly negative, but the original request in systemtest.pas was just below 2GiB. Probably malloc rounds it up to an integral number of pages.
The threshold in nmalloc is (INT_MAX - 65536) after rounding. Just a little safety margin.
The results below are for gpc-20030507 built with a patched gcc-3.2.1. The testsuite was run with run with EXTRA_PFLAGS="--longjmp-all-nonlocal-labels --maximum-field-alignment=16".
TEST bitsizes.pas: failed
TEST dialec3.pas: [same for dialec5.pas, dialec6.pas, dostest.pas, dostest2.pas, windtes2.pas, windtest.pas and y2k.pas] /Developer/Pascal/gpc321d17/lib/gcc-lib/powerpc-apple-darwin6.4/3.2.1/ units/dos.pas: In procedure `CloseFind': /Developer/Pascal/gpc321d17/lib/gcc-lib/powerpc-apple-darwin6.4/3.2.1/ units/dos.pas:401: cast to type of different size /Developer/Pascal/gpc321d17/lib/gcc-lib/powerpc-apple-darwin6.4/3.2.1/ units/dos.pas: In procedure `FindFirst': /Developer/Pascal/gpc321d17/lib/gcc-lib/powerpc-apple-darwin6.4/3.2.1/ units/dos.pas:435: cast to type of different size /Developer/Pascal/gpc321d17/lib/gcc-lib/powerpc-apple-darwin6.4/3.2.1/ units/dos.pas:440: cast to type of different size /Developer/Pascal/gpc321d17/lib/gcc-lib/powerpc-apple-darwin6.4/3.2.1/ units/dos.pas: In procedure `FindNext': /Developer/Pascal/gpc321d17/lib/gcc-lib/powerpc-apple-darwin6.4/3.2.1/ units/dos.pas:474: cast to type of different size gpc1: gpc exited with status 1 failed
TEST fjf31.pas: failed: 2, 2, 1
TEST pack1.pas: failed
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed with 3 *** malloc[24421]: error: Can't allocate region *** malloc: vm_allocate(size=2147483648) failed with 3 *** malloc[24421]: error: Can't allocate region OK
# of GPC tests 3594 # of GPC tests passed 3567 # of GPC tests skipped 15 # of GPC tests failed 12
Regards,
Adriaan van Os
Adriaan van Os wrote:
... snip ...
TEST fjf31.pas: failed: 2, 2, 1
TEST pack1.pas: failed
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed
Of course it did. malloc of that size would require a sbrk with a negative size (even though sbrk is specified to take an unsigned). That would reduce the heap space available, and create havoc.
CBFalconer wrote:
Adriaan van Os wrote:
... snip ...
TEST fjf31.pas: failed: 2, 2, 1
TEST pack1.pas: failed
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed
Of course it did. malloc of that size would require a sbrk with a negative size (even though sbrk is specified to take an unsigned). That would reduce the heap space available, and create havoc.
Yes, it will fail, but it should return a nil pointer then, rather than aborting the program and writing an error on its own. AFAIK, that's the required behaviour in standard C (which makes sense -- imagine an interactive program or a long calculation just aborted, without giving the programmer any chance to clean up). And that's just what this test tests.
Frank
Frank Heckenbach wrote:
CBFalconer wrote:
Adriaan van Os wrote:
... snip ...
TEST fjf31.pas: failed: 2, 2, 1
TEST pack1.pas: failed
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed
Of course it did. malloc of that size would require a sbrk with a negative size (even though sbrk is specified to take an unsigned). That would reduce the heap space available, and create havoc.
Yes, it will fail, but it should return a nil pointer then, rather than aborting the program and writing an error on its own. AFAIK, that's the required behaviour in standard C (which makes sense -- imagine an interactive program or a long calculation just aborted, without giving the programmer any chance to clean up). And that's just what this test tests.
To be sure, I asked on an Apple mailing list some time ago. They confirmed that the intended behaviour of malloc is to return nil instead.
Regards,
Adriaan van Os
Frank Heckenbach wrote:
CBFalconer wrote:
Adriaan van Os wrote:
... snip ...
TEST fjf31.pas: failed: 2, 2, 1
TEST pack1.pas: failed
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed
Of course it did. malloc of that size would require a sbrk with a negative size (even though sbrk is specified to take an unsigned). That would reduce the heap space available, and create havoc.
Yes, it will fail, but it should return a nil pointer then, rather than aborting the program and writing an error on its own. AFAIK, that's the required behaviour in standard C (which makes sense -- imagine an interactive program or a long calculation just aborted, without giving the programmer any chance to clean up). And that's just what this test tests.
Then he should try my nmalloc, as I posted earlier. That's just what it will do.
CBFalconer wrote:
Frank Heckenbach wrote:
CBFalconer wrote:
Adriaan van Os wrote:
... snip ...
TEST fjf31.pas: failed: 2, 2, 1
TEST pack1.pas: failed
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed
Of course it did. malloc of that size would require a sbrk with a negative size (even though sbrk is specified to take an unsigned). That would reduce the heap space available, and create havoc.
Yes, it will fail, but it should return a nil pointer then, rather than aborting the program and writing an error on its own. AFAIK, that's the required behaviour in standard C (which makes sense -- imagine an interactive program or a long calculation just aborted, without giving the programmer any chance to clean up). And that's just what this test tests.
Then he should try my nmalloc, as I posted earlier. That's just what it will do.
I suppose it should work. BTW, have you run the GPC tests under DJGPP with nmalloc?
Frank
Frank Heckenbach wrote:
... snip ..
I suppose it should work. BTW, have you run the GPC tests under DJGPP with nmalloc?
No.
Adriaan van Os wrote:
The results below are for gpc-20030507 built with a patched gcc-3.2.1. The testsuite was run with run with EXTRA_PFLAGS="--longjmp-all-nonlocal-labels --maximum-field-alignment=16".
TEST dialec3.pas: [same for dialec5.pas, dialec6.pas, dostest.pas, dostest2.pas, windtes2.pas, windtest.pas and y2k.pas]
Insert `{$maximum-field-alignment 0}' in dos.pas and windos.pas.
TEST bitsizes.pas: failed
TEST fjf31.pas: failed: 2, 2, 1
TEST pack1.pas: failed
These tests test the size of packed records which is affected by maximum-field-alignment. So I think we should just insert `{$maximum-field-alignment 0}' in those tests as well, do you agree?
Frank
Frank Heckenbach wrote:
TEST bitsizes.pas: failed
TEST fjf31.pas: failed: 2, 2, 1
TEST pack1.pas: failed
These tests test the size of packed records which is affected by maximum-field-alignment. So I think we should just insert `{$maximum-field-alignment 0}' in those tests as well, do you agree?
The question is whether a maximum-field-alignment (command line or compiler) option should have any effect on packed types. I didn't think about that case before, but my answer to that question is "no".
Var R: packed record a: Boolean; b: 1..3; end;
Use of "packed" could imply a local maximum-field-alignment=8 (or 0) for the type, so that always SizeOf( R) = 1.
Any other opinions ?
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
TEST bitsizes.pas: failed
TEST fjf31.pas: failed: 2, 2, 1
TEST pack1.pas: failed
These tests test the size of packed records which is affected by maximum-field-alignment. So I think we should just insert `{$maximum-field-alignment 0}' in those tests as well, do you agree?
The question is whether a maximum-field-alignment (command line or compiler) option should have any effect on packed types. I didn't think about that case before, but my answer to that question is "no".
Var R: packed record a: Boolean; b: 1..3; end;
Use of "packed" could imply a local maximum-field-alignment=8 (or 0) for the type, so that always SizeOf( R) = 1.
Any other opinions ?
I don't use maximum-field-alignment myself, so I don't care much either way. BP compatibility should be of no concern either if they use `--ignore-packed' anyway.
So if there's consensus, I think I can change it.
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
TEST bitsizes.pas: failed
TEST fjf31.pas: failed: 2, 2, 1
TEST pack1.pas: failed
These tests test the size of packed records which is affected by maximum-field-alignment. So I think we should just insert `{$maximum-field-alignment 0}' in those tests as well, do you agree?
The question is whether a maximum-field-alignment (command line or compiler) option should have any effect on packed types. I didn't think about that case before, but my answer to that question is "no".
Var R: packed record a: Boolean; b: 1..3; end;
Use of "packed" could imply a local maximum-field-alignment=8 (or 0) for the type, so that always SizeOf( R) = 1.
Any other opinions ?
I don't use maximum-field-alignment myself, so I don't care much either way. BP compatibility should be of no concern either if they use `--ignore-packed' anyway.
So if there's consensus, I think I can change it.
Before you change it, I think some more investigation is needed to see what effect it will have on the packed types layouts found in Apple's Pascal Universal Interfaces.
In essense, maximum-field-alignment was a solution hack to get the correct type layout alignments needed for interfacing with Mac OS X when using a GPC compatible translation of Apple's Pascal Interfaces. Since the hack seems to be working for Mac OS X, I wouldn't like to see it break as a result of a change "fixing" something unrelated to Mac OS X interfacing.
Gale Paeper gpaeper@empirenet.com
At 22:03 -0700 12/5/03, Gale Paeper wrote:
The question is whether a maximum-field-alignment (command line or compiler) option should have any effect on packed types. I didn't think about that case before, but my answer to that question is "no".
Var R: packed record a: Boolean; b: 1..3; end;
Use of "packed" could imply a local maximum-field-alignment=8 (or 0) for the type, so that always SizeOf( R) = 1.
Any other opinions ?
I don't use maximum-field-alignment myself, so I don't care much either way. BP compatibility should be of no concern either if they use `--ignore-packed' anyway.
So if there's consensus, I think I can change it.
Before you change it, I think some more investigation is needed to see what effect it will have on the packed types layouts found in Apple's Pascal Universal Interfaces.
In essense, maximum-field-alignment was a solution hack to get the correct type layout alignments needed for interfacing with Mac OS X when using a GPC compatible translation of Apple's Pascal Interfaces. Since the hack seems to be working for Mac OS X, I wouldn't like to see it break as a result of a change "fixing" something unrelated to Mac OS X interfacing.
The change sounds fine to me. Traditional Mac Pascals treat packed fairly well and will align most things on byte boundaries (or less for booleans). I suspect most of the packed records in the interfaces are there only because Byte (Cardinal(8)) is normally two bytes long (don't ask), and so the use of a sensible UInt8 probably resolves the problems anyway.
The combination of maximum-field-alignment and packed records should allow us to easily ensure records are correctly aligned, so I'd say go ahead with the changes as described - packed should override maximum-field-alignment.
Enjoy, Peter.
Peter N Lewis wrote:
At 22:03 -0700 12/5/03, Gale Paeper wrote:
The question is whether a maximum-field-alignment (command line or compiler) option should have any effect on packed types. I didn't think about that case before, but my answer to that question is "no".
Var R: packed record a: Boolean; b: 1..3; end;
Use of "packed" could imply a local maximum-field-alignment=8 (or 0) for the type, so that always SizeOf( R) = 1.
Any other opinions ?
I don't use maximum-field-alignment myself, so I don't care much either way. BP compatibility should be of no concern either if they use `--ignore-packed' anyway.
So if there's consensus, I think I can change it.
Before you change it, I think some more investigation is needed to see what effect it will have on the packed types layouts found in Apple's Pascal Universal Interfaces.
In essense, maximum-field-alignment was a solution hack to get the correct type layout alignments needed for interfacing with Mac OS X when using a GPC compatible translation of Apple's Pascal Interfaces. Since the hack seems to be working for Mac OS X, I wouldn't like to see it break as a result of a change "fixing" something unrelated to Mac OS X interfacing.
The change sounds fine to me. Traditional Mac Pascals treat packed fairly well and will align most things on byte boundaries (or less for booleans). I suspect most of the packed records in the interfaces are there only because Byte (Cardinal(8)) is normally two bytes long (don't ask), and so the use of a sensible UInt8 probably resolves the problems anyway.
The combination of maximum-field-alignment and packed records should allow us to easily ensure records are correctly aligned, so I'd say go ahead with the changes as described - packed should override maximum-field-alignment.
Does everyone agree to it?
(maximum-field-alignment was implemented mostly because of the Mac interfaces, so if the change won't break anything there, this is probably the most important thing.)
Frank
Frank Heckenbach wrote:
Peter N Lewis wrote:
At 22:03 -0700 12/5/03, Gale Paeper wrote:
The question is whether a maximum-field-alignment (command line or compiler) option should have any effect on packed types. I didn't think about that case before, but my answer to that question is "no".
Var R: packed record a: Boolean; b: 1..3; end;
Use of "packed" could imply a local maximum-field-alignment=8 (or 0) for the type, so that always SizeOf( R) = 1.
Any other opinions ?
I don't use maximum-field-alignment myself, so I don't care much either way. BP compatibility should be of no concern either if they use `--ignore-packed' anyway.
So if there's consensus, I think I can change it.
Before you change it, I think some more investigation is needed to see what effect it will have on the packed types layouts found in Apple's Pascal Universal Interfaces.
In essense, maximum-field-alignment was a solution hack to get the correct type layout alignments needed for interfacing with Mac OS X when using a GPC compatible translation of Apple's Pascal Interfaces. Since the hack seems to be working for Mac OS X, I wouldn't like to see it break as a result of a change "fixing" something unrelated to Mac OS X interfacing.
The change sounds fine to me. Traditional Mac Pascals treat packed fairly well and will align most things on byte boundaries (or less for booleans). I suspect most of the packed records in the interfaces are there only because Byte (Cardinal(8)) is normally two bytes long (don't ask), and so the use of a sensible UInt8 probably resolves the problems anyway.
The combination of maximum-field-alignment and packed records should allow us to easily ensure records are correctly aligned, so I'd say go ahead with the changes as described - packed should override maximum-field-alignment.
Does everyone agree to it?
In some testing on the effect of maximum-field-alignment on Mac interfaces packed types, I've found a few packed types whose size changes between $maximum-field-alignment=16 and the built-in PPC compiler default. However, I also found that for some of those changing size types, the $maximum-field-alignment=16 type size doesn't match up with MAC68K alignment size obtained with CodeWarrior Pascal and THINK Pascal. When taken together, I think this indicates the root cause of the changing type sizes in those cases is due to a fundamental difference in the GPC/gcc type layout algorithm which isn't directly controllable with the maximum-field-alignment setting.
Since it is just a couple of packed types in the Mac interfaces and the size differences may not turn out to be of any importance upon more detailed investigation, I think the best way to work the changing size problem on those Mac interface types is through tweaking the few affected type declarations in the interfaces if it turns out necessary to do so. (I think the problem is with record alignment rather than field alignment which can be fixed with explict pad field declarations where MAC68K alignment implictly pads to achieve record alignment requirements.)
(maximum-field-alignment was implemented mostly because of the Mac interfaces, so if the change won't break anything there, this is probably the most important thing.)
For the vast majority of the packed types in the Mac interfaces, further investigation shows Peter's assessment of the effect of maximum-field-alignment on packed data types was correct. Therefore, I no longer have any reservations about the change.
P.S. Since I don't think it would be of interest to the wider GPC audience, I didn't get into the details of the differences. Once I complete a few more investigations, I'll following up with the folks working on the Mac interfaces (e.g., Peter and Adriaan) on the nature of the problem and what interface changes, if any, are needed for correct interfacing functionality.
Gale Paeper gpaeper@empirenet.com
At 8:52 PM -0700 17/5/03, Gale Paeper wrote:
Since it is just a couple of packed types in the Mac interfaces and the size differences may not turn out to be of any importance upon more detailed investigation, I think the best way to work the changing size problem on those Mac interface types is through tweaking the few affected type declarations in the interfaces if it turns out necessary to do so. (I think the problem is with record alignment rather than field alignment which can be fixed with explict pad field declarations where MAC68K alignment implictly pads to achieve record alignment requirements.)
Yep, that was my conclusion. Also, a bunch of the differences are actually bogus, for example, under MAC68K and GPC alignment, records like this:
type rec = record a: UInt32; b: UInt32; extradatalength: UInt32; extradata: UInt8; end;
where extradata is actually just a placeholder to indicate an arbitrary amount of extra data, MAC68K would align the size at a multiple of 2 bytes, (so 14 for the above) whereas GPC would size them as 13 bytes). However no one would ever actually use either of these sizes or ever declare such a record explicitly, so the difference does not matter.
P.S. Since I don't think it would be of interest to the wider GPC audience, I didn't get into the details of the differences. Once I complete a few more investigations, I'll following up with the folks working on the Mac interfaces (e.g., Peter and Adriaan) on the nature of the problem and what interface changes, if any, are needed for correct interfacing functionality.
Please do, if you find any tweaking that needs to be done. I've already gone through all the records that don't exactly match the sizes under 68K and GPC (with the addition of the maximum-field-alignment option, this dropped to quite a small number), and convinced myself that there were no actual problematic cases left. However if you find any, please do let us know since otherwise the only way they will be found is with very confused programmers getting very weird results! Quite an ugly one to track down! Peter.
Gale Paeper wrote:
Frank Heckenbach wrote:
Peter N Lewis wrote:
At 22:03 -0700 12/5/03, Gale Paeper wrote:
Use of "packed" could imply a local maximum-field-alignment=8 (or 0) for the type, so that always SizeOf( R) = 1.
So if there's consensus, I think I can change it.
The change sounds fine to me.
The combination of maximum-field-alignment and packed records should allow us to easily ensure records are correctly aligned, so I'd say go ahead with the changes as described - packed should override maximum-field-alignment.
As there seems to be agreement, I'll do this in the next version.
Frank
Frank Heckenbach a écrit:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
I have compiled it with djgpp and uploaded in the usual directory, both with gcc-2.95.3 and gcc-3.2.2.
No error in the test suite with gcc-3.2.2 and no EXTRA_TEST_PFLAGS, so with presubably the default dwarf-2 debugging, which works now.
No error with gcc-2.95.3 and no EXTRA_TEST_PFLAGS 8 errors with gcc-2.95.3 and EXTRA_TEST_PFLAGS=-gstabs This is not the default with djgpp (it is COFF debugging), but I use it in my work since some time, since the information given is better. All errors are variants of the same assembly bug. The test_summary is attached. May be it is time to recommend to switch to gcc-3.2.2 ?
Maurice
Maurice Lombardi wrote:
Frank Heckenbach a écrit:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
I have compiled it with djgpp and uploaded in the usual directory, both with gcc-2.95.3 and gcc-3.2.2.
No error in the test suite with gcc-3.2.2 and no EXTRA_TEST_PFLAGS, so with presubably the default dwarf-2 debugging, which works now.
No error with gcc-2.95.3 and no EXTRA_TEST_PFLAGS 8 errors with gcc-2.95.3 and EXTRA_TEST_PFLAGS=-gstabs This is not the default with djgpp (it is COFF debugging), but I use it in my work since some time, since the information given is better. All errors are variants of the same assembly bug. The test_summary is attached. May be it is time to recommend to switch to gcc-3.2.2 ?
Yes, I think we can recommend it now. There don't appear any major bugs left, and if there are more subtle ones, they're probably uncovered by wider deployment.
So I wouldn't object if you put up the binary for 3.2.2 only (or more prominently than 2.95.3). I might do the same for the Linux binary soon).
Frank
Hi,
there's something wrong with tokenization in the current snapshot:
[pas]% cat tst.pas program foo (input);
begin while input^in [' ', "\t"] do get (input) end. [pas]% gpc -v Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/specs Configured with: ../gcc-3.2.1/configure --enable-languages=pascal --disable-nls Thread model: posix gpc version 20030507, based on gcc-3.2.1 [pas]% gpc tst.pas tst.pas: In main program: tst.pas:4: warning: missing white space after character constant tst.pas:4: condition must be of Boolean type tst.pas:4: parse error before character #9 tst.pas:4: undeclared identifier `n' (first use in this routine) tst.pas:4: (Each undeclared identifier is reported only once tst.pas:4: for each routine it appears in.) tst.pas:4: parse error before `do' tst.pas:6: expression used as a statement -- value is ignored tst.pas:6: confused by earlier errors, bailing out
Emil
Emil Jerabek wrote:
there's something wrong with tokenization in the current snapshot:
[pas]% cat tst.pas program foo (input);
begin while input^in [' ', "\t"] do get (input) end.
Will be fixed in the next release (emil25.pas). (It's due to those stupid BP `^n' character constants.)
Frank
Hi Frank!
On Wed, May 07, 2003 at 08:22:58PM +0200, Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
Thank you, it works well with GNU/Linux.
- new attributes `iocritical' (fjf824*.pas), `ignorable' (fjf839*.pas) for routines
I really like this feature (`ignorable')!
Eike
Eike Lange wrote:
Hi Frank!
On Wed, May 07, 2003 at 08:22:58PM +0200, Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
Thank you, it works well with GNU/Linux.
- new attributes `iocritical' (fjf824*.pas), `ignorable' (fjf839*.pas) for routines
I really like this feature (`ignorable')!
BTW, this attribute can probably be added to a number of routines in the RTS and the units. I don't have the time for this now, but you might want to add them ...
Frank
-
Adriaan van Os -
CBFalconer -
Eike Lange -
Emil Jerabek -
Frank Heckenbach -
Gale Paeper -
Jaroslaw J. Pyszny -
Maurice Lombardi -
Peter N Lewis -
Prof A Olowofoyeku (The African Chief)