- Gpc - gnu.de

Re: Segmentation Fault With Gpc/Gcc 3.3
by Waldek Hebisch 13 Jun '03

13 Jun '03

> Perhaps we should pass sets smaller than 16bytes in registers, like all > other structures are... > > > Pascal patches the backend (stor-layout.c) to get this. More precisely > > `stor-layout.c' contains the following (at line 1813): > > > > if (rounded_size > (int) alignment) > > TYPE_MODE (type) = BLKmode; > > else > > TYPE_MODE (type) = mode_for_size (alignment, MODE_INT, 1); > > > > Pascal makes alignment equal to size of long. By default alignment is > > BITS_PER_WORD. I do not know what other front ends are doing, but > > safe way is to expect any integer mode. > > I see, this can be problem for passing 128bit sets in register, but I > guess if we classify it using x86_64_INTEGER_CLASS it will just work > (get casted via PARALLEL) > > Honza The following snippet appearently works for Pascal and should be relatively safe for other front ends: else if (TREE_CODE (type) == SET_TYPE) { if (bytes <= 4) { classes[0] = X86_64_INTEGERSI_CLASS; return 1; } else if (bytes <= 8) { classes[0] = X86_64_INTEGER_CLASS; return 1; } else if (bytes <= 12) { classes[0] = X86_64_INTEGER_CLASS; classes[1] = X86_64_INTEGERSI_CLASS; return 2; } else { classes[0] = X86_64_INTEGER_CLASS; classes[1] = X86_64_INTEGER_CLASS; return 2; } -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

BPReal must be a packed record
by David Ulbrich 13 Jun '03

13 Jun '03

in unit system, the BPReal type must be changed to a packed record (at least if the target is not a i686). We're using GPC with GCC-crosscompiler for embedded ARM CPU's (4 byte alignment). Without 'packed', mapping of existing BP-created data structures containing this 6 byte 'real' type does not work. David

2 1

Seeking advice for function return
by Mirsad Todorovac 11 Jun '03

11 Jun '03

There is a conversion function, which accepts "Width" up to which the returned value should be zero-extended as additional parameter. I was wondering, what would you expect from a library or unit function to do when this Width can't be satisfied withing given TString result value: 1. silently truncate (simply return the converted number as TString of maximum possible length, for the truncated zeros do not make a change in numerical value assigned ot return string.) 2. return '' (empty string), which can be checked and detected by caller 3. truncate with some sort of warning, for suspiciously high Width silently truncated can hide a bug in program that will crash sometimes later something else less detectable a) do it once per program run (i.e. like compiler that reports some conditions only once per function) b) report it with each call to function in either case this warning might occur in test runs, indicating error or bug in calling program 4. raise RuntimeWarning() { deprecated by Frank } 5. raise RuntimeError() to abort the program What is the behavior you'd prefer for such a library function? Example of the function might be: Integer2StringWidth (i: Integer; Width: Integer): TString; So, for example, if High(TString) = 2048, and the code is: WriteLn (Integer2StringWidth (i, 2200)); what should be done? (NOTE: this is not the actual function, but a meaningless, but simpler example.) Thank you, Mirsad

3 2

Re: Segmentation Fault With Gpc/Gcc 3.3
by Frank Heckenbach 11 Jun '03

11 Jun '03

Jan Hubicka wrote: > > Frank Heckenbach <Frank(a)G-N-U.De> Writes: > > > > > Andreas Jaeger Wrote: > > > > > >> One More Thing That Does Not Seems To Work Are Profile Driven > > >> Optimizations. Are You Supporting -Profile-Arcs And > > >> -Fbranch-Probabilities? > > > > > > We Don't Do Anything Special About Them. Is This Required, I.E., > > > Aren't They Handled By The Backend? > > > > Honza, can you explain what needs to be done? > > > > AFAIK you do not initialize some fields correctly but Honza knows > > more... > > It may well be also problem present on hammer branch only. The problem > is that profile code uses trees to expand data structures passed to GCC > runtime. The language frontend needs to initialize all the types that > gcov code expects to be on the place. > Recently I moved gcov from c type nodes into it's own nodes to avoid > problems with fortran frontend not initializing things like > unsigned_long_node but with pascal frontend it still seem to be > crashing. I didn't investigated what exactly is missing. We call build_common_tree_nodes which initializes long_unsigned_type_node etc. If anything more is needed, it shouldn't be difficult to add it. I'd only have to know what. Is this documented anywhere? 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

1 0

64 bit code generation
by Cserzo Miklos 11 Jun '03

11 Jun '03

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 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

5 17

Regression with array inside packed record
by Waldek Hebisch 10 Jun '03

10 Jun '03

The following program used to work: PROGRAM FOO; CONST IDLNGTH = 12; TYPE ALPHA = ARRAY [1..IDLNGTH] OF CHAR; IDENTIFIER = PACKED RECORD NAME: ALPHA; END; VAR FILID : IDENTIFIER ; I, J : INTEGER; BEGIN J := 0 ; FOR I := 1 TO IDLNGTH DO J := J + ORD(FILID.NAME[I]) ; WRITELN('OK') END . With gpc-20030507 I get the following: bash-2.04$ gpc -v -B/mnt/a9/pom/kompi/gcc3/gpc-3.2.2/gcc name4.p Reading specs from /mnt/a9/pom/kompi/gcc3/gpc-3.2.2/gcc/specs Configured with: ../gcc-3.3/configure --enable-checking Thread model: posix gpc driver version 20030507, based on gcc-3.3, executing gpc version 3.2.2 /mnt/a9/pom/kompi/gcc3/gpc-3.2.2/gcc/gpcpp -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -v -isystem /mnt/a9/pom/kompi/gcc3/gpc-3.2.2/gcc/include -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=2 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix -D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ name4.p -famtmpfile=/tmp/ccZIDfUy.gpa /tmp/ccKpUnOZ.i GNU Pascal Compiler PreProcessor version 20030507, based on gcc-3.2.2 (i386 Linux/ELF) /mnt/a9/pom/kompi/gcc3/gpc-3.2.2/gcc/gpc1 /tmp/ccKpUnOZ.i -quiet -dumpbase name4.p -version -famtmpfile=/tmp/ccZIDfUy.gpa -o /tmp/ccXcnQqq.s GNU Pascal version is actually 20030507, based on gcc-3.2.2 GNU Pascal version 3.2.2 (i686-pc-linux-gnu) compiled by GNU C version 3.3. name4.p: In main program: name4.p:15: cannot take address of packed record field `NAME' -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

