Gpc

gpc@gnu.de

5400 discussions

Compilation problem with gpc 20021128
by Martin Liddle 23 Jan '03

23 Jan '03

I am experimenting with gpc 20021128 built with gcc 3.2.1. However I have a compilation problem. The following code fails to compile with the error message: ml.p:12: passing arg1 of Sys_stat from incompatible array. The code compiles OK under 20020426 based on gcc 2.95.2. Am I doing something wrong or is this a bug? (Note if the function rmdir line is commented out in ml2 then the program compiles. If the code of ml2 is merged with ml then the code compiles). unit ml2; interface Const CstrSize = 254; type StatRecord = Array[1..20] of Integer; CstrIndex = 1..CstrSize+1; Cstring0 = packed array [CstrIndex] of char; function Cstr(protected S: string): Cstring0; function rmdir(protected Path: Cstring0): integer; C_language; function sys_stat(protected Path: Cstring0; var Buf: StatRecord): integer; asmname 'stat'; implementation function Cstr; var I, U: CstrIndex; Result: Cstring0; begin U := length(S); if U > CstrSize then U := CstrSize; for I := 1 to U do Result[I] := S[I]; Result[U+1] := chr(0); Cstr := Result; end { Cstr }; end. Program ml; uses gpc, { cstrings,} ml2; procedure make_standard_error(progname:Tstring); var retval1:integer; statrec:statrecord; begin retval1:=sys_stat(Cstr(progname+'.err'),statrec); end; Begin Writeln('Starting'); Make_standard_error('ml'); end. -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324. Web site: <http://www.tynecomp.co.uk>.

4 17

Re: Gpc package for `pkgadd' available?
by Rick Roland 23 Jan '03

23 Jan '03

A million tanks! >-----Original Message----- >From: Mariusz Zynel [mailto:mariusz@math.uwb.edu.pl] > >I've just build GPC 2.1 (on top of GCC 2.95.2) on Solaris 8 x86. >The package can be download from: > >ftp://math.uwb.edu.pl/solaris/x86/5.8 > >-- > . >Mariusz Zynel University of Bialystok, Institute of Mathematics > Akademicka 2, 15-267 Bialystok, Poland >----------------------------------------------------------------------- >mailto:mariusz@math.uwb.edu.pl office: +48 (85) 745 7552 >http://math.uwb.edu.pl/~mariusz mobile: +48 (604) 777 588 > > LGT Financial Services Limited Herrengasse 12, P.O. Box 85, FL-9490 VADUZ Principality of Liechtenstein Tel. +423 235 24 44, Fax +423 235 24 40 Mail: lgt.fs(a)lgt.com Web: http://www.lgt.com ---------------------------------------------------------------------- Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it. -----------------------------------------------------------------------

1 0

Gpc package for `pkgadd' available?
by Roland Rick 22 Jan '03

22 Jan '03

