- Gpc - gnu.de

Linux 64 bit versions of GPC?
by Mike Reid 22 Dec '06

22 Dec '06

I've been using an ancient 1999 version of GPC since, well, 1999, because it worked fine, came as an RPM, and did what I wanted. However, I've now got a laptop that is running the 64 bit version of Mandriva Linux. Compiled 32-bit code seems to run OK, but the packaged versions of the compiler fail at the assembly stage. I.e. I can use my old versions of GPC to produce assembler, but the assembler gives error messages even on a "hello world" program. Is there any simple work-around, or a binary distribution that should work on my system? Or do I have no option other than compiling from scratch? Mike Reid -- Dr Michael F Reid Department of Physics and Astronomy University of Canterbury Christchurch, New Zealand Ph: + 64 3 364 2548 Fax: + 64 3 364 2469 Email: mike.reid(a)canterbury.ac.nz

2 2

Bug: copy
by Andreas K. Foerster 28 Nov '06

28 Nov '06

Hello, I came across a strange thing in gpc. My programs compile well with old versions of gpc, but when someone tried to compile the program with his version, it broke. It made me look very bad. :-( The function "copy" doesn't seem to accept the result of a function anymore. I consider that as a bug. --------------------------------------------------------------- program akf1; uses GPC; function mytext: TString; begin mytext := 'something ...' end; begin WriteLn(copy(mytext, 1, 9)) end. --------------------------------------------------------------- -- AKFoerster

1 0

break bug report
by Russ Whitaker 26 Nov '06

26 Nov '06

Hi Got careless and used "break" where I should use "exit" and got this: try.pas: In main program: try.pas:7: internal compiler error: in plant_exit_loop, at p/plant.c:651 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. from this: program bug; uses gpc; begin if FileExists( Paramstr( ParamCount ) ) then begin writeln('Quitting: output file "', Paramstr( ParamCount ), '" exists'); break; end; end. gpc version 20060325, based on gcc-4.1.1 Russ

1 0

more on gp
by Frank McCormick 16 Nov '06

16 Nov '06

On Tue, 14 Nov 2006 22:58:17 +0100 Frank Heckenbach <ih8mj(a)fjf.gnu.de> wrote: > > > Frank McCormick wrote: > > > > > > > gp: Pascal and C compilers specified seem to be for different > > > > platforms gp: (`i686-pc-linux-gnu' and `i486-linux-gnu') > > > > > > GP by default compares the versions of GPC and GCC very strictly to > > > avoid subtle errors that could result on mismatch. If you know the > > > mismatch is harmless (e.g., as above, just a different labeling of > > > targets), you can add "--no-check-platform" to skip this check. > > > > I tried putting --no-check-platform into a .gp config file in my > > home directory and it works...but only sometimes. Seems to depend on whether I am in an > > IDE (Anjuta/Peng/Geany) or at the cli. Does GP always check ~.gp ? > > No, GP doesn't currently read any config file itself (this is > planned in the future, though). Soon ? > This seems to be a feature of your > IDE. (Though for PENG, which I wrote, I'm not aware of such a > feature. ;-) However, PENG allows doing such things in user-defined > tools, so perhaps this was done in your setup.) > > To make it work on the command line, too, you can use the usual > means of a shell alias or a tiny wrapper script to add this option. Alias seems to work well. Thanks -- Cheers Frank

2 1

Works sometimes.
by fmccormick＠videotron.ca 14 Nov '06

14 Nov '06

On Sun, 12 Nov 2006 19:23:21 +0100 Frank Heckenbach <ih8mj(a)fjf.gnu.de> wrote: > Frank McCormick wrote: > > > > > gp: Pascal and C compilers specified seem to be for different > > platforms gp: (`i686-pc-linux-gnu' and `i486-linux-gnu') > > > > GP by default compares the versions of GPC and GCC very strictly to > avoid subtle errors that could result on mismatch. If you know the > mismatch is harmless (e.g., as above, just a different labeling of > targets), you can add "--no-check-platform" to skip this check. I tried putting --no-check-platform into a .gp config file in my home directory and it works...but only sometimes. Seems to depend on whether I am in an IDE (Anjuta/Peng/Geany) or at the cli. Does GP always check ~.gp ? ---Frank McCormick--- ------Montreal--------

2 1

error message
by Frank McCormick 12 Nov '06

12 Nov '06

Something must have changed on my system because now I am getting this error message once in a while: gp: Pascal and C compilers specified seem to be for different platforms gp: (`i686-pc-linux-gnu' and `i486-linux-gnu') I usually happens when I use gp instead of gpc. Any ideas ? Thanks

2 1

GPC is falling out of the mainstream
by CBFalconer 08 Nov '06

08 Nov '06

GPC is falling out of the mainstream, due to the failure to integrate it with gcc. It seems to me this should take priority. -- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net>

4 3

Incorrect scoping of object/class field and method formal parameter identifiers
by Gale Paeper 08 Nov '06

08 Nov '06

While assisting in porting MacPascal Object Pascal code to GPC, I encountered a bug in GPC's scope rules implementation for object field and method formal parameter identifiers. The same bug also exists with the OOE objects implementation. The follow examples (one for mac-objects and one for ooe-objects) along with the respective GPC compilation error demonstrate the bug: {$ooe-objects} program ClassScopeBug(output); type Tclass = class x: integer; procedure y(x: real); { Should be legal} end; procedure Tclass.y(x: real); begin end; begin writeln('OK'); end. ClassScopeBug.pas:8: error: formal parameter `x' of method `y' conflicts with field or method {$mac-objects} program ObjectScopeBug(output); type Tobj = object x: integer; procedure y(x: real); { Should be legal} end; procedure Tobj.y(x: real); begin end; begin writeln('OK'); end. ObjectScopeBug.pas:8: error: formal parameter `x' of method `y' conflicts with field or method Both the MacPascal Object Pascal object and the Object-Oriented Extensions for Pascal class have the same 6.2.2 Scopes requirements extensions in this area. Although stated informally; implied through syntax extensions; and informal behavioral descriptions, the formal-parameter-list of a method heading is a separate scope region for which 6.2.2.5 scope exclusion requirements apply. The "Object-Oriented Extensions for Pascal" Technical Report in paragraph 6.5.4 "Implicit References" also states in part: "...Therefore, a parameter identifier or a local variable with the same spelling as a name brought in will hide the name brought in. A name so hidden can be accessed by explicit use of the class name and qualification." Therefore, there is no conflict between formal parameter `x' of method `y' and object/class field `x' since object/class field `x' is excluded from the scope of method `y' 's formal-parameter-list and method body. Since there is no violation of either object models' requirements, GPC should compile both of the example programs without any errors. The GPC I'm using is built from Adriaan's Mac OX X GPC sources distribution which I've upgraded to use Waldek's gpc-20060325 snapshot GPC sources. The specs are: Reading specs from /Developer/Pascal/gpc345u2d1/lib/gcc/powerpc-apple-darwin8/3.4.5/specs Configured with: ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc345u2d1 Thread model: posix gpc version 20060325, based on gcc-3.4.5 Gale Paeper gpaeper(a)empirenet.com

1 0

Re: Internal compiler error with non-matching method signatures
by Waldek Hebisch 08 Nov '06

08 Nov '06

Gale Paeper wrote: > Since the 20051116 workaround for the bug is to use the legal code > construct needed for a successful compile anyway, I don't have a presing > need for a 20051116 fix. Just reporting a bug to ensure it got fixed if > it hadn't already been taken care of in one of the later snapshots. > Thanks for the report. As I wrote it should be fixed in newer versions (unless the testcase hits two bugs and one is Mac specific). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 1

Bit setting operations
by Contestcen＠aol.com 07 Nov '06

07 Nov '06

And I'm curious wheteher there are bitsetting operations ... Thanks - Thurs, The Pascal Macro Compiler has a full set of bit operations. You compile first with the Macro Compiler, and then compile the generated Pascal code with whatever Pascal compiler you customarily use. The bit operations are described on the Master Software website at pasbit.htm with an example at pasbit2.htm Frank Rubin

1 0