- Gpc - gnu.de

Gcc-3.4 & gpc
by David Kredba 08 Jul '04

08 Jul '04

Hello. I am trying to get gcc-3.4 working with gpc. I use gcc-3.4-20040702 and gpc-20040516. I ran : dave2@srv1 p $ patch -p2 < ../../update27h.diff cd ../../gcc-3.4-20040702 dave2@srv1 gcc-3.4-20040702 $ patch -p1 < ../gcc-3.4.diff8 I got one reject : patching file gcc/expr.c Hunk #2 succeeded at 5081 (offset 1 line). Hunk #3 succeeded at 5118 (offset 1 line). Hunk #4 succeeded at 5133 (offset 1 line). Hunk #5 FAILED at 5148. Hunk #6 succeeded at 5202 (offset 1 line). Hunk #7 succeeded at 5584 (offset 1 line). 1 out of 7 hunks FAILED -- saving rejects to file gcc/expr.c.rej cd .. mkdir gcc-3.4 cd gcc-3.4 ../gcc-3.4-20040702/configure --prefix=/opt/gcc-3.4 --enable-shared --enable-threads=posix --enable-checking --enable-long-long --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++,ada,f77,objc,java,pascal --with-system-zlib make bootstrap && make -k -C gcc gnatlib_and_tools && make -k check <snip> gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-3.4-20040702/gcc -I../../gcc-3.4-20040702/gcc/. -I../../gcc-3.4-20040702/gcc/../include ../../gcc-3.4-20040702/gcc/c-common.c -o c-common.o ../../gcc-3.4-20040702/gcc/p/mk_lang_opt < ../../gcc-3.4-20040702/gcc/p/opts.sum > "../../gcc-3.4-20040702/gcc/p/lang.opt" /bin/sh: line 1: ../../gcc-3.4-20040702/gcc/p/mk_lang_opt: Přístup odmítnut make[2]: *** [../../gcc-3.4-20040702/gcc/p/lang.opt] Error 126 make[2]: Leaving directory `/home/dave2/gcc/gcc-3.4/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/home/dave2/gcc/gcc-3.4/gcc' make: *** [bootstrap] Error 2 There is lang.opt file with 0 Byte size in gcc-3.4-20040702/gcc/p folder. Mk_lang_opt has no executable flag. I ran tar xzf to unpack gpc archive an diffs to gpc and gcc. If I set executable flag to mk_lang_opt file, build process continues. I had never unpack gpc tarball with p option, like tar xzpf gpc-20040516.tar.gz and build process always works fine. I can see that mk_lang_opt comes from update27h.diff, so tar xzpf to gpc tarball is not needed. I don`t now if patch can set executable flag to mk_lang_opt file but I think that not. Is executable flag really on mk_lang_opt file needed to bootstrap compiler or I am doing some error ? Thanks very much, David -- David Kredba <kredba at ibot.cas.cz> GPG: ID 1024D/5B6B02DE Fingerprint: F0B3312596BEDCF91DFB 0699E06AACD75B6B02DE

1 0

gpc+gcc-3.4.1
by Russell Whitaker 07 Jul '04

07 Jul '04

Hi gcc-3.4.1 was released July 1. Should I try building gpc with it at this time? Thanks, Russ

2 1

Re: problem with writeln (or program
by Mingeborg＠aol.com 02 Jul '04

02 Jul '04

How embarrassing - -O -W -Wall indeed found the problem with the program. Thank you very much! - Inga In a message dated 7/1/2004 10:13:57 PM Eastern Daylight Time, Frank Heckenbach <ih8mj(a)fjf.gnu.de> writes: >What do you mean with register values? Assembler level registers? Of >course, almost every operation changes them. Pascal variables? If >they have a defined value, an operation without side-effects on them >shouldn't change them, of course. (Otherwise it's in fact a compiler >bug.) > >*However*, if the variables are undefined, any operation can change >their accidental values. That's what undefined means. > >So I'd first look for this in your code. Did you compile with all >warnings on, for a start? Please note that GPC doesn't find some >such cases unless you compile with optimization. So `-O -W -Wall' >would be a good start. > >Frank

1 0

problem with writeln (or program bug?)
by Mingeborg＠aol.com 02 Jul '04

02 Jul '04