Hallo all Does anyone know, where a Solaris 8 package (for `pkgadd') of the current (is this now 2.1 or 2.95.x? I'm a litte confused by the version numbers) stable gpc version is available? Many thanks for any help! CU, Roland

5 9

gpc-20021128/gcc-3.2.1/mingw32 test results
by J. David Bryan 21 Jan '03

21 Jan '03

Notes from building gpc-20021128 with gcc-3.2.1 configured for i486-pc-mingw32: * GPC will not build with the version of os-hacks.h on the GPC Web site; a patched version is required. * GPC will build with the FSF gcc-3.2.1 sources, but compiled programs that use files will fault in _p_bind (bad pointer). Building with the FSF sources + the Mingw-specific patches from the mingw.org Web site works. * GPC will not run on Win9x/WinME systems, due to a Mingw-specific change in gcc/config/i386/xm-mingw32.h. Patching gpc.c is required. * Test suite results are: agettext2test.pas: SKIPPED: libintl not installed crttest.pas: SKIPPED: no curses library found environo.pas: SKIPPED: setenv not present in libc fjf480a.pas: SKIPPED: librx not installed fjf480b.pas: SKIPPED: librx not installed fjf480c.pas: SKIPPED: librx not installed fjf582.pas: failed [Exception c00000fd (stack overflow)] fjf663.pas: failed [runs forever -- aborted by ulimit] gettexttest.pas: SKIPPED: libintl not installed gmptest.pas: SKIPPED: libgmp not installed pipetest.pas: SKIPPED: IOSelect not yet implemented for mingw regextest.pas: SKIPPED: librx not installed # of GPC tests 2855 # of GPC tests passed 2843 # of GPC tests skipped 10 # of GPC tests failed 2 "fjf582" fails because GPC allocates about 144KB of stack with -O0 and -O1 but allocates about 4.1MB with -O2 and -O3. The default stack reserve set in "ld" is 2MB. Increasing the default manually allows "fsf582" to succeed. Specifically, the generated code is: [with -O0 and -O1] _pascal_main_program: pushl %ebp movl %esp, %ebp movl $147976, %eax call __alloca ... [with -O2 and -O3] _pascal_main_program: pushl %ebp movl $4259848, %eax movl %esp, %ebp call __alloca ... "fjf663" appears to loop indefinitely and is aborted due to time limit. -- Dave

4 18

How to make gpc *.o linkable for native SUN F77 compiler
by Roland Rick 21 Jan '03

21 Jan '03

Hi gpc cracks I have an interesting problem: Original source: Borland Delphi 6 Target source: gpc Because gpc knows a lot about Delphi concepts, this is no problem at all and will be done quite quickly. But: The functions and procedures of the gpc object code (e.g. myFuncs.o, produced by gpc) should be linkable with an VERY OLD native SUN SPARC compiler, the `f77' from SUN's WorkShop 4.2 (a release from 1995). YES, tasks like that really exist! If no one can help, I have to translate the Delphi/gpc source to standard Pascal, what means, working again with include files instead of UNITS (and many more worse things). Remembers me of 1985... ;) (Last but not least this will also be an absolutely boring job to do...) Unfortunately no newer native `pc' from SUN exists. I REALLY would appreciate any help. Cheers, Roland

5 5

Re: Pascal in Mac OS X
by Adriaan van Os 18 Jan '03

18 Jan '03

Sources, binaries, patches and building instructions for GPC on Mac OS X can be found at http://www.microbizz.nl/gpc.html Regards, Adriaan van Os

1 0

can I use C++ units in GPC projects? It tells me "C++ compiler is not installed" although it present in the system
by IM 17 Jan '03

17 Jan '03

Hi All! I need to use C++ units (*.cpp) in my GPC projects. If I use C units (*.c) in my project (just like {$L socketmain.c}) it's ok but if I try to use {$L socketmain.cpp} then Pascal compiler tells me gpc: ./socketmain.cpp: C++ compiler not installed on this system. But it installed. Two things I tried to do: 1. Export environment variables CXX and CPP with "g++" value 2. Change *cpp_options in my gpc specs file. There was no such section before, so I inserted it into from gcc specs file. Now this section looks like: *cpp_options: %{C:%{!E:%eGNU C does not support -C without using -E}} %{std*} %{nostdinc*} %{C} %{v} %{I*} %{P} %{$} %I %{MD:-M -MF %W{!o: %b.d}%W{o*:%.d%*}} %{MMD:-MM -MF %W{!o: %b.d}%W{o*:%.d%*}} %{M} %{MM} %W{MF*} %{MG} %{MP} %{MQ*} %{MT*} %{M|MD|MM|MMD:%{o*:-MQ %*}} %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2 -D__GNUC_PATCHLEVEL__=%v3} %{!undef:%{!ansi:%{!std=*:%p}%{std=gnu*:%p}} %P} %{trigraphs} %c %{Os:-D__OPTIMIZE_SIZE__} %{O*:%{!O0:-D__OPTIMIZE__}} %{fno-inline|O0|!O*:-D__NO_INLINE__} %{ffast-math:-D__FAST_MATH__} %{fshort-wchar:-U__WCHAR_TYPE__ -D__WCHAR_TYPE__=short\ unsigned\ int} %{fshow-column} %{fno-show-column} %{fleading-underscore} %{fno-leading-underscore} %{foperator-names} %{fno-operator-names} %{ftabstop=*} %{remap} %{g3:-dD} %{W*} %{w} %{pedantic*} %{H} %{d*} %C %{D*&U*&A*} %{i*} %Z %i %{E:%{!M*:%W{o*}}} But nothing changed. What have I do to compile projects with C++ files? I have not ideas for the present, please give them to me:) Software versions: Linux: RedHat (kernel 2.5.52) gpc: gpc version 2.1 (20020510), based on 2.95.3 20010315 (release) gcc: gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110) mailto:marny@rambler.ru

5 8

Re: Upper/lower case in identifiers
by Tom Schneider 15 Jan '03

15 Jan '03

Frank: > > ... So if I want to cut and paste to search for the name in > > my program, it fails. > > I didn't like this as well, and that's exactly why I've brought up > the issue. Oh good! > > Why not take the first [occurrence] of a variable as the name to use on > > all output? > > The first, or the most recent one, that's still a question. After > some experimenting, there seem to be points for both ways. I'm > implementing the latter now (though it should be easy to change). > So, e.g.: > > program Baz; > > procedure Foo; > var BaR: Integer; > begin > end; > > begin > WriteLn (bar) > end. > > will complain about an unknown identifier `bar', not `BaR' ... I would strongly vote for using the first occurrence because that is the one which is the definition! If one is disciplined, then all later cases should follow the definition! > > Note: only Germans like to capitalize all nouns! > > I know, and that's not the reason why this rule was introduced (long > ago). Rather it was to avoid asmname conflicts with libc routines > etc. -- see, e.g., Pierre's mail for detailed explanations. Oh. I think that you should either: 1. ignore the conflicts and let the user deal with them. Warn the user that a conflict has occurred. or 2. protect the user from such conflicts so they never have to deal with them. I want to be able to write 'vanilla flavor' Pascal programs that will work on many compilers. I have great hope that GPC is the end-all solution, but even so it is nice to allow my programs to work on other compilers. So I do not want to be forced to change variable names because of conflicts specific to the internal workings of a particular compiler. For example, the fact that I cannot name a procedure 'main' on the Sun compiler is rather obnoxious - I was forced to rename all my 'main' procedures to 'themain', and even have a tool for modifying Pascal programs to make such variable-name switches: http://www.lecb.ncifcrf.gov/~toms/delila/worcha.html ... written in vanilla Pascal of course! Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

