Hi,
during some debugging I noticed that GPC generates very hairy code
for the `mod' operator with signed arguments. A closer look revealed
that the code contains a lot of branching on conditions which can be
determined on compile time, and most surprisingly, the value of
X mod Y is recomputed _twice_, if X is negative. (I've attached
a commented assembler dump.)
This may be partially a back-end problem (CSE?), but I feel there's
something wrong in the relevant code in gpc-common.c (…
[View More]build_pascal_binary_op)
as well. `exp1 mod exp2' gets translated into something like
exp2 <= 0 ? error :
exp1 >= 0 ? exp1 mod exp2 :
((-exp1) mod exp2) == 0 ? 0 : exp2 - (-exp1) mod exp2
This arranges that both arguments supplied to the "internal mod"
are non-negative, but this information is not passed on -- the arguments
are still declared as signed types, which apparently makes the back-end
to produce the mess it does. I've done a little test: the following
replacement for `mod', which differs from the built-in one essentially
just by the type-casts to `Cardinal',
inline operator xmod (X, Y: Integer) = Z: Integer;
begin
if Y <= 0 then RuntimeError (714);
if X >= 0 then Z := Cardinal (X) mod Y
else begin
Z := Cardinal (-X) mod Y;
if Z <> 0 then Z := Y - Z
end
end;
indeed generates a better code, it measures about 15% faster for
positive X and more than twice faster for negative X. YMMV.
If this is possible in user code, it should work in the compiler
internals as well :)
The result type of the whole `mod' expression looks dubious too.
IIUIC, `exp1 mod exp2' inherits the type of exp1. Now, the result
of `mod' is guaranteed to be nonnegative and to fit in the type of exp2
(or more precisely, it is in 0 .. High (type of (exp2)) - 1),
whereas it needn't have anything to do with the type of exp1:
consider
var
X, Z: Integer;
Y: LongInt;
begin
X := -8;
Y := High (LongInt);
Z := X mod Y { -> overflow }
end
Or am I missing something?
Emil
(BTW, where is fjf434c.pas?)
[View Less]
On The debian-legal mailing list there currently is a major discussion
about the "freeness" of the "GNU Free Documentation License". You may
want to look at the archives yourself, one point to start is
http://lists.debian.org/debian-legal/2003/debian-legal-200304/msg00307.html
The problem are the "Invariant Sections" of the GFDL, which make the
GFDL non-free from Debian's viewpoint. Looking at gpc's documentation,
I see the GFDL-1.1 (with the short example GFDL license at the end),
but in …
[View More]the man page I only find:
COPYING
Copyright (c) 1997-2003 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version
1.1 version published by the Free Software Foundation.
A copy of the GFDL comes as a texinfo document along with the
GPC manual.
In contrast with copying-fdl.texi, there is no mentioning of the
"Invariant Sections":
"If you have no Invariant Sections, write ``with no Invariant
Sections'' instead of saying which ones are invariant. If you have
no Front-Cover Texts, write ``no Front-Cover Texts'' instead of
``Front-Cover Texts being @var{list}''; likewise for Back-Cover
Texts."
Please clarify the copyright of the man page. I'll have to remove the
info and html docs from the Debian main section (maybe somebody
volunteers to repackage them to the non-free section), but to keep at
least the manual pages in the package I'd like to see the license of
the manual pages be clarified.
Thanks, Matthias
[View Less]
For the main tests, i hope it's the end...
Up to you to correct my tests...
http://www.info.fundp.ac.be/~fsc/dvpt/fsc.tar.gz
or, "online"
http://www.info.fundp.ac.be/~fsc/dvpt/
fsc01-05 : array R/W
fsc06-10 : packed array R/W
fsc11 : array in a record (just one, i dont think it's usefull :) )
fsc12 : enum
fsc13-14 : string (R/W)
fsc15-16 : range write (integer and char)
fsc 17-18 : functions and range
fsc 19-25 : predefined functions (chr, fillchar, ...)
fsc26-27 : conformant array R/W
fsc28-…
[View More]30 : slice array
fsc31-35 : actual schema discriminant
fsc36-37 : "for loops", i'm not sure it's what you expect...
For asm target, i have a problem...
The only "assembler language" i know is MIX (thanks D. Knuth :-) )...
And i haven't really got time to learn it before... long time i'm
afraid...
Can anybody help here???
For the remaining... What's
missing?
wrong?
misunderstood?
I've never played with delphi extensions, the OO language i used was
java. And i'm teaching the very basics of programming so, i never used
slice array and other schema discriminant before, it's possible i missed
a lot of thing... Just explain me (or point me to a relatively short
tutorial), i only ask to learn :)
--
Francois Schoubben
[View Less]
Peter N Lewis wrote,
> ####
> #### FDE 0x2aea4 (OB 0x13fd60, fde_end 0x2affc) has zero
> length!Aborting.
> ####
> Abort
Fixed with gcc-3.3.
Geoff Keating wrote:
>
> Adriaan van Os writes:
>> (4) compiling any .c source with -ggdb or -gdwarf-2 (instead of
>> -gstabs or -g) produces the following output:
>> Internal compiler error in default_no_named_section, at varasm.c:5305
>
> Darwin doesn't really support dwarf2 at present.
Fixed with gcc-3.3,…
[View More] there is now a message "unknown or unsupported -g
option".
Geoff Keating wrote:
>
> Adriaan van Os writes:
>
>> Does anyone know what the status is of the following problems,
>> encountered with gcc-3.2.1/3.2.2 on Darwin/Mac OS X ?
>>
>> (1) trampolines crash (I have a patch to fix it)
>>
>> (2) longjumps crash (I have a patch to fix it also)
>>
>> (3) non-local goto's don't work, e.g.
>
> These are all fixed in GCC 3.3.
Well, not quite. Longjump crashes and non-local goto crashes have been
fixed, but trampoline crashes not. The gcc-3.2.x trampoline patch can
be applied to gcc-3.3 and it fixes most trampoline crashes, but .....
./test_run: line 193: 766 Segmentation fault "$DIFF"
testmake.tmp "$xo"
TEST fproc.pas: failed
... running the testuite for fproc.pas takes a long time and fails.
After a while the hardddisk starts to spin continuously, which might
indicate that the system is allocating lots virtual memory (on a 1.25
GB Mac). After this, gpc1 crashes when compiling ANY .pas file, until a
reboot. The typical backtrace looks like this:
Date/Time: 2003-05-18 03:11:07 +0200
OS Version: 10.2.4 (Build 6I32)
Host: G4.local.
Command: gpc1
PID: 27979
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
Thread 0 Crashed:
#0 0x0014ec68 in find_reloads (reload.c:4000)
#1 0x0011bbe8 in reload_as_needed (reload1.c:3893)
#2 0x00115388 in reload (reload1.c:1107)
#3 0x001dca60 in global_alloc (global.c:583)
#4 0x000991ec in rest_of_compilation (toplev.c:3304)
#5 0x00007b58 in finish_routine (declarations.c:2436)
#6 0x0002d27c in main_yyparse (parse.c:1739)
#7 0x00097ce0 in compile_file (toplev.c:2134)
#8 0x0009ce94 in do_compile (toplev.c:5370)
#9 0x0009cf60 in toplev_main (toplev.c:5400)
#10 0x00002700 in _start (crt.c:267)
#11 0x00002580 in start
Maybe, virtual memory is corrupt after the fproc.pas testrun ??
Running the testsuite for fproc.pas with --longjmp-all-nonlocal-labels,
results in a compiler error message:
TEST fproc.pas: /var/tmp//ccMu9pMb.s:unknown:Can't emit reloc
{- symbol "LSJR11"} @ file address 800.
/var/tmp//ccMu9pMb.s:unknown:Can't emit reloc {- symbol "LSJR11"} @
file address 796.
/var/tmp//ccMu9pMb.s:unknown:Undefined local symbol L3$pb
failed
Regards,
Adriaan van Os
[View Less]
Hi Folks,
I need 64-bit code on Sun Solaris 2.9. The specification of the system
(gpc -v):
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2.1/specs
Configured with: /users/cserzo/big/src/gcc-3.2.1/configure
--enable-languages=pascal --disable-nls --with-gnu-as --with-gnu-ld
--with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld
Thread model: posix
gpc version 20030507, based on gcc-3.2.1
Apparently, the 32-bit compiler should be able to generate 64-bit code.
The problem is …
[View More]the missing 64-bit libgpc. The 64-bit version of the gcc
library is there but its gpc counterpart not. How could I force the
compilation of this library at build time?
I made another test. With the 32-bit version one should be able to address
~ 4.3 Gb of the memory. In practice, I can allocate about 2Gb
(array[1..500000000] of integer) but not much more. If I compile a code
containing array[1..600000000] of integer the following error generated:
/var/tmp//ccrvtgAm.s: Assembler messages:
/var/tmp//ccrvtgAm.s:7: Error: .COMMon length (-1894967300.) <0! Ignored.
/var/tmp//ccrvtgAm.s:7: Warning: rest of line ignored; first ignored
character is `,'
What is the correct way to make use of the memory in this case?
Cheers,
miklos
[View Less]
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 …
[View More]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(a)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(a)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(a)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(a)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(a)mail.bcpl.net>,
<Pine.LNX.4.44.0210281004000.31943-100000(a)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
--
Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
[View Less]
Hi, Frank!
-------------------------------------------------------
program mirsad16(output);
function testproc (n: LongCard): String(64);
begin
n := n;
return 'OK';
end;
begin
WriteLN (testproc (42));
end.
-------------------------------------------------------
bash-2.05b$ gpc -Wall mirsad16.pas
mirsad16.pas:4: warning: missing string capacity -- assuming 255
mirsad16.pas:4: parse error before `('
I couldn't find in reference docs whether this is actually banned by
specification, or …
[View More]is it a bug in parser.
Thanks,
Mirsad
--
"I have a dream!" -- Martin Luther King Jr.
"You can't hold someone down ... without staying down with him."
-- Booker T. Washington
"... one thing is for sure about the rat race:
Even if you win, you're still a rat." -- S. Baars
[View Less]
I installed gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz under my previous
Linux (Red Hat 8.) and it worked without any problems.
I did the same under Red Hat 9. When I tried to compile a program 'gpc'
complained:
gpc: installation problem, cannot exec `gpcpp': No such file or directory
I put then in /usr/local/bin a symbolic link:
gpcpp ->/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/gpcpp
Now I got the message:
gpc: installation problem, cannot exec `gpc1': No such file or …
[View More]directory
I added the link:
gpc1 -> /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/gpc1
Now I got a series of messages from the linker; some of them:
---------------------------------------------
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/libgpc.a(rts.o)(.text+0x5d6):
In function `_p_LocaleUpCase':
/home/frank/gpc/gcc-2.95.3/gcc/p/rts/rts.c:838: undefined reference to
`__ctype_toupper'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/libgpc.a(rts.o)(.text+0x5ea):
In function `_p_LocaleLoCase':
/home/frank/gpc/gcc-2.95.3/gcc/p/rts/rts.c:846: undefined reference to
`__ctype_tolower'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/libgpc.a(rts.o)(.text+0x5fe):
In function `_p_IsUpCase':
/home/frank/gpc/gcc-2.95.3/gcc/p/rts/rts.c:851: undefined reference to
`__ctype_b'
(... more deleted ...)
-----------------------------------------------
Any idea what the problem is? I am not a Linux expert and would
appreciate simple advice :-). Please send a copy of the answer to my
address because I am not a subscriber to this list.
Thanks!
-- Tomasz Kowaltowski
[View Less]
Hello
I have DLed the newest version listed and the Dec2002 Developer Tools
from Apple and have proceeded to work on a more complex project.
However, I am unable to compile the source - it gives me this error:
> alan.pas: In procedure `f_b':
> alan.pas:577: 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.
>
Any ideas?
If anyone cares to …
[View More]look into it I have attached the source, the
preprocessed source and the data file needed to run it.
Regards,
Boris
[View Less]
Hi, dear All. I have made exhaustive (at least, hope so) search in the documentation and mail
list archives but found only that "GPC will align variables according
to maximum performance", but how exactly? On what boundary will be
aligned Integer, Boolean, Longint, Word, etc. On what boundary will be
aligned string, record, array, their elements and are there any differences between default
alignment of variable without record and variable as record field? And, if
possible, I need information …
[View More]for the other platforms. I understand that I
can make experiments to find it out but it seems to me it should
appear in one or in other place (GPS manuals or mailing lists).
Thanx, dear All.
Best regards,
Ingvar mailto:marny@rambler.ru
[View Less]