Enclosed is a gzipped tar file containing program ind.p (298 lines.) As is, the program goes into infinite recursion, but it works correctly if you comment out a âwritelnâ statement on line 248, (the statement before ***************...) (gpc-20040516, Linux running on a Pentium 4 laptop.) I apologize for the size of the example, but I have been unable to reproduce the problem with a smaller example, and I don't understand what is happening. The following are lines 238 â 249 of the program. ... function rcrsv_ind_st2(var g:relation; s:subset): subset; {this one is not debugged yet. gives different result than rcrs2 for the third fullerene} var i,k,l,k1,k2 :integer; nb,ind1,ind2 :subset; iterations :integer=0; attribute (static); begin {writeln('top:'); diagnose_subset(s); stop_n_go;} iterations := iterations+1; writeln('iteration number:',iterations); {************ comment this out, and it works ********} if not there_are_edges_in(s,g) ... This particular code works correctly on DIGITAL Pascal, (after changing the syntax for the static variable declaration,) but âwritelnâ statements in âwrongâ (but different) places have the same effect there, also. The program is hardwired to compute the largest independent set of a path with 2 vertices, and the output should be: iteration number: 1 iteration number: 2 cardinality 1 0: 0 Is it possible that, under certain circumstances, âwritelnâ permanently changes register values, or some such? Or, is this necessarily a bug in the program? I have not figured out how to use the debugger on this â I'm getting: Die: DW_TAG_set_type (abbrev = 3, offset = 431) has children: FALSE attributes: DW_AT_type (DW_FORM_ref4) constant: 53 Dwarf Error: Cannot find type of die [in module ... I would appreciate any suggestions regarding what might be happening or how to debug it. Thanks, - Inga

2 1

Re: GPC on AMD Opteron?
by Mingeborg＠aol.com 26 Jun '04

26 Jun '04

Thanks for the help! - Inga In a message dated 6/26/2004 2:33:39 AM Eastern Daylight Time, chiefsoft(a)bigfoot.com writes: > > On 25 Jun 2004 at 19:06, Mingeborg(a)aol.com wrote: > > > Does GPC compile on AMD Opteron processors (64 bit, GNU/Linux)? > > > > I saw in the archives that it's been done for Athlon processors, > > presumably that means, "yes"? Are there any caveats? > > I easily built a version for Fedora Core 2 for AMD64. There > is nothing > to it. No caveats whatsoever. The binaries are here: > http://gnu-pascal.de/contrib/chief/fedora-2/ > > Best regards, The Chief > -------- > Prof. Abimbola A. Olowofoyeku (The African Chief) > web: http://www.greatchief.plus.com/ > > > > >

1 0

GPC on AMD Opteron?
by Mingeborg＠aol.com 26 Jun '04

26 Jun '04

Does GPC compile on AMD Opteron processors (64 bit, GNU/Linux)? I saw in the archives that it's been done for Athlon processors, presumably that means, "yes"? Are there any caveats? Thanks, - Inga

2 1

Re: GPC on AMD Opteron?
by Mingeborg＠aol.com 26 Jun '04

26 Jun '04

Thanks a lot, - Inga In a message dated 6/25/2004 7:15:41 PM Eastern Daylight Time, georges(a)its.caltech.edu writes: > > I assume you mean native AMD64? > > Yes it does (I recently repackaged a new wersion for Gentoo and tested it on > amd64). There doesn't seem to be anything special, just follow the > instructions. You can also take a look at the ebuild, > http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-lang/gpc/gpc-20040516.ebuild > which essentially contains all the steps to build and install it.. > > George > > On Friday 25 June 2004 16:06, you wrote: > > Does GPC compile on AMD Opteron processors (64 bit, GNU/Linux)? > > > > I saw in the archives that it's been done for Athlon > processors, presumably > > that means, "yes"? Are there any caveats? > > > > Thanks, > > - Inga > > > >

1 0

recursion problem
by Mingeborg＠aol.com 24 Jun '04

24 Jun '04

I am getting a recursion problem I don't understand. (gpc-20040516, LINUX on a Pentium 4 laptop.) This is a (silly) example program (enclosed as a gzipped tar file.): program subset_problem(input,output); const setlimit = 4; type subset = set of 0..255; var seta, setb: subset; function recursive_setprint(set1: subset):subset; var i : integer; found : boolean; returned : boolean; begin if set1 <> [] then begin i:= 0; found := false; while ((i <= setlimit) and (not found)) do begin if i in set1 then begin writeln('first element: ',i); found := true; recursive_setprint := recursive_setprint(set1 - [i]); end; i := i + 1; end end end; begin seta := [0..setlimit]; setb := recursive_setprint(seta); end. I'm getting the following output: first element: 0 first element: 1 first element: 2 first element: 3 first element: 4 first element: 4 first element: 3 first element: 4 first element: 4 first element: 2 first element: 3 first element: 4 first element: 4 first element: 3 first element: 4 first element: 4 first element: 1 first element: 2 first element: 3 first element: 4 first element: 4 first element: 3 first element: 4 first element: 4 first element: 2 first element: 3 first element: 4 first element: 4 first element: 3 ... and so on. I'm expecting: first element: 0 first element: 1 first element: 2 first element: 3 first element: 4 (This is the output I am getting with Digital Pascal.) Thanks for your help with this.

4 4

Re: recursion problem
by Mingeborg＠aol.com 23 Jun '04

23 Jun '04

Yes, it works. (That was an incredible turnaround time.) Thank you very much! - Inga In a message dated 6/22/2004 7:34:08 PM Eastern Daylight Time, ih8mj(a)fjf.gnu.de writes: > Thanks for the report. The attached patch will fix it. (inga1*.pas) > > 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

Re: recursion problem
by Mingeborg＠aol.com 23 Jun '04

23 Jun '04

Thanks for verifying this so quickly! - Inga In a message dated 6/22/2004 5:35:05 PM Eastern Daylight Time, chiefsoft(a)bigfoot.com writes: > > On 22 Jun 2004 at 16:45, Mingeborg(a)aol.com wrote: > > > I am getting a recursion problem I don't understand. (gpc-20040516, > > LINUX on a Pentium 4 laptop.) > > > > This is a (silly) example program (enclosed as a gzipped tar file.): > > > > program subset_problem(input,output); > > const setlimit = 4; > > type > > subset = set of 0..255; > > > > var > > seta, setb: subset; > > > > function recursive_setprint(set1: subset):subset; > [...] > > I'm expecting: > > first element: 0 > > first element: 1 > > first element: 2 > > first element: 3 > > first element: 4 > > (This is the output I am getting with Digital Pascal.) > > The output is the same with Virtual Pascal, Delphi, and > FreePascal - so > something is up with the GPC output. > > Best regards, The Chief > -------- > Prof. Abimbola A. Olowofoyeku (The African Chief) > web: http://www.greatchief.plus.com/ > > > > >

1 0