3 2

Re: Upper/lower case in identifiers
by Tom Schneider 14 Jan '03

14 Jan '03

| I actually think that your existing convention (1st upper, rest | lower) is an excellent way to resolve most things. I am quite sure | I don't have a grasp of the conflicting systematic I also don't understand the conflicts, but this rule is painful. If I name a variable 'something' then I expect to be able to search the error messages for 'something' but of course it got changed to 'Something'. So if I want to cut and paste to search for the name in my program, it fails. Why not take the first occurence of a variable as the name to use on all output? Then internally have a table (as others have suggested) mapping the first occurence to the actual one. Flag variables that map to the same word but which are not the same. This way the compiler merely demands consistency, but is 'case insensitive'. Note: only Germans like to capitalize all nouns! Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

4 4

Re: Upper/lower case in identifiers
by Tom Verhoeff 14 Jan '03

14 Jan '03

Frank wrote: >As you probably know, GPC currently converts all identifiers to >first letter upper-case/rest lower-case. Since this is often not >nice, I plan to change this. This would affect at least the >following things: It is not clear to me what change you propose. You probably mean (because this is easiest to implement) to (optionally?) drop the conversion altogether and consequently have case-sensitive identifiers. This is contrary to Pascal standards, but has some advantages in the C/Unix-dominated tool world. Of course, I would NOT recommend program Example1; const MIXEDCASE = True; var MixedCase: Integer; mixedCase: Real; ALTERNATIVELY, it might be possible to convert all occurences of the same identifier (modulo case) to the casing found on the defining occurrence. Thus program Example2; var MixedCase: Integer; ... readln ( mixedCase ) ; writeln ( mixedcase ) would work properly and all external handling would be via the identifier MixedCase. This also seems easy to implement (at the expense of a slightly more expense compare for lookup) and more in line with Pascal: When creating a symbol-table entry you store the casing as found. When looking up a name you compare names modulo case (e.g. convert both comparands to lower case), when you get a hit you use the actual casing found in the symbol table. This makes Example1 illegal and makes Example2 work as expected. >While I'm at it, it might be easy to add a warning if an identifier >is used with varying case (something like `var Foo: Integer; [...] >WriteLn (FOO)'). Such an option would be quite helpful, even if you do not make changes to the case handling. >- Any ideas for the name of the option? (`-Widentifier-case'?) Seems fine. >- Default? (I suppose off, though I think I myself would prefer on.) I would prefer on, because we have come to know that case variations of the same identifier are confusing. >- Should it work across units/modules? Or should it be a tri-state > option (never/current file/global)? Across units/modules would be best, but I can imagine that with legacy code it might be helpful to restrict the scope of the checking. Tom

4 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc