Gpc July 2012

gpc@gnu.de

4 participants
9 discussions

GPC with gcc-4.[23]
by Waldek Hebisch 18 Apr '13

18 Apr '13

I did some work on updating gpc to newer gcc versions. You can find it at GitHub: https://github.com/hebisch/gpc This is experimental work. 4.2 and 4.3 ports (on "master" Git branch) are basically in "works for my purpose" state: on my machine compiler builds and passes test suite with small (but nonzero) number of failures. On 4.5.1 there is initial port to gcc-4.[45] -- this one is broken from user point of view and may be of some use only for people who want to seriously work on the compiler. Note that this is _not_ a release. There are relatively easy to fix but non working things (in particular some features of Makefiles are broken). Testing was limited to running testsute just for one configuration. I estimate that fixing easily fixable stuff and polishing things would take me about a week -- unfortunately I am busy with other things. So I decided to make the code available "as is". If there will be bug reports, I will look at them and there is reasonable chance that I will fix them. But otherwise I do not plan to work on gpc in near future. If you want to try the code note that there are changes to build process, look at toplevel README file. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

4 15

Re: GPC git
by Waldek Hebisch 02 Aug '12

02 Aug '12

Prof A Olowofoyeku (The African Chief) wrote: > > On 25 Jul 2012 at 16:09, Waldek Hebisch wrote: > > > I wrote: > > > > > Hi Waldek > > > > > > Something is broken under Win32 (compiling with msys environment). > > > This is what I have noticed so far; > > > > > > 1. rts-config.inc is not installed when you run 'make pascal.install' > > > 2. make-lang.inc has "@true" in it. This results in a "command not > > > found" error > > > > > > I will report other problems as I isolate them - but there is a big > > > difference from the release version, in the file sizes when you run > > > 'make pascal.bindist' (about 500kb difference in the tarball size). I > > > will investigate further and will report back in due course. > > > > I have found the issues (under Win32, gcc-3.4.5 backend sources); > > > > 1. "@true" causes an error in 'pascal.install' and 'pascal.bindist', so > > I have removed it. > > > > 2. "rts-config.inc" does not get installed. I believe it is something to > > do with "TREE_GIMPLE_H" definitions. Since I don't fully understand > > TREE_GIMPLE_H, I have manually copied the code that installs the file to > > the relevant section. > > > > 3. The GPC info files are not built or installed. I am yet to find a > > solution to that. > > Solved: I found that the git p/doc/info/ does not contain the .info > files. It only contains a zero-byte file called ".git_is_stupid" ! > > Also, p/doc/generated/ does not contain "gpc-run.1". It also only > contains a zero-byte file called ".git_is_stupid". > > How do I update the git repository? Or will you do it yourself? Sorry, I forgot to mention this: git repository is supposed to contain only source files. So machine generated files like content of p/doc/info/ and p/doc/generated/ is omited. Building gpc should fill those directores with content. But for this you need appropriate tools, in particular 'texinfo' package. Look at the output of 'configure' in build log, if configure can not find needed tools it will print a message and skip building documentation. Git repository does not replace release tarballs -- simply it gives access to code between releases. Content is similar to what 'minimal' gpc tarballs used to contain. Concerning updating git repository: I probably could give write access to persons needing it (I would have to check github instructions). However, more popular method seem to be that developer use GitHub 'fork' feature to create own version and then ask maintainer of main repository to merge changes back to master version. Anyway, for documentation the only thing that needs updating is README -- it should clearly say that you need to have 'texinfo'. BTW: Please keep discussion on the mailing list. One, other folks may have similar problems and learn solution from archived message. Second, others may find good answer earlier. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 3

Re: GPC git
by Waldek Hebisch 01 Aug '12

01 Aug '12

Prof A Olowofoyeku (The African Chief) wrote: > > I wrote: > > > Hi Waldek > > > > Something is broken under Win32 (compiling with msys environment). This > > is what I have noticed so far; > > > > 1. rts-config.inc is not installed when you run 'make pascal.install' 2. > > make-lang.inc has "@true" in it. This results in a "command not found" > > error > > > > I have found the issues (under Win32, gcc-3.4.5 backend sources); > > 1. "@true" causes an error in 'pascal.install' and 'pascal.bindist', so > I have removed it. The line is now: echo "pascal.install done" ; @true Try: echo "pascal.install done" ; true that is remove '@' sign. Note: both lines start from a tab. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

3 7

string literal as const var parameter
by Jay Michael 24 Jul '12

24 Jul '12

gpc 20070904, based on gcc-3.4.5 (mingw special) I got a compilation error, "type mismatch", when I passed a string literal to a routine with a formal parameter of "const var s : string". In tests, this had been acceptable to the compiler. I find that whether it is acceptable seems to be a function of whether the call is preceded by another call (to a different routine), passing a string literal to (as?) a "const s : string" formal parameter. jsm1bad.pas gets a "type mismatch" compilation error. jsm1ok.pas compiles, links, and executes.

6 10

Re: unit/procedure same name, unhelpful error
by Waldek Hebisch 18 Jul '12

18 Jul '12

Jay Michael wrote: > some of the source when it issues a compilation error? Like > > jsm2.pas:5:jsm2m; > jsm2.pas:5:^---error: expression used as a statement > Currently no such option. > In the test case it's not much more informative than the line number. > In the original code, where the procedure had 5 or 8 arguments, it > would have focused me on the procedure that turned out to also be > a module name. (I spent a lot of time getting the error message=20 > backwards and trying to see if one of the arguments was being affected > by a preprocessor directive that changed it into a procedure call or > other statement where I needed an expression.) > > Does the compiler have enough information to reconstruct the=20 > source representation of the expression it thinks is being used as > a statement? I know there's no limit to how big that could be. > Again, I think it would help to know exactly which source is > upsetting the compiler. > Compiler keeps line numbers of expressions in the input. ATM compiler does not know position of offending item within the input line. Also, the expressions are transformed and what compiler have in hand may be quite different from user input. In principle printing compiler data in Pascal-like form could be of some use, but compiler have no routine for doing this. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

Windows install
by Jay Michael 17 Jul '12

17 Jul '12

Where is the source corresponding to GPC 20070904? Where should I find the .gpi files for supplied units (like unit GPC)? If I install a binary distribution for Windows, is there a follow-up step that must be performed manually? (like compiling GPC.PAS) Where would I find documentation of the entry points provided by unit GPC? I downloaded and installed dev_gnu_pascal-1.9.4.13.exe I started with mingw-get-inst-20120426.exe -- It downloaded and installed whatever it wanted. From the size of dev_gnu_pascal-1.9.4.13.exe I had assumed it included the source of GPC, but I haven't been able to find it. In http://www.gnu-pascal.de/alpha, there is no gcc-core-3.4.5, and there is no gpc-20070904.

3 4

unit/procedure same name, unhelpful error
by Jay Michael 10 Jul '12

10 Jul '12

gpc 20070904, based on gcc-3.4.5 (mingw special) I got a compilation error, "expression used as a statement". When I finally realized I had a unit and a procedure in the unit with the same name, I changed one name and the error went away, so I'm guessing the duplication of name was somehow responsible. I am not asking to be allowed to name a unit the same as some entity within the unit. I am asking that the error message be changed to something that would have spared me thrashing around until I noticed that I had duplicated a name. Failing that, could someone explain how what I did was an "expression used as a statement"? >gpc -c -x Pascal jsm2m.int >gpc -c jsm2.pas jsm2.pas: In main program: jsm2.pas:5: error: expression used as a statement

2 1

Re: string literal as const var parameter
by Waldek Hebisch 10 Jul '12

10 Jul '12

> > > From: Waldek Hebisch <hebisch(a)math.uni.wroc.pl> > > Subject: Re: string literal as const var parameter > > To: "Jay Michael" <jmichael_ll(a)yahoo.com> > > Cc: gpc(a)gnu.de > > Date: Monday, July 9, 2012, 8:15 AM > > Jay Michael wrote: > > > > > > procedure enabler( const s : string ) ; > > > procedure rejecter( const var s : string ) ; > > > > > > enabler( 'lit2' ) ; > > > rejecter( 'literal' ) ; > > > > > > > > > Why did compiling the call to > > > "enabler" first result in the compiler > > > accepting the call to "rejecter"? > > > > Plain bug: compiler got wrong internal bookkeeping and > > compiling enabler overwrote info about parameter list > > of rejecter. > > > Is this bookkeeping error fixed by the patch > you posted? Is there a separate patch you did not > post? > The patch should fix both problems. gpc uses code generator from gcc -- the part taken from gcc is usually called backend. To compile Pascal program gpc first builds appropriate data structures describing (in machine-indpendent way) code which should be generated. Layout of such data structures is defined by backend. Also backend provides several functions which create and transform data structures. To save space and usualsy also execution time backend tries to share the same data structures between parts of program. Apparently in case ouf your program backend decided that it can use the same data structure to describe properties of parameters to 'enabler' and 'rejecter'. Previous gpc code called backed function 'build_type_variant' which allows backed to re-use its input argument if there are no change and it seems that backend decided that the change done by gpc is a no-op and reused the data. The patch uses 'build_type_copy' function which disalows sharing in this case. Conseqently, this elliminates sharing of parameter description between 'enabler' and 'rejecter' and prevents overwriting. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

Re: string literal as const var parameter
by Jay Michael 09 Jul '12

09 Jul '12

procedure enabler( const s : string ) ; procedure rejecter( const var s : string ) ; enabler( 'lit2' ) ; rejecter( 'literal' ) ; Why did compiling the call to "enabler" first result in the compiler accepting the call to "rejecter"?

2 1

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