Gpc March 2003

gpc@gnu.de

23 participants
45 discussions

gpc building
by Mehdi Khaldi 21 Mar '03

21 Mar '03

Hi, I fixed the missed space in the patch file. Then I built the gpc compiler with the make command. It worked until an other error occured : /Home/Users/mkhaldi/workspace/gpc-build/gcc/xgcc -B/Home/Users/mkhaldi/workspace/gpc-build/gcc/ -B/usr/local/sparc-sun-solaris2.7/bin/ -B/usr/local/sparc-sun-solaris2.7/lib/ -isystem /usr/local/sparc-sun-solaris2.7/include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,-h,libgcc_s.so.1 -Wl,-z,text -Wl,-z,defs -Wl,-M,libgcc/sparcv9/libgcc.map -o sparcv9/libgcc_s.so.1 -m64 libgcc/sparcv9/_muldi3.o libgcc/sparcv9/_negdi2.o libgcc/sparcv9/_lshrdi3.o libgcc/sparcv9/_ashldi3.o libgcc/sparcv9/_ashrdi3.o libgcc/sparcv9/_ffsdi2.o libgcc/sparcv9/_clz.o libgcc/sparcv9/_cmpdi2.o libgcc/sparcv9/_ucmpdi2.o libgcc/sparcv9/_floatdidf.o libgcc/sparcv9/_floatdisf.o libgcc/sparcv9/_fixunsdfsi.o libgcc/sparcv9/_fixunssfsi.o libgcc/sparcv9/_fixunsdfdi.o libgcc/sparcv9/_fixdfdi.o libgcc/sparcv9/_fixunssfdi.o libgcc/sparcv9/_fixsfdi.o libgcc/sparcv9/_fixxfdi.o libgcc/sparcv9/_fixunsxfdi.o libgcc/sparcv9/_floatdixf.o libgcc/sparcv9/_fixunsxfsi.o libgcc/sparcv9/_fixtfdi.o libgcc/sparcv9/_fixunstfdi.o libgcc/sparcv9/_floatditf.o libgcc/sparcv9/_clear_cache.o libgcc/sparcv9/_trampoline.o libgcc/sparcv9/__main.o libgcc/sparcv9/_exit.o libgcc/sparcv9/_absvsi2.o libgcc/sparcv9/_absvdi2.o libgcc/sparcv9/_addvsi3.o libgcc/sparcv9/_addvdi3.o libgcc/sparcv9/_subvsi3.o libgcc/sparcv9/_subvdi3.o libgcc/sparcv9/_mulvsi3.o libgcc/sparcv9/_mulvdi3.o libgcc/sparcv9/_negvsi2.o libgcc/sparcv9/_negvdi2.o libgcc/sparcv9/_ctors.o libgcc/sparcv9/_divdi3.o libgcc/sparcv9/_moddi3.o libgcc/sparcv9/_udivdi3.o libgcc/sparcv9/_umoddi3.o libgcc/sparcv9/_udiv_w_sdiv.o libgcc/sparcv9/_udivmoddi4.o libgcc/sparcv9/unwind-dw2.o libgcc/sparcv9/unwind-dw2-fde.o libgcc/sparcv9/unwind-sjlj.o -lc && rm -f libgcc_s_sparcv9.so && ln -s sparcv9/libgcc_s.so.1 libgcc_s_sparcv9.so ld: fatal: file /lib/sparcv9/values-Xa.o: wrong machine class What is the problem? How to fix it? Thanks

1 0

patch problem
by Mehdi Khaldi 21 Mar '03

21 Mar '03

Hi, I try to build gpc on a solaris platform (solaris7). I use GCC 3.2.1 . The gpc version I want to build dates 20030209. When I execute the configure file, an error occurs : *** *** Detected GCC version 3.2.1. *** GPC 2.1 requires a patch to GCC to build with version 3.2.1. *** This patch will now be applied. *** Press ENTER to continue, Ctrl-C to abort. *** Malformed patch at line 67: patch: Second character must be a ' ' character. What do I do to resolve this problem? Do I fix the patch? Where is the patch? Thanks.

2 1

Preparedisposepointer eats time
by Marten Jan de Ruiter 20 Mar '03

