January 2003 - Gpc

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

Building gpc on Mac OS X.2
by Adriaan van Os 12 Jan '03

12 Jan '03

I have found a much simpler way to build gpc (with gcc-3.2.1) on Mac OS X, than what I did before. A summary is given below. I will put full instructions, together with binaries, on my website, somewhere next week (I hope). Regards, Adriaan van Os --------- The following has been tested on Mac OS X.2.3 out-of-the-box. It might also work on Mac OS X.2 or X.2.2 (but I didn't test). (1) Get the gpc-20021128 and gcc-core-3.2.1 sources (2) Remove the space after "-D" in p/Make-lang.in (Frank Heckenbach) $(CC) -o $@ -c $(ALL_GPC_FLAGS) -DRTS_VERSION_CHECK="\"__GPC_RTS_VERSION_`cat $(RTSSRCDIR)/rts-version`__\"" $< (3) Patch p/parse.y (Frank Heckenbach) Try this (patch may need manual applying, since I've changed some other things in my copy meanwhile). *** p/parse.y.orig Fri Jan 3 09:44:04 2003 --- p/parse.y Fri Jan 3 09:49:25 2003 *************** *** 792,799 **** tree name = get_module_destructor_name (current_module); const char *save_filename = start_dummy_file_name (); context = build_nt (CALL_EXPR, name, no_parameters (), NULL_TREE); ! if (!start_function (chainon (build_tree_list (NULL_TREE, static_id), ! build_tree_list (NULL_TREE, void_type_node)), context, NULL_TREE, 0)) YYERROR1; store_parm_decls (); --- 792,798 ---- tree name = get_module_destructor_name (current_module); const char *save_filename = start_dummy_file_name (); context = build_nt (CALL_EXPR, name, no_parameters (), NULL_TREE); ! if (!start_function (build_tree_list (NULL_TREE, void_type_node), context, NULL_TREE, 0)) YYERROR1; store_parm_decls (); (4) Patch stddef.h (Andreas Tobler). The patch can be found at http://gcc.gnu.org/ml/gcc/2002-08/msg01681.html. --- gcc-04072002/gcc/ginclude/stddef.h Wed Jan 9 13:28:06 2002 +++ gccsrc/gcc/gcc/ginclude/stddef.h Thu Jul 4 18:37:27 2002 @@ -242,6 +242,7 @@ #ifndef _WCHAR_T_ #ifndef _BSD_WCHAR_T_ #ifndef _BSD_WCHAR_T_DEFINED_ /* Darwin */ +#ifndef _BSD_RUNE_T_DEFINED_ /* Darwin */ #ifndef _WCHAR_T_DEFINED_ #ifndef _WCHAR_T_DEFINED #ifndef _WCHAR_T_H @@ -278,6 +279,7 @@ #ifdef _BSD_RUNE_T_ #if !defined (_ANSI_SOURCE) && !defined (_POSIX_SOURCE) typedef _BSD_RUNE_T_ rune_t; +#define _BSD_RUNE_T_DEFINED_ #define _BSD_WCHAR_T_DEFINED_ #if defined (__FreeBSD__) /* Why is this file so hard to maintain properly? In constrast to @@ -295,6 +297,7 @@ #endif #ifndef __cplusplus typedef __WCHAR_TYPE__ wchar_t; +#endif #endif #endif #endif (5) Create a build directory and run configure with the right options (as described in the gpc docs) (6) Now, type "make bootstrap" instead of "make". This will build a gcc-3.2.1 and a gpc-3.2.1 compiler. The first stage of the bootstrap uses the gcc compiler that came with Mac OS X.2.3.

1 0

Dropping gcc-3.1.1
by Frank Heckenbach 11 Jan '03

11 Jan '03

As I wrote some weeks ago, I'd like to drop the gcc-3.1.1 support since 3.2.1 seems to work at least as well (and much better on some systems). Dropping gcc-3.1.1 currently just means removing the diff file, but it makes it easier to maintain whenever there are changes in the diff (and I suppose there'll be some when the debug info problems will be fixed). So, that's your last chance to raise any objections. 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 6