I've uploaded a new alpha version. Besides many internal cleanups (again) and bugfixes (thanks especially to Artur Zaroda for many reports), one new feature is to preserve the case of identifiers in error messages etc. and an optional warning for varying cases.
GPC now installs the two utilites `binobj' and `gpidump' (with man pages if the program `help2man' is available at build time). However, since `binobj' is a BP compatiblity utility, and `gpidump' is mostly useful for debugging and understanding GPC internals, these programs might not be too useful to most GPC users. Those who build GPC packages of some kind, please note the new files.
The structure of the homepage has changed. (It is now generated using `makeinfo --html' instead of `texi2html'.) Since many file names are different now, your links and bookmarks might break, but if you start from the home page, you should be able to find anything again. (Except for the info and texi versions of the to-do list which have been dropped from the home page. They're still contained in GPC source (info and texi) and binary (only info) distributions, and the HTML version is on the home page.)
Furthermore, each page now contains an input form at the bottom where everyone can enter their additions. This was inspired by a discussion on gpc-doc. We hope this will encourage more contributions to the documentation. BTW, the source code of the CGI program that handles this input form can be found in my `cgiprogs' package in contrib/frank.
There are some slightly incompatible changes. I hope they won't be a big problem to anyone:
- dropped `--[no-]borland-char-constants' (now simply coupled to dialect options)
- `=' and `<>' comparisons of structures (arrays, records, ...) except strings and sets are forbidden now
- irrelevant operands and arguments (e.g. `foo in []'; `bar * []'; `Im (baz)' if `baz' is of real type) are not necessarily evaluated anymore (which is allowed by the standard); instead, a warning is given if they have side-effects
- only one program, unit, module interface or implementation or a module interface and the implementation of the same module are accepted in one source file; new options `--[no-]ignore-garbage-after-dot' (fjf735*.pas)
- dropped the usage of `GetMem' as a function with one parameter (only the BP compatible usage as a procedure with two parameters remains). (Both are semantically equivalent, so if you used the function syntax, you'll only have to make a minor change in your code, possibly using a new variable.)
- accessing the variable `FileMode' now requires using the `GPC' (or, for BP compatibility, the `System') unit
- routines declared in a program or module/unit implementation, with an `asmname' or `attribute' specification must now be marked `forward' explicitly (not so in an interface since those declarations are always forward if not external).
E.g., previously:
procedure Foo; asmname 'Bar'; procedure Foo; begin end;
Now (note, this way also works with previous GPC versions):
procedure Foo; asmname 'Bar'; forward; procedure Foo; begin end;
The `asmname' etc. stuff is still quite confusing and unlogical (otherwise, you shouldn't need the two declarations at all), but at least now `forward' should work regularly.
Frank
Frank Heckenbach wrote:
I've uploaded a new alpha version.
The new alpha gpc-20030209 bootstraps on Mac OS X (with previously discussed patches to gcc-3.2.1).
[G4:~] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc321d6/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ specs Configured with: ../gpc-20030209/configure --enable-languages=pascal,c --prefix=/Developer/Pascal/gpc321d6 Thread model: single gpc version 20030209, based on gcc-3.2.1
The gpc-20030209 test suite, however, produces strange results:
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 20030209, based on gcc-3.2.1 (powerpc-apple-darwin6.3) (G4.local.), 2003-02-10 03:29:38 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 ./adam2u.pas: No such program ./adam2v.pas: No such program TEST agettext2test.pas: SKIPPED: libintl not installed TEST asmtest.pas: SKIPPED: only for IA32 TEST asmtest2.pas: SKIPPED: only for IA32 TEST asmtest3.pas: SKIPPED: only for IA32 ./babyuni2.pas: No such program ./babyunit.pas: No such program ./berend1m.pas: No such program ..... (etcetera)
The gpc-20021128 test suite produces other strange results:
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 20030209, based on gcc-3.2.1 (powerpc-apple-darwin6.3) (G4.local.) echo "gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused -fstack-check " gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused -fstack-check PC="gpc" PFLAGS="--autobuild -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused -fstack-check " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | "./test_sum" TEST adam2.pas: gpc1: warnings being treated as errors adam2v.pas:12: warning: varying case of `aLimit' adam2v.pas:7: warning: other case: `ALimit' adam2v.pas: In constructor `MList.Init': adam2v.pas:14: warning: varying case of `ALimit' adam2v.pas:12: warning: other case: `aLimit' ..... (etcetera)
Regards,
Adriaan van Os
Adriaan van Os wrote:
The new alpha gpc-20030209 bootstraps on Mac OS X (with previously discussed patches to gcc-3.2.1).
Fine. :-)
The gpc-20030209 test suite, however, produces strange results:
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 20030209, based on gcc-3.2.1 (powerpc-apple-darwin6.3) (G4.local.), 2003-02-10 03:29:38 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 ./adam2u.pas: No such program ./adam2v.pas: No such program TEST agettext2test.pas: SKIPPED: libintl not installed TEST asmtest.pas: SKIPPED: only for IA32 TEST asmtest2.pas: SKIPPED: only for IA32 TEST asmtest3.pas: SKIPPED: only for IA32 ./babyuni2.pas: No such program ./babyunit.pas: No such program ./berend1m.pas: No such program ..... (etcetera)
Which command exactly did you run, and from which directory?
If from the build directory, what does <build>/gcc/p/test/Makefile contain? I suppose, `srcdir' is not set correctly there (i.e., to `.' instead of the source directory). If so, there might be a problem with the sed substitution (gcc/p/Make-lang.in:1022) that creates this Makefile -- either with the regex or the sed invocation or pwd or something else ... I don't see a problem now, but if you play around with it, you might be able to find it out. (You'll have to remove <build>/gcc/p/test/Makefile so it's rebuilt when you change something in Make-lang.in.)
The gpc-20021128 test suite produces other strange results:
TEST adam2.pas: gpc1: warnings being treated as errors adam2v.pas:12: warning: varying case of `aLimit' adam2v.pas:7: warning: other case: `ALimit' adam2v.pas: In constructor `MList.Init': adam2v.pas:14: warning: varying case of `ALimit' adam2v.pas:12: warning: other case: `aLimit' ..... (etcetera)
That's not strange. That's the new warning I've suggested here recently (and implemented now). :-)
Frank
On 10 Feb 2003 at 5:33, Frank Heckenbach wrote:
I've uploaded a new alpha version. Besides many internal cleanups (again) and bugfixes (thanks especially to Artur Zaroda for many reports), one new feature is to preserve the case of identifiers in error messages etc. and an optional warning for varying cases.
[...]
A quick report. It compiled okay with gcc-3.2.2 - but I haven't yet run the testsuite.
My Sysutils unit is broken :-( - lots of undefined asmnames (I am sure this can be fixed - but it got me a bit worried). Did you change any asmnames in the GPC and/or Strings units?
Thanks.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/
Prof. A Olowofoyeku (The African Chief) wrote:
The asmnames for many routines in the GPC unit have changed (primarily a change of case). This (because asmnames are case-sensitive) breaks existing units (e.g., Sysutils) that rely on asmnames to work around the absence of qualified identifiers.
Are these case changes likely to be continuous, or are you finished with the changes now? Thanks.
Finished for now (the immediate reason was to let a built-in routine `FooBar' get an asmname `_p_FooBar' which simplifies some things in the compiler), but in the future further changes will likely occur, at least when "asmname mangling" is introduced.
As the note in the GPC unit says:
: This unit contains Pascal declarations of many RTS routines which : are not built into the compiler and can be called from programs. : Don't copy the declarations from this unit into your programs, but : rather include this unit with a `uses' statement. The reason is : that the internal declarations, e.g. the `asmnames', may change, : and this unit will be changed accordingly.
If you just need some declarations from the GPC unit in your units, you might achieve it via `only' imports (see my other mail), possibly with import renaming to avoid name conflicts:
import GPC only (FileMode => GPC_FileMode);
If you also need to re-export some of those declarations, I'll have to think further ...
Frank
On 11 Feb 2003 at 4:15, Frank Heckenbach wrote:
[...]
As the note in the GPC unit says:
: This unit contains Pascal declarations of many RTS routines which : are not built into the compiler and can be called from programs. : Don't copy the declarations from this unit into your programs, but : rather include this unit with a `uses' statement. The reason is : that the internal declarations, e.g. the `asmnames', may change, : and this unit will be changed accordingly.
If you just need some declarations from the GPC unit in your units, you might achieve it via `only' imports (see my other mail), possibly with import renaming to avoid name conflicts:
import GPC only (FileMode => GPC_FileMode);
If you also need to re-export some of those declarations, I'll have to think further ...
That is exactly the problem. As you remember, Delphi's Sysutils is a sort of amalgam of routines from the old BP Strings and Dos units - some are identically named, and some are not. Instead of reinventing the wheel, I just export them using the asmnames. If the asmnames will be changing frequently, this kind of solution becomes a non-starter. Therefore I suggest that asmnames should not be changed until we have qualified identifiers.
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 11 Feb 2003 at 4:15, Frank Heckenbach wrote:
[...]
As the note in the GPC unit says:
: This unit contains Pascal declarations of many RTS routines which : are not built into the compiler and can be called from programs. : Don't copy the declarations from this unit into your programs, but : rather include this unit with a `uses' statement. The reason is : that the internal declarations, e.g. the `asmnames', may change, : and this unit will be changed accordingly.
If you just need some declarations from the GPC unit in your units, you might achieve it via `only' imports (see my other mail), possibly with import renaming to avoid name conflicts:
import GPC only (FileMode => GPC_FileMode);
If you also need to re-export some of those declarations, I'll have to think further ...
That is exactly the problem. As you remember, Delphi's Sysutils is a sort of amalgam of routines from the old BP Strings and Dos units - some are identically named, and some are not. Instead of reinventing the wheel, I just export them using the asmnames. If the asmnames will be changing frequently, this kind of solution becomes a non-starter.
Indeed.
Therefore I suggest that asmnames should not be changed until we have qualified identifiers.
I'm not sure if QI will be a really good solution, either. AFAICS, you'd then need wrapper functions in order to re-export the routines (which you currently don't need, provided the parameters etc. are exactly the same).
OTOH, modules allow for direct re-exporting, optionally with renaming. The following example works with the current GPC:
module Foo;
export Foo = (a, Bar, FileMode => GPC_FileMode);
import GPC;
var a: Integer = 42;
procedure Bar;
end;
procedure Bar; begin WriteLn ('bar') end;
to begin do WriteLn ('qwe');
end.
GPC allows for importing a module with `uses' or `import', just like units, so the user of the module should not notice any difference.
The backdraws (except the module syntax, and a few module bugs which will hopefully be fixed soon), is that you have to name all identifiers to be exported in the `export' clause. Often this will be all interface declarations which have to be repeated there.
GPC supports, as an extension `export Foo = all' which exports all interface declarations -- but only those, i.e., one can't add any re-exports or do any renaming.
But it should be possible with moderate effort to implement something like
export Foo = all (FileMode => GPC_FileMode);
so one won't have to name all interface declarations, but only the re-exports and renamings explicitly.
Frank
On 11 Feb 2003 at 18:40, Frank Heckenbach wrote:
[...]
Therefore I suggest that asmnames should not be changed until we have qualified identifiers.
I'm not sure if QI will be a really good solution, either. AFAICS, you'd then need wrapper functions in order to re-export the routines
Yes, that is what one would need to do with BP/Delphi - and I am happy to do it. But it is currently not an option.
[modules]
But it should be possible with moderate effort to implement something like
export Foo = all (FileMode => GPC_FileMode);
so one won't have to name all interface declarations, but only the re-exports and renamings explicitly.
Ok. I'd rather not touch any EP stuff (e.g., modules) at all. However, if that is going to be the only realistic option, then I guess it would have to do ...
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:
[modules]
But it should be possible with moderate effort to implement something like
export Foo = all (FileMode => GPC_FileMode);
so one won't have to name all interface declarations, but only the re-exports and renamings explicitly.
Ok. I'd rather not touch any EP stuff (e.g., modules) at all. However, if that is going to be the only realistic option, then I guess it would have to do ...
Even when QI will work sometime, I think export renaming is still the better solution (shorter to write, and a little more efficient), so you might as well get used to it. :-)
As I said, the problem currently is that the syntax given above doesn't work yet, but you'd have to name all regular exports in the `export' clause as well.
Any opinions (also from others interested) on whether I should add this feature, and if so, with the syntax above or differently?
Frank
Frank Heckenbach wrote:
Which command exactly did you run, and from which directory? If from the build directory, what does <build>/gcc/p/test/Makefile contain? I suppose, `srcdir' is not set correctly there (i.e., to `.' instead of the source directory). If so, there might be a problem with the sed substitution (gcc/p/Make-lang.in:1022) that creates this Makefile -- either with the regex or the sed invocation or pwd or something else ... I don't see a problem now, but if you play around with it, you might be able to find it out. (You'll have to remove <build>/gcc/p/test/Makefile so it's rebuilt when you change something in Make-lang.in.)
I will try to find out and report about it. For now, I ran the testsuite with the Makefile from the previous alpha version.
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 in OS X
It's an interesting option to add -fstack-check to the test suite:
./read2.inc: In procedure `R': In file included from ./readg1.pas:9: ./read2.inc:203: warning: frame size too large for reliable stack checking ./read2.inc:203: warning: try reducing the number of local variables failed
Could you please try that again after the release of the next GPC alpha?
I did and the result is included as an attachement to this email.
The gpc-20021128 test suite produces other strange results:
TEST adam2.pas: gpc1: warnings being treated as errors adam2v.pas:12: warning: varying case of `aLimit' adam2v.pas:7: warning: other case: `ALimit' adam2v.pas: In constructor `MList.Init': adam2v.pas:14: warning: varying case of `ALimit' adam2v.pas:12: warning: other case: `aLimit' ..... (etcetera)
That's not strange. That's the new warning I've suggested here recently (and implemented now). :-)
I apologize. I associated "case" with the case statement rather than with uppercase and lowercase.
Regards,
Adriaan van Os
Adriaan van Os wrote:
It's an interesting option to add -fstack-check to the test suite:
./read2.inc: In procedure `R': In file included from ./readg1.pas:9: ./read2.inc:203: warning: frame size too large for reliable stack checking ./read2.inc:203: warning: try reducing the number of local variables failed
Could you please try that again after the release of the next GPC alpha?
I did and the result is included as an attachement to this email.
Do you know what the allowed frame size for reliable stack checking is (by experimenting or asking someone)? It seems to be fairly small (a few KB?), and in this case we might have to ignore this option, I'm afraid. GPC uses the stack for internal temporary values (string operations, structured value parameters and function results, ...), not only for local variables, so a size oriented on "typical" C usage (only a few local variables, mostly of scalar types) simply wouldn't fit.
I don't know exactly how stack checking is implemented, but on other platforms I've seen it done without any such restrictions (other than the total stack size, of course).
adam2v.pas:14: warning: varying case of `ALimit' adam2v.pas:12: warning: other case: `aLimit' ..... (etcetera)
That's not strange. That's the new warning I've suggested here recently (and implemented now). :-)
I apologize. I associated "case" with the case statement rather than with uppercase and lowercase.
I see. Any better suggestion for the wording?
Frank
In article 200302132205.XAA00991@goedel.fjf.gnu.de, Frank Heckenbach frank@g-n-u.de writes
adam2v.pas:14: warning: varying case of `ALimit' adam2v.pas:12: warning: other case: `aLimit' ..... (etcetera)
That's not strange. That's the new warning I've suggested here recently (and implemented now). :-)
I apologize. I associated "case" with the case statement rather than with uppercase and lowercase.
I see. Any better suggestion for the wording?
Capitalisation perhaps?
Martin Liddle wrote:
In article 200302132205.XAA00991@goedel.fjf.gnu.de, Frank Heckenbach frank@g-n-u.de writes
adam2v.pas:14: warning: varying case of `ALimit' adam2v.pas:12: warning: other case: `aLimit' ..... (etcetera)
That's not strange. That's the new warning I've suggested here recently (and implemented now). :-)
I apologize. I associated "case" with the case statement rather than with uppercase and lowercase.
I see. Any better suggestion for the wording?
Capitalisation perhaps?
If that's the proper English term. You can tell better than I could -- my dictionary says:
capitalisation n 1: the act of capitalizing on an opportunity [syn: {capitalization}] 2: the sale of capital stock [syn: {capitalization}]
;-)
Frank
On 14 Feb 2003 at 3:28, Frank Heckenbach wrote:
[...]
I see. Any better suggestion for the wording?
Capitalisation perhaps?
If that's the proper English term. You can tell better than I could -- my dictionary says:
capitalisation n 1: the act of capitalizing on an opportunity [syn: {capitalization}] 2: the sale of capital stock [syn: {capitalization}]
;-)
I think that your dictionary is referring to the technical meanings of the word. These are additional meanings deriving from modern commerce, and do not replace the original meaning. "Capitalisation" (whether you spell it British or American style) would be an appropriate word to use in this context - but there may be other more appropriate words.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
On Fri, 14 Feb 2003, Prof A Olowofoyeku (The African Chief) wrote:
On 14 Feb 2003 at 3:28, Frank Heckenbach wrote:
[...]
I see. Any better suggestion for the wording?
Capitalisation perhaps?
If that's the proper English term. You can tell better than I could -- my dictionary says:
capitalisation n 1: the act of capitalizing on an opportunity [syn: {capitalization}] 2: the sale of capital stock [syn: {capitalization}]
;-)
I think that your dictionary is referring to the technical meanings of the word. These are additional meanings deriving from modern commerce, and do not replace the original meaning. "Capitalisation" (whether you spell it British or American style) would be an appropriate word to use in this context - but there may be other more appropriate words.
Webster's New Collegiate:
capitalization n 1 a: the act or process of capitalizing b: ...
capitalize ... vb -ized; -izing vt 1: to write or print with an initial capital or capitals 2: ...
perhaps "mismatched caps" ?
Russ
Russell Whitaker wrote:
Webster's New Collegiate:
capitalization n 1 a: the act or process of capitalizing b: ...
capitalize ... vb -ized; -izing vt 1: to write or print with an initial capital or capitals 2: ...
perhaps "mismatched caps" ?
cap n 1: a tight-fitting covering for the head 2: a top (as for a bottle) 3: a mechanical or electrical device or a small amount of explosive; can be used to fire an explosive charge [syn: {detonator}, {detonating device}] 4: something serving as a cover or protection 5: umbrellalike fruiting structure forming the top of a stalked fleshy fungus such as a mushroom [syn: {pileus}] 6: an upper limit on what is allowed: "they established a cap for prices" [syn: {ceiling}] 7: an artificial crown for a tooth [syn: {crownwork}] 8: the upper part of a column that supports the entablature [syn: {capital}, {chapiter}]
;-)
Frank
On Sat, 15 Feb 2003, Frank Heckenbach wrote:
Russell Whitaker wrote:
Webster's New Collegiate:
capitalization n 1 a: the act or process of capitalizing b: ...
capitalize ... vb -ized; -izing vt 1: to write or print with an initial capital or capitals 2: ...
perhaps "mismatched caps" ?
cap n 1: a tight-fitting covering for the head 2: a top (as for a bottle) 3: a mechanical or electrical device or a small amount of explosive; can be used to fire an explosive charge [syn: {detonator}, {detonating device}] 4: something serving as a cover or protection 5: umbrellalike fruiting structure forming the top of a stalked fleshy fungus such as a mushroom [syn: {pileus}] 6: an upper limit on what is allowed: "they established a cap for prices" [syn: {ceiling}] 7: an artificial crown for a tooth [syn: {crownwork}] 8: the upper part of a column that supports the entablature [syn: {capital}, {chapiter}]
;-)
not cap -- caps abbr 1. capitals 2. capsule
capital n ... 2 a: a capital letter; esp : an inital capital letter
Russ
Russell Whitaker wrote:
On Sat, 15 Feb 2003, Frank Heckenbach wrote:
Russell Whitaker wrote:
Webster's New Collegiate:
capitalization n 1 a: the act or process of capitalizing b: ...
capitalize ... vb -ized; -izing vt 1: to write or print with an initial capital or capitals 2: ...
perhaps "mismatched caps" ?
cap n 1: a tight-fitting covering for the head 2: a top (as for a bottle) 3: a mechanical or electrical device or a small amount of explosive; can be used to fire an explosive charge [syn: {detonator}, {detonating device}] 4: something serving as a cover or protection 5: umbrellalike fruiting structure forming the top of a stalked fleshy fungus such as a mushroom [syn: {pileus}] 6: an upper limit on what is allowed: "they established a cap for prices" [syn: {ceiling}] 7: an artificial crown for a tooth [syn: {crownwork}] 8: the upper part of a column that supports the entablature [syn: {capital}, {chapiter}]
;-)
not cap -- caps abbr 1. capitals 2. capsule
capital n ... 2 a: a capital letter; esp : an inital capital letter
I know -- it wasn't meant so seriously. ;-)
So, what's best now, "varying capitalisation", "varying capitals", "mismatched caps"?
Frank
Le Dimanche 16 Février 2003 06:58, Frank Heckenbach a écrit :
So, what's best now, "varying capitalisation", "varying capitals", "mismatched caps"?
"varying capitalisation" would be my choice "varying letter-cases" may be clearer, and it avoids the ambiguity on "cases" that started the discussion
Frank Heckenbach wrote:
Russell Whitaker wrote:
... snip ...
not cap -- caps abbr 1. capitals 2. capsule
capital n ... 2 a: a capital letter; esp : an inital capital letter
I know -- it wasn't meant so seriously. ;-)
So, what's best now, "varying capitalisation", "varying capitals", "mismatched caps"?
Keep it short. Maybe "varying id letter case: <oldid> <thisid>"?
On Sun, 16 Feb 2003, CBFalconer wrote:
Frank Heckenbach wrote: .. snip ...
So, what's best now, "varying capitalisation", "varying capitals", "mismatched caps"?
Keep it short. Maybe "varying id letter case: <oldid> <thisid>"?
I'd prefer "mismatched" over "varying" because it's not something changing in place but is something that differs from another place.
Perhaps "mismatched <oldid> <thisid>"?
Russ
Russell Whitaker wrote:
On Sun, 16 Feb 2003, CBFalconer wrote:
Frank Heckenbach wrote: .. snip ...
So, what's best now, "varying capitalisation", "varying capitals", "mismatched caps"?
Keep it short. Maybe "varying id letter case: <oldid> <thisid>"?
I'd prefer "mismatched" over "varying" because it's not something changing in place but is something that differs from another place.
Perhaps "mismatched <oldid> <thisid>"?
Another useful word would be "inconsistent".
Frank Heckenbach wrote:
not cap -- caps abbr 1. capitals 2. capsule
capital n ... 2 a: a capital letter; esp : an inital capital letter
I know -- it wasn't meant so seriously. ;-)
The compiler will have to look at the date first and, if that happens to be April 1, issue the message "I don't like your cap".
Regards,
Adriaan van os
Frank Heckenbach wrote:
adam2v.pas:14: warning: varying case of `ALimit' adam2v.pas:12: warning: other case: `aLimit' ..... (etcetera)
That's not strange. That's the new warning I've suggested here recently (and implemented now). :-)
I apologize. I associated "case" with the case statement rather than with uppercase and lowercase.
I see. Any better suggestion for the wording?
Some ideas:
warning: varying caps warning: varying capitals warning: varying lower/uppercase
Regards,
Adriaan van Os
On Mon, 10 Feb 2003, Frank Heckenbach wrote:
I've uploaded a new alpha version...
Built it here using gcc-3.2.2 and PFLAGS=-gstabs:
Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/3.2.2/specs Configured with: ../gcc-3.2.2/configure --enable-languages=pascal : (reconfigured) ../gcc-3.2.2/configure --enable-languages=pascal Thread model: posix gpc version 20030209, based on gcc-3.2.2
Ran test suite. Got a lot of "No such program" messages. Are these counted as tests and shouldn't be counted?
Results: tests 3151 passed 3145 skiped 6 fail 0
Attached is a diff to add to your p/diffs
Russ
Russell Whitaker wrote:
Ran test suite. Got a lot of "No such program" messages. Are these counted as tests and shouldn't be counted?
See my reply to Adriaan's mail. We'll have to investigate this. In any case, it's only a problem with the Makefiles or such, and the results you quoted are correct.
Attached is a diff to add to your p/diffs
Thanks.
Frank
Hi,
the newest GPC release (with 3.2.1 backend) crashes on the program below:
program foo;
var v : 0 .. maxint; d : integer;
begin v := (v mod d) * 32768; 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 20030209, based on gcc-3.2.1 [pas]% gpc crash1.pas crash1.pas: In main program: crash1.pas:8: Internal compiler error in copy_to_mode_reg, at explow.c:725 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions.
I also encountered some segfaults. Unfortunately I wasn't able to reduce the problem to a simple test case, because it manifests only during garbage collection (which doesn't occur at all on short input files, and the trouble might arose long before the actual crash anyway). I'll try to rebuild the compiler with GC checking enabled to see what happens.
[pas]% gpc -O2 tex.p -Q texinthandler readtcxfile parsecnum blanks initialize println printrealch printchar print printnl printesc printthedigs printint printcs sprintcs printfilename printsize printwritewhatsit jumpout error fatalerror overflow confusion aopenin aopenout bopenin wopenin wopenout inputln initterminal {GC 5353k -> tex.p: In function `initterminal': tex.p:539: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions.
[pas]% gdb /usr/local/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/gpc1 GNU gdb Red Hat Linux (5.1.90CVS-5) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) attach 12354 Attaching to program: /usr/local/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/gpc1, process 12354 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 insn_variable_length_p (insn=0x401b3860) at insn-attrtab.c:48 48 return 0; (gdb) cont Continuing.
Program received signal SIGCONT, Continued. insn_variable_length_p (insn=0x401b3860) at insn-attrtab.c:48 48 return 0; (gdb) Continuing.
Program received signal SIGSEGV, Segmentation fault. 0x0822d4e1 in ggc_set_mark (p=0x25701d8) at ../../gcc-3.2.1/gcc/ggc-page.c:439 439 return base[L1][L2]; (gdb) bt #0 0x0822d4e1 in ggc_set_mark (p=0x25701d8) at ../../gcc-3.2.1/gcc/ggc-page.c:439 #1 0x0813b21b in ggc_mark_tree_ptr (elt=0xbffff7f8) at ../../gcc-3.2.1/gcc/ggc-common.c:628 #2 0x0813a137 in ggc_mark_roots () at ../../gcc-3.2.1/gcc/ggc-common.c:256 #3 0x0822da21 in ggc_collect () at ../../gcc-3.2.1/gcc/ggc-page.c:1429 #4 0x080cbbdb in rest_of_compilation (decl=0x4050ebd0) at ../../gcc-3.2.1/gcc/toplev.c:3385 #5 0x08054627 in finish_function (nested=0) at ../../gcc-3.2.1/gcc/p/gpc-decl.c:5029 #6 0x0807128e in main_yyparse () at parse.y:2921 #7 0x080ca159 in compile_file () at ../../gcc-3.2.1/gcc/toplev.c:2124 #8 0x080ce25b in do_compile () at ../../gcc-3.2.1/gcc/toplev.c:5218 #9 0x080ce2b9 in toplev_main (argc=8, argv=0xbffff944) at ../../gcc-3.2.1/gcc/toplev.c:5250 #10 0x4003c0c4 in __libc_start_main () from /lib/libc.so.6
Further playing with the debugger revealed that base[L1] was a NULL pointer.
Emil
On Wed, 12 Feb 2003, Emil Jerabek wrote:
Hi,
the newest GPC release (with 3.2.1 backend) crashes on the program below:
program foo;
var v : 0 .. maxint; d : integer;
begin v := (v mod d) * 32768; end.
[..] tried it with gpc-20030209 ( 2.95.3 backend ) and got:
foo.pas: In main program: foo.pas:8: Internal compiler error in `copy_to_mode_reg', at explow.c:669 Please submit a full bug report. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions.
Russ
Emil Jerabek wrote:
the newest GPC release (with 3.2.1 backend) crashes on the program below:
program foo;
var v : 0 .. maxint; d : integer;
begin v := (v mod d) * 32768; end.
(emil24.pas)
--- p/gpc-common.c.orig Thu Feb 13 01:47:31 2003 +++ p/gpc-common.c Thu Feb 13 02:20:54 2003 @@ -1284,7 +1284,9 @@ else temp = build (COND_EXPR, TREE_TYPE (temp), build_pascal_binary_op (LE_EXPR, exp2, integer_zero_node), - build_rts_call (p_ModRangeError, NULL_TREE), + build (COMPOUND_EXPR, TREE_TYPE (temp), + build_rts_call (p_ModRangeError, NULL_TREE), + integer_zero_node), temp); return temp; }
Frank
Emil Jerabek wrote:
I also encountered some segfaults. Unfortunately I wasn't able to reduce the problem to a simple test case, because it manifests only during garbage collection (which doesn't occur at all on short input files, and the trouble might arose long before the actual crash anyway).
I found an instance myself now, and the following fixes it. Hope it does so for your case, too.
--- p/predef.c.orig Thu Feb 13 02:01:44 2003 +++ p/predef.c Fri Feb 14 08:08:31 2003 @@ -117,7 +117,7 @@ TREE_PUBLIC (decl) = 1; KItable[i].decl = decl; #ifdef EGCS97 - ggc_add_tree_root (&decl, 1); + ggc_add_tree_root (&KItable[i].decl, 1); #endif } }
Frank
On Fri, Feb 14, 2003 at 08:18:43AM +0100, Frank Heckenbach wrote:
Emil Jerabek wrote:
I also encountered some segfaults. Unfortunately I wasn't able to reduce the problem to a simple test case, because it manifests only during garbage collection (which doesn't occur at all on short input files, and the trouble might arose long before the actual crash anyway).
I found an instance myself now, and the following fixes it. Hope it does so for your case, too.
I'll try it, thanks. Anyway, I rebuilt the compiler with ENABLE_GC_ALWAYS_COLLECT meanwhile, which helped to pinpoint the problem. All five segfaults I got actually reduced to the same pattern, namely deep nesting of conditionals (and/or loops), such as this one:
program p4;
procedure g; var c: integer; begin if true then begin if true then begin case c of 40: begin if true then if true then begin if true then begin ; if true then if true then begin ; if true then begin ; if true then c := c - 48 end end end end end end end end end;
begin 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 --enable-checking --enable-gc-checking --enable-gc-always-collect Thread model: posix gpc version 20030209, based on gcc-3.2.1 Delete /tmp/ccUdXKeS.gpa? (y or n) y [pas]% gpc crash4.pas -Q g {GC 126k -> crash4.pas: In procedure `g': crash4.pas:29: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. Delete /tmp/ccT5oAVp.s? (y or n)
Emil
On Fri, Feb 14, 2003 at 08:18:43AM +0100, Frank Heckenbach wrote:
Emil Jerabek wrote:
I also encountered some segfaults. Unfortunately I wasn't able to reduce the problem to a simple test case, because it manifests only during garbage collection (which doesn't occur at all on short input files, and the trouble might arose long before the actual crash anyway).
I found an instance myself now, and the following fixes it. Hope it does so for your case, too.
Yes, it works. Thanks
Emil
Frank Heckenbach a écrit:
I've uploaded a new alpha version.
I had some problems when compiling the utils stuff with djgpp/gcc-2.95.3 The reason was that GPC_FOR_TARGET was overriden from top level makefile by
c:/djgpp/b/gnu/gcc-2.953/build.djg/gcc/xgpc -Bc:/djgpp/b/gnu/gcc-2.953/build.djg/gcc/ -Bc:/djgpp/i586-pc-msdosdjgpp/bin/
Applying GCC2GPC gives c:/djgpp/b/gnu/gcc-2.953/build.djg/gpc/xgpc -B ... ^ and the needed -I./p/rts is lost
The following diff solved the problem for me (take care to unwanted line wrappings):
--- p/Make-lang.in.orig 2003-02-09 13:37:16.000000000 +0000 +++ p/Make-lang.in 2003-02-13 13:57:54.000000000 +0000 @@ -163,10 +163,11 @@
# The GPC to use for compiling libgpc.a # Usually the one we just built. -GPC_FOR_TARGET=./xgpc -B./ -I./p/rts +GPC_FOR_TARGET=./xgpc -B./
ADD_RTS_PARENT_DIR=sed -e 's,(-[BI])([^/][^:]),\1../../\2,g;s,^([^/][^:]*/),../../\1,' GCC2GPC=sed 's, *$$,,;s,^([^ ]*[/][^/]*)gcc,\1gpc,;s/^gcc$$/gpc/' # $(CC) might be .../gcc-foo/.../xgcc +ADD_RTS_DIR=sed -e 's,$$, -I./p/rts ,'
# The ' ' is there so, e.g., `-B.' will be replaced by ADD_RTS_PARENT_DIR RTS_COMPILERS=CC="`echo $(GCC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`" \ @@ -193,7 +194,7 @@ # Flags to pass when building the utilities. (PC is the GPC for the host!) UTILS_FLAGS_TO_PASS=\ SHELL="$(SHELL)" \ - PC="`if [ x"$(GPC_HOST)" = x"$(target)" ]; then echo $(GPC_FOR_TARGET)' '; else echo $(CC)' '; fi | $(ADD_RTS_PARENT_DIR) | $(GCC2GPC)`" \ + PC="`if [ x"$(GPC_HOST)" = x"$(target)" ]; then echo $(GPC_FOR_TARGET)' '; else echo $(CC) | $(GCC2GPC); fi | $(ADD_RTS_DIR) | $(ADD_RTS_PARENT_DIR)`" \ CFLAGS="$(CFLAGS)" \ PFLAGS="$(PFLAGS)" \ exeext="$(exeext)" \
but I have no possibility to check the case host <> target
Otherwise no errors in the test suite with gcc-2.95.3 and only one with gcc-3.2.1
TEST fjf165a.pas: SKIPPED: German locale not installed TEST fjf341b.pas: c:/djgpp/b/gnu/gcc-3.21/gcc/p/test/fjf341b.pas:5: tree c heck: expected integer_cst, have plus_expr in tree_int_cst_sgn, at tree.c:3515 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. failed TEST longr2.pas: SKIPPED: no LongReal math routines available
# of GPC tests 3151 # of GPC tests passed 3148 # of GPC tests skipped 2 # of GPC tests failed 1
Maurice
Maurice Lombardi wrote:
Frank Heckenbach a écrit:
I've uploaded a new alpha version.
I had some problems when compiling the utils stuff with djgpp/gcc-2.95.3 The reason was that GPC_FOR_TARGET was overriden from top level makefile by
c:/djgpp/b/gnu/gcc-2.953/build.djg/gcc/xgpc -Bc:/djgpp/b/gnu/gcc-2.953/build.djg/gcc/ -Bc:/djgpp/i586-pc-msdosdjgpp/bin/
Applying GCC2GPC gives c:/djgpp/b/gnu/gcc-2.953/build.djg/gpc/xgpc -B ... ^ and the needed -I./p/rts is lost
The following diff solved the problem for me (take care to unwanted line wrappings):
[...]
+ADD_RTS_DIR=sed -e 's,$$, -I./p/rts ,'
- PC="`if [ x"$(GPC_HOST)" = x"$(target)" ]; then echo $(GPC_FOR_TARGET)' '; else echo $(CC)' '; fi
| $(ADD_RTS_PARENT_DIR) | $(GCC2GPC)`" \
- PC="`if [ x"$(GPC_HOST)" = x"$(target)" ]; then echo $(GPC_FOR_TARGET)' '; else echo $(CC) |
$(GCC2GPC); fi | $(ADD_RTS_DIR) | $(ADD_RTS_PARENT_DIR)`" \
but I have no possibility to check the case host <> target
Seems to work (with a slight modification), thanks.
Frank
-
Adriaan van Os -
CBFalconer -
Emil Jerabek -
Frank Heckenbach -
Jean-Pierre Vial -
Martin Liddle -
Maurice Lombardi -
Prof A Olowofoyeku (The African Chief) -
Prof. A Olowofoyeku (The African Chief)
-
Russell Whitaker