Adriaan van Os wrote:
Waldek Hebisch wrote:
Yes, I think we should not mark 4.1 based version as "experimental". There are some regressions compared to gpc based on 3.4.6 but they are minor.
The failure of prep2.pas on Mac OS X can lead to nasty problems in software that depends on the missing defines. So, for Darwin, I am checking in the following diff (although it may be wrong for cross-compilers)
diff -ur gcc-4.1.2-orig/gcc/p/gpcpp.c gcc-4.1.2/gcc/p/gpcpp.c --- gcc-4.1.2-orig/gcc/p/gpcpp.c 2007-09-04 08:22:53.000000000 +0200 +++ gcc-4.1.2/gcc/p/gpcpp.c 2007-09-18 10:36:57.000000000 +0200 @@ -1187,6 +1187,14 @@ strcat (strcpy (tmp_buf, "__GPC_RELEASE__="), GPC_VERSION_STRING); make_definition (tmp_buf, 1);
+#ifdef __APPLE__
- make_definition ("__APPLE__", 1);
+#endif
+#ifdef __MACH__
- make_definition ("__MACH__", 1);
+#endif
- /* Now handle the command line options. */ /* Do -U's and -D's in the order they were seen. */ for (i = 1; i < argc; i++)
Hmm, that solves only tiny part of the problem. Technically, to know about Darwin/PPC builtins gpc needs information provided by darwin_cpp_builtins and rs6000_cpu_cpp_builtins. Proper solution would be to put definitions of both functions in files visible by the front end -- either change them to macros and move to header file (as done by most target files) or maybe put them in some "target independed" file guarded by preprocessor conditions.
Simple practical way is to link offending files into gpc. I tried the patch below some time ago and it seemed to work, but since the patch may potentially break working targets I was not included in the official version.
The part below is copied (via cut&paste) from an e-mail, so it probably has incorrect tabs (and files changed anyway)...
---------------------------------------------------------------------
GPC has the same problem with 3.4.0 for ppc-linux target. We may also try to link in C_TARGET_OBJS. If I define `cpp_define' and add dummy definitions of `c_lex' and `cpp_assert' then gpc1 for ppc-linux seem to work. Unfortunatly linking C_TARGET_OBJS may break some other targets. But ia64 (the only other Debian target for which C_TARGET_OBJS is non-empty) seem to work. However, if we put C_TARGET_OBJS in a library and link it to that library we should be completly safe.
Crude patch below:
--- ../tst25/gpc-20040516/p/Make-lang.in 2004-05-18 20:01:22.000000000 +0200 +++ gpc-20040516/p/Make-lang.in 2004-05-20 20:19:42.000000000 +0200 @@ -587,7 +587,7 @@ p/typecheck.o p/types.o p/convert.o p/dbxout.o p/dwarf2out.o \ p/expr.o p/fold-const.o p/function.o p/integrate.o p/optabs.o \ p/stor-layout.o p/toplev.o p/tree.o p/stmt.o p/emit-rtl.o \ - p/version.o + p/version.o $(C_TARGET_OBJS)
# Exclude patched files from language-independent object file list. # Not necessary for gcc-3 since for a library (libbackend.a), the linker does this automatically. --- ../tst25/gpc-20040516/p/lang.c 2004-05-19 01:12:12.000000000 +0200 +++ gpc-20040516/p/lang.c 2004-05-20 20:40:07.000000000 +0200 @@ -402,6 +402,29 @@ fprintf (stderr, "-D%s -D__%s -D__%s__ ", s, s, s); }
+int +c_lex (t) + tree * t; +{ + return 0; +} + +void +cpp_define (r, s) + void * r; + const char * s; +{ + builtin_define_std (s); +} + +void +cpp_assert (pfile, str) + void *pfile; + const char *str; +{ +} + + #define preprocessing_asm_p() 0 #define preprocessing_trad_p() 0 #define c_language (-1) @@ -554,9 +577,12 @@ /* @@ Backend bug: TARGET_OS_CPP_BUILTINS on some targets uses it though it's a C specific flag. */ #define flag_iso 1 - - TARGET_CPU_CPP_BUILTINS (); - TARGET_OS_CPP_BUILTINS (); + { + extern void rs6000_cpu_cpp_builtins PARAMS ((void *)); + void * pfile = 0; + TARGET_CPU_CPP_BUILTINS (); + TARGET_OS_CPP_BUILTINS (); + } #endif /* The following is no joke! The difference between what the preprocessor and the compiler think of BYTES_BIG_ENDIAN is