Gpc

gpc@gnu.de

5400 discussions

gpc in Mac OSX Lion
by Leo Brewin 25 Oct '11

25 Oct '11

Hi troops, Has anybody successfully compiled GPC under MacOSX Lion? I've tried doing so using Adriaan's sources (gpc346u4-sources.dmg) but I encountered the following errors (as listed below). Any help would be greatly appreciated. Cheers, Leo Brewin School of Mathematical Sciences Monash University stage1/xgcc -Bstage1/ -B/Users/leo/tmp-pascal/gpc346u4/i386-apple-darwin11/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition -DHAVE_CONFIG_H -DGENERATOR_FILE -o genmodes \ genmodes.o errors.o ../libiberty/libiberty.a ld: warning: -macosx_version_min not specificed, assuming 10.7 Undefined symbols for architecture i386: "___bzero", referenced from: _htab_empty in libiberty.a(hashtab.o) ld: symbol(s) not found for architecture i386 collect2: ld returned 1 exit status make[2]: *** [genmodes] Error 1 make[1]: *** [stage2_build] Error 2 make: *** [bootstrap] Error 2

2 2

Latest versions of gpc
by John Gordon Ollason 13 Oct '11

13 Oct '11

Greetings, Having upgraded to Fedora 15 I'd like to install gpc again, but I don't know where to look for the latest version. I have found a source for gpc-20070904 but I haven't yet managed to compile it. (Is that the latest version?) I suppose that by now the language must have lost most of its users, but I still, occasionally, write some Pascal code, and would like to be able to compile it. Thanks for any advice, John Ollason

4 5

Missing crt1
by Kevan Hashemi 15 Sep '11

15 Sep '11

Hi, I recently moved from MacOS 10.4 to 10.5 on my old PPC laptop. I re-installed GPC for MacOS 10.5 from the Microbizz site. When I try to compile a hello world program, I get the following error: gpc p.pas /Xcode2.5/usr/bin/ld: can't locate file for: -lcrt1.o collect2: ld returned 1 exit status The file crt1.o is sitting in /Xcode2.5/SDKs/MacOSX10.4u.sdk/usr/lib When I add the above directory to my PATH, I still have problems. My path is now: /usr/bin:/bin:/usr/sbin:/sbin:/Xcode2.5/usr/bin:/Xcode2.5/SDKs/MacOSX10.4u.sdk/usr/lib Do I have my path set up wrong? Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

3 7

Ada translation using gpc.
by Pascal Pignard 09 Aug '11

09 Aug '11

Hello. I've object Pascal source codes I would like to translate in Ada. Though newP2Ada translator does good job for standard Pascal, it isn't object aware. Thus I've created objP2Ada, a new branch, which can parse object Pascal syntax. http://sourceforge.net/projects/p2ada But some nice features work partially as the parser has some limitations. What about to produce Ada code with modified gpc? Is there some interested people in helping gpc modification? I've got gpc source codes for Mac from http://www.microbizz.nl/gpc.html. Thanks to perfect building script from Adriaan, I was able to build completely gpc on Mac OS X 10.6. I've some ideas for translation of Pascal structures from my experience with objP2Ada. What would be the next steps with gpc? Regards, Pascal. http://blady.pagesperso-orange.fr

1 0

Compiler error output
by Adriaan van Os 01 Jul '11

01 Jul '11

Waldek Hebisch wrote: > I did some work on updating gpc to newer gcc versions. You can > find it at GitHub: Another issue I found is that in compiler error output, the line number is equal to 0 for most of the errors. program error (Output); procedure nonsense; begin xxx; end; yyy; begin zzz end. [P18:~/gpc/testgpc/adriaan] adriaan% gpc error.pas error.pas: In procedure `nonsense': error.pas:0: error: undeclared identifier `xxx' (first use in this routine) error.pas:0: error: (Each undeclared identifier is reported only once error.pas:0: error: for each routine it appears in.) error.pas: At top level: error.pas:9: error: syntax error before `yyy'

1 0

[Fwd: GCC 4.3.6 Released]
by Adriaan van Os 28 Jun '11

28 Jun '11

-------- Original Message -------- Subject: GCC 4.3.6 Released Date: Tue, 28 Jun 2011 15:05:50 +0200 (CEST) From: Richard Guenther <rguenther(a)suse.de> Reply-To: gcc(a)gcc.gnu.org To: gcc-announce(a)gcc.gnu.org CC: gcc(a)gcc.gnu.org The GNU Compiler Collection version 4.3.6 has been released. GCC 4.3.6 is a bug-fix release containing fixes for regressions and serious bugs in GCC 4.3.5. This release marks the end of the maintainance of the GCC 4.3 series. The release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank individually!

1 0

Test
by Frank Heckenbach 27 Dec '10

27 Dec '10

Just a test, please ignore. Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

1 0

Running a 32 bit binary built with GPC on a 64 bit system
by Martin Liddle 16 Nov '10