20 Mar '03

Hi all, I got some trouble compiling a finite element program called charles. I used GNU Pascal version 20020910, based on gcc-2.95.2 19991024 (release). to compile the program with profiling using the switch -pg. Because the program took an unusual amount of time running, I made a profile. Profiling the run yields that Preparedisposepointer uses exceedingly long times. This is the result for a fairly small problem, used to get output for this mail. I have seen 95% time use for Preparedisposepointer, but lost that profile testing other versions of gpc, and I am not patient enough to regenerate it, now that this output also shows the problem: /hole 17 % gprof `which charles` | more Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 59.13 3.14 3.14 Preparedisposepointer 3.20 3.31 0.17 _p_read_longreal 3.20 3.48 0.17 _p_trim ... (sorry for the crappy lay-out) Charles, compiled by an older version (see below) of gpc (seems to) works fine, but suffers from a memory leak in the file-io routines. (older version of gpc) /hole 20 % /usr/tm/bin/gpc --version 2.95.2 19991024 (release) I was not able to locate the difference in the pascal sources that explains why Preparedisposepointer now needs so much time. However, I suspect FreeMemPtr^ (in rts/heap.pas) does some things. A colleague mentioned that it might be a lot of moving in memory to prevent fragmentation. I tried to create a test program that creates a linked list of integers and disposes it. Then the allocation and de-allocation times are similar in magnitude: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 44.07 1.30 1.30 1 1.30 1.30 pascal_main_program 15.93 1.77 0.47 _p_new 10.85 2.09 0.32 Preparedisposepointer 10.51 2.40 0.31 _p_dispose Using 8 % gpc --version gpc 20030209, based on gcc-3.2.1 does not change much: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 46.82 1.40 1.40 1 1.40 1.40 pascal_main_program 16.39 1.89 0.49 _p_dispose 13.04 2.28 0.39 _p_new 9.36 2.56 0.28 Preparedisposepointer 6.69 2.76 0.20 Addheaprange Still allocation and deallocation take similar times Now I have the following questions: Any idea why deallocation takes forever in the FE program as compared to allocation? Maybe the reason is that the data-structure is slightly more complicated than a linked list of integers ;-) How can I isolate the problem? What kind of feedback can I provide you with to isolate and solve the problem? Gpc 20030209, based on gcc-3.2.1 does not compile the FE program, but that is another story, which is in my next mail. Regards, Marten Jan

3 6

Re: Bug report request
by Frank Heckenbach 20 Mar '03

20 Mar '03

Marten Jan de Ruiter wrote: > I tried to do so, but could not locate a core. To verify core-dumping > abilities, I whipped up the program at the end of my mail, which ran > as intended, and produced a nice core. Sorry, I forgot, gcc-3 disables coredumps explicitly. Try the included patch. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

TimeStamp?
by Peter N Lewis 19 Mar '03

19 Mar '03

TimeStamp has a field: TimeZone : Integer; { in seconds } Can GPC not sometimes have 16 bit Integer? Because if so, that field would be too small. Should it be defined as Integer(32)? Hmm, the TimeZone on my system comes back as: TimeZone (in seconds): -1878692308 It should be +8 hours (28800). Enjoy, Peter. -- <http://www.interarchy.com/> <http://download.interarchy.com/>

3 5

Bug report request
by Marten Jan de Ruiter 19 Mar '03

19 Mar '03

Hi all, I got some trouble compiling a finite element program called charles, see my previous mail `Preparedisposepointer eats time' gpc 20030209, based on gcc-3.2.1 barfs on me with the following output: <cut> #progress# POST/post.p (29) #progress# ELEMENTS/initelem.p (79) #progress# ELEMENTS/TRIANG_TOOLS/triang_init.p (147) #progress# ELEMENTS/TRIANG_TOOLS/triang_init.p (218) #progress# ELEMENTS/BED/initbed.p (23) #progress# ELEMENTS/BUBBLE_BED/initbbed.p (24) #progress# ELEMENTS/BUBBLE_BED/initbbed.p (249) #progress# MATERIAL/clpt.p (21) #progress# MATERIAL/clpt.p (219) #progress# MATERIAL/clpt.p (289) #progress# MATERIAL/clpt.p (381) #progress# MATERIAL/clpt.p (434) #progress# MATERIAL/clpt.p (585) #progress# MATERIAL/clpt.p (723) #progress# MATERIAL/clpt.p (871) #progress# MATERIAL/clpt.p (1074) #progress# MATERIAL/clpt.p (1253) #progress# MATERIAL/clpt.p (1350) #progress# MATERIAL/clpt.p (1599) #progress# MATERIAL/clpt.p (1835) #progress# MATERIAL/clpt.p (1913) #progress# MATERIAL/clpt.p (2110) MATERIAL/clpt.p: In procedure `GINLE_compute_tangent_stiffness': MATERIAL/clpt.p:2262: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. gpc1: gpc exited with status 1 gpc1: gpc exited with status 1 gpc1: gpc exited with status 1 ~/CHARLES 11 % gpc --version gpc 20030209, based on gcc-3.2.1 Copyright (C) 1987-2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ~/CHARLES 12 % gcc --version gcc (GCC) 3.2.1 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Now http://www.gnu-pascal.de/todo.html does not tell me much... What can I do to help you eleminate the bug (if it is a new one, that is) I am not sure, but I thought I installed a gcc-3.2.1 based gpc at home, which compiled the FE program charles OK. But that is not using the latest gpc source, nor the latest charles source. Regards, Marten Jan

2 1

External variables and constants
by Adriaan van Os 18 Mar '03

18 Mar '03

Is it correct that an external variable can be declared in GPC as follows: var eV: integer; external; asmname 'eV'; Is there a similar construct to declare external constants ('extern const' in C) ? Regards, Adriaan van Os

4 3

Conditional keywords
by Frank Heckenbach 17 Mar '03

17 Mar '03

GPC supports a number of keywords that do not belong to all (or any ;-) known Pascal standards/dialects. To relieve the resulting problems, there are currently 3 mechanisms: - If any dialect option (`--extended-pascal' etc.) is used, all keywords not belonging to this standard are deactivated completely. - Individual keywords can be disabled using `--disable-keyword'. - Some keywords are recognized only depending on context, so compiling a program that uses them as identifiers is still possible without any of the above options. However, the 3rd approach only works in some situations (and can never work perfectly, since at some points there would simply be syntactic ambiguities between certain keywords and identifiers). I think for some words it would be easier to recognize them as keywords only if they have no current meaning (as identifiers) in the program, rather than turning them on and off in certain syntactic places (which is quite error-prone and probably still has some subtle bugs). I'm not sure if this approach will work for all problematic keywords, but at least for some. So this will still work: program Foo; var Foo: static Integer; begin end. Also this: program Foo; procedure Bar; var Static: Integer; begin end; var Foo: static Integer; begin end. But not this (which works now): program Foo; var Static: Integer; Foo: static Integer; begin end. Do you think this would a problem? It should not affect the ability to compile, say, EP code without `--extended-pascal' *as far as* that's possible now, since EP code can't use `static' as a directive (and it can't use as identifiers what are keywords in EP). 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

5 10

Re: gpc with gdb
by Frank Heckenbach 16 Mar '03

16 Mar '03

mkhaldi(a)softaddicts.ca wrote: > I'd like to debug a pascal program. When I run it in gdb, I can't examine > the variables. I can examine my variables before running it in gdb. > > I put yet the compile options to have debug information. > So, what do I do to get the variables' value when I run my program in gdb... > Is it clear? No. Did you actually read my previous mail? I wrote: : PLEASE, try : to give some information with your requests! Like, the Pascal : source, and what you expected to get etc. ... I suggest you read http://www.chiark.greenend.org.uk/~sgtatham/bugs.html and http://www.catb.org/~esr/faqs/smart-questions.html very thoroughly. Before sending a request, read it again and imagine you're someone who doesn't know about your problem and see if you can make sense of your mail. Sorry, but if you can't take the time to write a proper request, don't expect anyone to take the time to help you. I'll ignore such requests in the future. And again, reply to the list, not personally. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

5 7

Download links were temporarily broken
by Frank Heckenbach 16 Mar '03

16 Mar '03

The download links on the GPC web page were broken for some hours, due to a mistake. Everything should be working normal again now. 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

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