2 2

Preprocessor question
by Mirsad Todorovac 09 Jun '03

09 Jun '03

Hi, everybody! How could I make this preprocessor check work? domac:~/pascal/gcc-3.2.1/gcc/p/test> time make MASK='mtm017.pas' pascal.check-long rm -f *.dat *.o *.s *.i *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.i todo/*.gpi todo/*.gpd todo/core { 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 20030507, based on gcc-3.2.1 (i686-pc-linux-gnu) (domac), 2003-06-07 15:36:13 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" mtm017.pas | tee test_log GPC-TEST-BEGIN ========================== TEST mtm017.pas: ./mtm017.pas:23: conditional expression: `Low' is not defined ./mtm017.pas:23: conditional expression: trailing garbage failed --------------------------------------------------------------------------------- function IsValidNumberBase2 (s: String; Base: Integer): Boolean; attribute(const); var i, dv : Integer; attribute (register); b : Byte; attribute (register); function DigitValue (Dig: Char): Integer; attribute (inline, const); var d : Integer; attribute (register); {$if Low (Char) < 0} {$error "this won't work: negative Char used as index} {$endif} v : array [0..255] of Integer = ( -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, -1, -1, -1, -1, -1, -1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, -1, -1, -1, -1, -1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 ); begin DigitValue := v[Dig]; end; ... Thanks, Mirsad -- "I have a dream!" -- Martin Luther King Jr.

3 6

Mac OS X download
by Adriaan van Os 08 Jun '03

08 Jun '03

Updated compiler sources and binaries, as well as updated Apple PInterfaces for GPC can be downloaded from <www.microbizz.nl/gpc.html>. Regards, Adriaan van Os

1 0

gpc-20030507 released
by Frank Heckenbach 07 Jun '03

07 Jun '03

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(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

10 61

How many bits in longreal?
by John Ollason 06 Jun '03

06 Jun '03

Greetings, I am running GPC under RedHat 7.3 on an Intel i686. I am trying to debug a MatLab program by running it against one written in Gnu Pascal. I am using the type longreal throughout. According to the manual this typically occupies 80 bits. Is there any way of finding out easily how long longreal is on my hardware? I want to avoid precision-related problems. The programs generate much the same output but depart beyond about 7 significant figures. Thanks in advance for information and advice. John O.

3 2