16 Nov '10

We build our executables using a 32 bit version of GPC (20070904 based on gcc-3.4.6) running on a 32 bit kernel. A customer has tried to run the executable on a 64 bit kernel (Fedora 14) and gets the error message: manager.e: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory Error 126 whilst executing manager. Press RETURN I would expect it to be possible to run a 32 binary on a 64 bit system. Is this correct and if so what additional steps might be required? -- Martin Liddle, Tynemouth Computer Services, 3 Kentmere Way, Staveley, Chesterfield, Derbyshire, S43 3TW. Web site: <http://www.tynecomp.co.uk>.

3 2

Inefficiency of `mod'
by Emil Jerabek 25 Oct '10

25 Oct '10

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

10 16

Re: Null characters in strings
by Morton, John 12 Sep '10

12 Sep '10

My thanks once again. Things are now gradually starting to come together. I should first clarify that we never manipulate the time field - it's the precise 32-bit bit pattern (time) that gets sent to the outside world that matters, not what gpc Pascal (or any language/compiler) actually uses to hold the 32 bit time field. I am not yet a gpc user and was unaware of the type casting approach. (My last Pascal experience was some years ago and that was on mainframe/mini-computers, not in the PC/Linux world. Since then I've worked in ADA and greatly liked that language.) Type casting is exactly the KISS approach I was looking/hoping for. In great preference to the fragile and potentially non-portable approaches of variant records or the parameter mapping "trick" at the library interface. Also new to me are the gpc bitwise operators, thanks for mentioning them. They will be a great help in rewriting parts of our code. Once I get "Hello World" working I'll be spending some time with the current gpc manual to see what else in gpc is new to me. I expect I will find other things in gpc that will be of immediate practical use to us. Hopefully the manual also covers how to create GPC makefiles that use individually compile multiple source files, persistent object files and a separate user controllable linker step. As surmised, the time taken to build a message is not (yet) time-critical. However "endian-ism" might (but shouldn't) become an issue. We do not manipulate the time and not care how the bytes are actually stored because it's only the bit pattern of the "4 byte time field" that matters when the message is sent. The current conceptual model (without type casting) is: GetSystemTime( X ) - return 32 bit time in X (as a 4 byte string) Y = X + rest-of-message - concatenate strings to get final message string SendMessage( Y ) - hardware sends the final message sting As revised to use type casting (using the types at the end of this message): GetSystemTime( Z ) - return the time in Z (Z is defined as 32 bits) X = Char4( Z ) - cast the 32 bit time to a 4 byte string Y = X + rest-of-message - concatenate strings to get final message string SendMessage( Y ) - hardware sends the final message string So why use a 4 byte string and not something else? Everything else in the application uses strings - which makes using a string the simplest way for us to handle the 32 bit time field. Comments? Improvements? Thanks. BTW, My viewpoint is that if something can be done in an easily understood (=KISS) manner using only standard gpc Pascal constructs (i.e. without "tricks" or "virtuous" (=often obtuse) coding) it is "pure" Pascal. By those standards only the second version is "pure" Pascal. -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Frank Heckenbach Sent: September 7, 2010 08:03 PM To: gpc(a)gnu.de Subject: Re: Null characters in strings Morton, John wrote: > My thanks for confirming that writeln is not implemented using C's > printf function (I can't remember where I got that idea) and that gpc's > writeln can send all 256 characters (absolutely necessary to handle > binary time as a string). > > On reflection I realize I have misstated our problem. But I think I > also have a work-around for it. > > The issue is that the supplied library returns the time as a 32 bit > binary value. The problem is essentially how to coerce the 32 bits into > a corresponding 4 character gpc string. (BTW, they are the first 4 > bytes of every message sent by our application). > > I had hoped that the coercion (effectively a type cast) would be easy to > accomplish within Pascal. I then thought about variant records but that > did not seem feasible. > I have since realized that the conversion could be done where we define > the interface to the external routine. In the Pascal function > definition use a 4 character fixed length string for the time field and > have the linker map that string to the corresponding 32 bit value field > used by the library (probably by using pass-by-address, possibly > pass-by-value). > Not a pure Pascal approach but a practical one - as long as you are well > aware of the pitfalls. (In the "pure" approach the Pascal interface > parameter would be a 32 bit unsigned value that gets converted/mapped by > Pascal to the corresponding 4 byte string). The only "pure" Pascal approach would be converting the value to single bytes using "div"/"mod" (GPC also supports bitwise "and" and "shl"/"shr") and then to characters using "Chr". If it's not time-critical, this might actually be worth considering, since it avoids endianness issues. With GPC, also type-casting should work. Something like this: program Foo; type Card32 = Cardinal attribute (Size = 32); Char4 = array [1 .. 4] of Char; var a: Card32; b: Char4; begin b := Char4 (a); a := Card32 (b); end. Variant records are sometimes abused(!) for this purpose, but I don't recommend it. Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

2 1

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