Adriaan van Os wrote:

Waldek Hebisch wrote:

...

I have put a new gpc snapshot at:

http://www.math.uni.wroc.pl/~hebisch/gpc-20060325.tar.bz2

The correct URL seems to be

<http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20060325.tar.bz2>

Yes, thanks for correction. -- Waldek Hebisch hebisch@math.uni.wroc.pl

Adriaan van Os wrote:

The asmnames.pas failure is new. It doesn't fail with the gpc-20060215. Neither does it fail with gpc-20060325 at -O1. At -O3 or -O2 the output of the generated progam is empty. I can provide more info as needed.

Will take deeper look at asmnames.pas failure on Monday. ATM I would like to know if asmnames.pas fails also in non-pic mode? -- Waldek Hebisch hebisch@math.uni.wroc.pl

Adriaan van Os wrote:

Waldek Hebisch wrote:

...

Adriaan van Os wrote:

...

The asmnames.pas failure is new. It doesn't fail with the gpc-20060215. Neither does it fail with gpc-20060325 at -O1. At -O3 or -O2 the output of the generated progam is empty. I can provide more info as needed.

Will take deeper look at asmnames.pas failure on Monday. ATM I would like to know if asmnames.pas fails also in non-pic mode?

Yes, that's what I already tried, it fails with -mdynamic-no-pic.

I still do not know what is wrong with asmnames.pas. I have tried to reproduce problem in ppc-linux, but in Linux asmnames.pas generated correct output. I am affraid it is time to do assembly level debugging. Could you set breakpoint in `puts' and look at its argument. The argument should be address of S plus 8, and it should point to the string "OK". The first question is if `puts' gets correct address (alternativly, the content of S my be incorrect). If the content of S is incorrect then one may step trough the program to verify why. AFAICS generated assembly contains `memcpy' call and after that call data part of S should contain the string "OK". Next the length field (at address S plus 4) should be set to 2. Then there is a code to null terminate S (but only in conditionally, if it is not already null terminated). Then `puts' is called. At first glance the assembly contains all needed instructions, but computers are much better then people at executing programs, so one should just single-step the program verifing values stored in S at each step. BTW. One gets simplest assembly using `-static -fno-range-checking'. -- Waldek Hebisch hebisch@math.uni.wroc.pl

Adriaan van Os wrote:

...

Waldek Hebisch wrote:

...

I have put a new gpc snapshot at:

http://www.math.uni.wroc.pl/~hebisch/gpc-20060325.tar.bz2

Next, I will try with gcc-4.

The compiler does build on powerpc-apple-darwin8 with gcc-4.0.3 (I bootstrapped an FSF-gcc-4.0.3 C compiler first). Next I tried the testsuite.

rm -f *.dat *.o *.s *.i *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.i todo/*.gpi todo/*.gpd todo/core GP= PC="gpc403d1" PFLAGS=" --autobuild -g -O3 -W -Wall -Wno-unused " PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | tee test_log | "./test_sum" -d Test Run By adriaan on 2006-03-25 18:00:51 Native configuration is powerpc-apple-darwin8 (g5.local)

=== gpc tests ===

Running target any Running testsuite ...

UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas UNSUPPORTED: asmtest.pas FAIL: aturbo3test.pas gpc403d1: Internal error: Cputime limit exceeded (program gpc1) Please submit a full bug report. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. gpc1: gpc403d1 exited with status 1 gpc1: gpc403d1 exited with status 1 failed

Looks like the compiler hangs in an endless loop. I took a sample with the Mac OS X activity monitor.

Analysis of sampling pid 2816 every 10.000000 milliseconds Call graph: 289 Thread_100f 289 start 289 _start 289 toplev_main 289 yyparse 289 cgraph_optimize 289 cgraph_expand_function 289 tree_rest_of_compilation 289 execute_pass_list 289 rest_of_compilation 289 dbxout_function_decl 289 dbxout_block 289 dbxout_block 289 dbxout_syms 289 dbxout_symbol 289 dbxout_symbol

Total number in stack (recursive counted multiple, when >=5):

Sort by top of stack, same collapsed (when >= 5): dbxout_symbol 289 Sample analysis of process 2816 written to file /dev/stdout Sampling process 2816 each 10 msecs 300 times

The same happened with another test program (but I didn't come very far yet). Adding -O2, -O1 or -O0 doesn't help. Same for -mdynamic-no- pic and --no-pic.

Looks like problem with debug info. BTW: if the same happens with standalone program (without modules) I should be able to reproduce it. -- Waldek Hebisch hebisch@math.uni.wroc.pl

Adriaan van Os wrote:

FAIL: fjf1062a.pas /var/tmp//ccpndmuf.s:71:non-relocatable subtraction expression, "L2" minus "L00000000001$pb" /var/tmp//ccpndmuf.s:71:symbol: "L2" can't be undefined in a subtraction expression /var/tmp//ccpndmuf.s:69:non-relocatable subtraction expression, "L2" minus "L00000000001$pb" /var/tmp//ccpndmuf.s:69:symbol: "L2" can't be undefined in a subtraction expression /var/tmp//ccpndmuf.s:unknown:Undefined local symbol L2 failed

Looks like backend regression to me. AFAICS the following C program has the same problem: void Object (void) { void * jmpbuf_1[6]; void P (void) { { void * jmpbuf_3[6]; if (__builtin_setjmp (&jmpbuf_3)) goto nonlocal_exit_2; else (void) 0;; __builtin_longjmp (&jmpbuf_1, 1); nonlocal_exit_2:;; } } { if (__builtin_setjmp (&jmpbuf_1)) goto nonlocal_exit_0; else (void) 0;; P (); nonlocal_exit_0:;; } } int main(void) { Object (); } -- Waldek Hebisch hebisch@math.uni.wroc.pl

Waldek Hebisch wrote:

Adriaan van Os wrote:

...

Thanks, this fixes the problem. New testsuite results on powerpc- apple-darwin8 (with -gdwarf-2) are given below.

AFAICS most new failures are related to `-flongjmp-all-nonlocal-labels' option which is on by default for Mac OSX. With this option fjf1062a.pas, fjf1062b.pas, fjf1062c.pas, nmaze.pas, permute.pas, peter5c.pas, peter5f.pas also fail on AMD64 (all of them passes without `-flongjmp-all-nonlocal-labels').

Right, these tests all pass on Mac OS X with --no-longjmp-all-nonlocal-labels. With that option, I can now build and debug a typical Mac OS X GUI app (from the GPC Xcode Kit) with the gcc-4 based compiler and -gdwarf-2. My first impression is that debugging (with Xcode as front-end) has quite improved as compared to -gstabs (apart from the line-number problem). I will try to patch the installed system gdb with your gdb dwarf patches and then report the result.

In particular fjf1062[abc].pas looks like a generic backend bug. I reported it as: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26983

Thanks. We will see if it gets fixed -- I am glad it's reproducable with Linux and AMD also (...). Regards, Adriaan van Os

Russell Whitaker wrote:

hi

The following compiles but no longer works:

program fill; var s: string(10); begin fillchar(s[1], s.capacity, ' '); writeln("ok"); end.

Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6/specs Configured with: ../gcc-3.4.6/configure --enable-languages=c,c++,pascal --enable-shared --enable-threads-posix --enable-__cxa_atexit Thread model: posix gpc version 20060215, based on gcc-3.4.6

Russ

Do you get a message about out of range value? If yes then strictly speaking the compiler is right: s is uninitialized, so its length is set to 0, hence access to s[1] is illegal (out of range). In fact, I see another problem with the code above: s[1] is a single char, but fillchar acceses also s[2],... which strictly speaking is another out of bound access (but ATM compiler can not detect this problem). I would say that fillchar is incompatible with range checking (at least now). ATM you can say: setlength(s, 10); fillchar(s[1], s.capacity, ' '); and I will work. However, I think that the correct way is: setlength(s, s.capacity); fillchar(s[1..length(s)], length(s), ' '); Alternatively, you char turn range checking off. In the future we may teach the compiler that fillchar is special, so it applies to it relaxed range checking rules, but that would require non-trivial changes in the compiler. -- Waldek Hebisch hebisch@math.uni.wroc.pl

Russell Whitaker wrote:

...

and I will work. However, I think that the correct way is:

setlength(s, s.capacity); fillchar(s[1..length(s)], length(s), ' ');

shouldn't that be fillchar(s[1], length(s), ' '); ?

That was the first alternative Waldek gave (WRT the 1st parameter). It's formally a bit cleaner, though currently (and as I wrote, I don't plan to change it), the second alternative works as well and does the same.

...

In the future we may teach the compiler that fillchar is special, so it applies to it relaxed range checking rules, but that would require non-trivial changes in the compiler.

perhaps something like: if ( start+count ) GT s.capacity then out-of-range-error if ( start+count ) GT length(s) then setlength( s, start+count)

You mean for FillChar? Well, FillChar is independent of SetLength. In fact, it's a low-level routine that doesn't know about strings at all and can be applied to any kind of data.

Also, if the fillchar line is written as fillchar( s, count, Afillchar ); it should default to fillchar( s[1], count, Afillchar );

No, it shouldn't. Again, FillChar is low-level, and FillChar (s, ...) will just fill the memory starting at s. That's usually pointless and dangerous, just as many other applications of FillChar are (such as applying it to file types or records containing various types, ...).

current behavior fillchar( s, ... overwrites length (and capacity?) fields.

Yes, that's what it's supposed to do. Therefore, such low-level routines should be used with great caution. BTW, a cleaner way (though involving a runtime function call) to achieve the same is: uses GPC; [...] s := StringOfChar (' ', s.Capacity); Perhaps you were really looking for something like this from the start. Frank -- Frank Heckenbach, frank@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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

Frank Heckenbach wrote:

Waldek Hebisch wrote:

...

Russell Whitaker wrote:

...

The following compiles but no longer works:

program fill; var s: string(10); begin fillchar(s[1], s.capacity, ' '); writeln("ok"); end.

Do you get a message about out of range value? If yes then strictly speaking the compiler is right: s is uninitialized, so its length is set to 0, hence access to s[1] is illegal (out of range).

Yes.

...

In fact, I see another problem with the code above: s[1] is a single char, but fillchar acceses also s[2],... which strictly speaking is another out of bound access (but ATM compiler can not detect this problem).

Well, FillChar is low-level, working on memory directly.

Low-level does not exclude error checking. The following: var c : char ... fillchar(c, 2, ' '); is wrong. It make sense to flag such things, as long as there is a way to write the correct cases. More precisely, IMHO it is acceptable to recect some versions as long as there is an acceptable alternative.

...

I would say that fillchar is incompatible with range checking (at least now). ATM you can say:

setlength(s, 10); fillchar(s[1], s.capacity, ' ');

Yes, that's what I did in the few cases like that I had.

...

and I will work. However, I think that the correct way is: setlength(s, s.capacity); fillchar(s[1..length(s)], length(s), ' ');

Alternatively, you char turn range checking off.

In the future we may teach the compiler that fillchar is special, so it applies to it relaxed range checking rules, but that would require non-trivial changes in the compiler.

To some extend the compiler already knows this, that's why the first way works. I.e., it cares only about the address of the first argument (and thus only about its validity), not about the length of the memory block. Actually, that's nothing magic -- an untyped `var' parameter has the same effect. Since it's possible to write user-level routines using untyped parameters that work on memory blocks of any size, the compiler can't check them in general.

So I'd rather leave things as they are -- OTOH, making checking stricter (to the whole block) wouldn't be possible with user-level routines, OTOH, making it looser (WRT s[1]) would seem to cost quite some effort for little gain (as it's often easy to avoid the problem by reordering as here, or at worst, turn off range-checking locally).

In ideal world fillchar (and argument proccesing in the compiler) would ignore string length. Namely, when doing low-level string manipulation it is safer to fill data first and set length only _after_ the data is correct (gives at least partial protection against using partially filled string). OTOH in the ideal world fillchar would check that the block is big enough. I am not sure if the effect would justify the effort, but in principle transfering: filchar(x, l, c); into something like if sizeof(x) >= l then filchar_lowlevel(x, l, c) else RangeCheckError; does not look very hard. Of course, for really low-level use we should add something like: fillchar(Void(x), n, c); to bypass the length check. -- Waldek Hebisch hebisch@math.uni.wroc.pl

Adriaan van Os wrote:

Waldek Hebisch wrote:

...

BTW: if the same happens with standalone program (without modules) I should be able to reproduce it.

Sorry, not clear to me what you mean.

I have build a cross-compiler targetting Mac OSX. However, I do not have the complete toolchain (only bare compiler). Without full toolchain I can not compile RTS (the problem really is configure) and also I can not compile anything using GPC module. If you have a testcase which does not use GPC module (directy or indirectly) I should be able to compile it. In fact, if a program uses no extra modules (units) at all debugging becomes easier. I have tried the cross-compiler on various test programs and ATM it happily produced stabs debug info. I have noticed a problem, namely on `emil3.pas' at -O0 I get ice: ../gpc-4-osx/gcc/xgpc -B../gpc-4-osx/gcc -static -S emil3.pas main program emil3.pas: In main program: emil3.pas:12: error: unrecognizable insn: (insn 28 27 29 1 (set (reg:DF 142 [ D.587 ]) (subreg:DF (mem/i:DC (lo_sum:SI (reg/f:SI 155) (symbol_ref:SI ("C") [flags 0x182] <var_decl 0x2a9594cdd0 C>)) [0 C+0 S16 A64]) 0)) -1 (nil) (expr_list:REG_DEAD (reg/f:SI 155) (nil))) emil3.pas:12: internal compiler error: in extract_insn, at recog.c:2020 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. This ICE goes away with -fPIC or -mdynamic-no-pic (also any optimization option or -m64 helps). I see this ICE both with 4.0 and 3.4.6 backend. -- Waldek Hebisch hebisch@math.uni.wroc.pl

Frank Heckenbach wrote:

Waldek Hebisch wrote:

...

I have build a cross-compiler targetting Mac OSX. However, I do not have the complete toolchain (only bare compiler). Without full toolchain I can not compile RTS (the problem really is configure) and also I can not compile anything using GPC module.

BTW, if Adriaan sends you his <build>/gcc/p/rts/config.cache file, configure might be able to use the cached data and let you build. I once did test compiles this way for a system I had no complete toolchain for (though with earlier gcc versions, but the RTS configure/build should be relatively independent of gcc versions).

I will be pleased to send the config.cache file or anything else needed. As far as I know, the odcctools toolchain <http://www.opendarwin.org/projects/odcctools/> can be built cross to Darwin on Linux.

You'll need system headers as well, though (and libraries if you want to link, of course), and I don't know if Mac OSX's are freely distributable.

Yes, Darwin <http://opendarwin.org/>, the Mac OS X kernel <http://darwinsource.opendarwin.org/>, is licensed under the Apple Open Source License version 2.0 <http://www.opensource.apple.com/apsl/>, which qualifies as both a free <http://www.gnu.org/philosophy/apsl.html> and open <http://www.opensource.org/licenses/apsl-2.0.php> license. The Mac OS X (non-Darwin) GUI libraries are not free but the GPC testsuite doesn't use them (and even if they were needed, I could send stub libraries). Regards, Adriaan van Os

Waldek Hebisch wrote:

...

Looks like problem with debug info.

indeed, I can run the testsuite with -g0

Same results when passing -gdwarf-2, which is a new option for Darwin with gcc-4 (note that it may be needed to install cctools-590.36, binaries are at <http://www.microbizz.nl/cctools-590.36.dmg> and sources at <http://www.microbizz.nl/cctools-590.36.tar.bz2>). Regards, Adriaan van Os

Mirsad Todorovac wrote:

Adriaan van Os wrote:

...

...

Waldek Hebisch wrote:

...

I have put a new gpc snapshot at: http://www.math.uni.wroc.pl/~hebisch/gpc-20060325.tar.bz2 Next, I will try with gcc-4.

The compiler does build on powerpc-apple-darwin8 with gcc-4.0.3 (I bootstrapped an FSF-gcc-4.0.3 C compiler first). Next I tried the testsuite.

I suppose this means you are running Tiger. What could I do to build on old machines with Panther or Jaguar?

I haven't tried gpc-20060325 with gcc-4 on Mac OS X 10.3. I guess it is possible, because I do have a FSF gcc 4.0 C compiler running on Mac OS X 10.3.9. However, for important new features like creating 64-bit applications, you would need Mac OS X 10.4 anyway, so there is no point in moving to gcc-4 on Mac OS X 10.3, as gcc-3.4.x is more stable at this point. Since I sold my old G4, I can not run and test Mac OS X 10.2 anymore (I now have a G5 with 10.3.9 and 10.4). For building details, have a look at the scripts that come with the source code at my website (the build process for the 32-bit compilers hasn't changed).

Do you recommend odcctools?

odcctools is a great project, especially for creating cross-compilers targeting Mac OS X. It should be possible to use both Apple cctools and Open Darwin odcctools. Regards, Adriaan van Os

Mirsad Todorovac wrote:

Adriaan van Os wrote:

...

...

I suppose this means you are running Tiger. What could I do to build on old machines with Panther or Jaguar?

I haven't tried gpc-20060325 with gcc-4 on Mac OS X 10.3. I guess it is possible, because I do have a FSF gcc 4.0 C compiler running on Mac OS X 10.3.9. However, for important new features like creating 64-bit applications, you would need Mac OS X 10.4 anyway, so there is no point in moving to gcc-4 on Mac OS X 10.3, as gcc-3.4.x is more stable at this point.

I have built gcc-4.2 (experimental) on 10.3.9 and it has built OK. Perhaps this was too much of a bravery, but I was chasing those new optimizations for G5 machines. In fact, which -march and -mtune parameters do you recommend for speed-demanding builds? (Of course, while compiling the compiler itself, I am more conservative ...)

-mtune=G5, -mcpu=G5, -O3 <http://gcc.gnu.org/onlinedocs/gcc-4.0.3/gcc/RS_002f6000-and-PowerPC- Options.html> However, generating 64-bit instructions (which is something different than generating a 64-bit application) is not fully reliable yet (but you can experiment with it, maybe rebuild libgpc.a). Possibly also --fast-math <http://gcc.gnu.org/onlinedocs/gcc-4.0.3/gcc/Optimize-Options.html> (for non-IEEE calculations). You can also have a look at <http://developer.apple.com/performance/accelerateframework.html>.

...

Since I sold my old G4, I can not run and test Mac OS X 10.2 anymore (I now have a G5 with 10.3.9 and 10.4).

I still have a G4 running in the lab with 10.2.8. I wonder if this platform is considered obsoleted now? Sadly, even 10.3.9 is not updated in development tools, and I don't think our institution will provide for 10.4.2 ...

Apple policies, sadly. Regards, Adriaan van Os

Russell Whitaker wrote:

On Sat, 25 Mar 2006, Waldek Hebisch wrote:

...

I have put a new gpc snapshot at:

http://www.math.uni.wroc.pl/~hebisch/gpc-20060325.tar.bz2

Main change is preliminary gcc-4.0.x support. [..]

Results here:

<snip>

=== gpc tests ===

Running target any Running testsuite ...

UNSUPPORTED: aregextest.pas FAIL: fjf186.pas FAIL: fjf322.pas FAIL: fjf403b.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: goto8.pas FAIL: nicola4c.pas

Thanks for the report. fjf186.pas is somewhat nasty, I thought that I fixed it, but it is still present. The other were "expected" (those are either problems with warnings or compiler accepting wrong programs). -- Waldek Hebisch hebisch@math.uni.wroc.pl

Hi Frank, thanks for your quick reply - and sorry for being late at my end, I got distracted by non-computer things. On Fri, May 19, 2006 at 03:45:06PM +0200, Frank Heckenbach wrote:

...

I just tried it on AIX 5.3, with gcc-3.4.6, and the result is sort of "mixed":

There is one line that needs to be changed in gcc/p/test/test_run, because otherwise I'll get an error from the shell (in make check):

old:

echo "$PC `$PC $PFLAGS -dumpversion`, flags: $PFLAGS_NO_PATHS `if [ echo "$PC `$PC $PFLAGS -dumpversion`, flags: $PFLAGS_NO_PATHS `if [ x"$GP" != x ]; then echo "(using GP)"; fi`"

new:

echo "$PC `$PC $PFLAGS -dumpversion`, flags: $PFLAGS_NO_PATHS `if [ echo "$PC `$PC $PFLAGS -dumpversion`, flags: $PFLAGS_NO_PATHS `if [ x"$GP" != x ]; then echo \"(using GP)\"; fi`"

What's that? The original line is:

echo "$PC `$PC $PFLAGS -dumpversion`, flags: $PFLAGS_NO_PATHS `if [ x"$GP" != x ]; then echo "(using GP)"; fi`"

Perhaps you unintentionally duplicated a part of it (from the beginning to the first "[")?

Yes. I'm not sure how that happened, but that's what you get when using the mouse for "insert lines of code into mail". The (changed) line indeed looks like this: echo "$PC `$PC $PFLAGS -dumpversion`, flags: $PFLAGS_NO_PATHS `if [ x"$GP" != x ]; then echo \"(using GP)\"; fi`"

So I assume it should be changed to:

echo "$PC `$PC $PFLAGS -dumpversion`, flags: $PFLAGS_NO_PATHS `if [ x"$GP" != x ]; then echo \"(using GP)\"; fi`"

Yes.

...

(the change is that "(using GP)" needs extra quotes, otherwise the shell will complain - this is with AIX' ksh, but as far as I know, recent bash versions will be similarily picky)

Not AFAICS:

# bash --version GNU bash, version 3.1.0(1)-release (i686-pc-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. # echo "`echo "foo"`" foo

Interesting. Even more interesting is that the abovementioned "echo" command runs under AIX's ksh and /bin/sh just fine - but that's to be expected, the quotes just disappear, and then all you have left is echo foo which works :) Things look different if you do this: gd@hilb31:/s1/gcc-3.4.6/gcc/p/test> echo "`echo "(foo)"`" ksh: 0403-057 Syntax error: `(' is not expected. gd@hilb31:/s1/gcc-3.4.6/gcc/p/test> echo "`echo \"(foo)\"`" (foo) - but you're right, bash doesn't care one way or the other.

I think it's not so much about being picky, but supporting a slightly extended syntax ("" within `` pairs, while ksh apparently considers the first unquoted " to be the closing one without regard to nesting). But anyway, the extra \'s don't hurt bash (and I hope no other shell either).

Unfortunately it's not so easy. NetBSD's ksh does it just the other way: gert@kirk:/rhome/gert$ echo "`echo \"(foo)\"`" /bin/ksh: syntax error: `(' unexpected gert@kirk:/rhome/gert$ echo "`echo "(foo)"`" (foo) *argh* so maybe portable code really should avoid using the same quote character on different levels. Which means, the "right" thing to do would be: echo "$PC `$PC $PFLAGS -dumpversion`, flags: $PFLAGS_NO_PATHS `if [ x"$GP" != x ]; then echo '(using GP)'; fi`" - which seems to be fully portable to all shells I have tried.

...

After that, the test suite starts, but *all* test programs fail:

"gmake pascal.check-long" explains what is going wrong:

Test Run By gd on 2006-05-19 13:43:03 Native configuration is powerpc-ibm-aix5.3.0.0 (hilb31) /s1/gpc-build-20060325-3.4.6/gcc/xgpc -B/s1/gpc-build-20060325-3.4.6/gcc/ 20060325, based on gcc-3.4.6, flags: -g -O3 -W -Wall -Wno-unused GPC-TEST-BEGIN ========================== TEST abso1.pas: cc1: warning: command line option "-funit-path=/gnulocal/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6/units" is valid for Pascal but not for C cc1: warning: command line option "-fno-unit-path" is valid for Pascal but not for C cc1: warning: command line option "-funit-path=/s1/gcc-3.4.6/gcc/p/units" is valid for Pascal but not for C cc1: warning: command line option "-fautobuild" is valid for Pascal but not for C cc1: warning: command line option "-funit-path=/s1/gcc-3.4.6/gcc/p/test" is valid for Pascal but not for C cc1: warning: command line option "-funit-path=/s1/gcc-3.4.6/gcc/p/test/../rts" is valid for Pascal but not for C cc1: warning: command line option "-funit-path=/s1/gcc-3.4.6/gcc/p/test/../units" is valid for Pascal but not for C cc1: warning: command line option "-fexecutable-path=." is valid for Pascal but not for C OK

I'm not sure how to proceed here. Why is it calling cc1? Why is it passing options that the backend doesn't like? Is this something that gcc-3.4.6 has changed?

For debugging, you could insert an echo statement in test_run, to find out how exactly it invokes GPC, then try this command-line manually, and if it still fails, play with the options to find out what's causing this.

The relevant line for most test programs (including abso1) is:

if { $PC_WITH_FLAGS -Werror "$1"; } 2>&1; then

Note there are some similar looking lines, this is line 254. So you could put before it:

echo $PC_WITH_FLAGS -Werror "$1"

OK, here we go. This is how it's called: ---PC_WITH_FLAGS--- /s1/gpc-build-20060325-3.4.6/gcc/xgpc -B/s1/gpc-build-20060325-3.4.6/gcc/ --unit-path=/gnulocal/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6/units -I /gnulocal/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6/units -I ../rts --no-unit-path --unit-path=/s1/gcc-3.4.6/gcc/p/units --autobuild -g -O3 -W -Wall -Wno-unused -o a.out --unit-path=/s1/gcc-3.4.6/gcc/p/test --unit-path=/s1/gcc-3.4.6/gcc/p/test/../rts --unit-path=/s1/gcc-3.4.6/gcc/p/test/../units -I /s1/gcc-3.4.6/gcc/p/test -I /s1/gcc-3.4.6/gcc/p/test/../units --executable-path=. -Werror /s1/gcc-3.4.6/gcc/p/test/abso1.pas ---PC_WITH_FLAGS--- If I run that on "hello.pas" I get the same warnings from "cc1". If I remove all "--unit-path" directives, and the "--executable-path" and "--no-unit-path" directives, the warnings are gone (which was to be expected, but isn't very enlightening). Adding "-v" to the gpc command line suggests that the warnings might come from "collect2": ... GNU Pascal Compiler PreProcessor version 20060325, based on gcc-3.4.6 {$include "..."} search starts here: {$include <...>} search starts here: /gnulocal/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6/units ../rts /s1/gcc-3.4.6/gcc/p/test /s1/gcc-3.4.6/gcc/p/test/../units End of search list. as -u -mppc -o /tmp//cchPIwsI.o /tmp//cckcaRBw.s /s1/gpc-build-20060325-3.4.6/gcc/collect2 -bpT:0x10000000 -bpD:0x20000000 -btextro -bnodelcsect -bexport:/usr/lib/libg.exp -o a.out /lib/crt0.o -L/s1/gpc-build-20060325-3.4.6/gcc -L/gnulocal/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6 -L/gnulocal/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6/../../.. /tmp//cchPIwsI.o -lgpc -lm /s1/gpc-build-20060325-3.4.6/gcc/libgcc.a /s1/gpc-build-20060325-3.4.6/gcc/libgcc_eh.a -lg -lc /s1/gpc-build-20060325-3.4.6/gcc/libgcc.a /s1/gpc-build-20060325-3.4.6/gcc/libgcc_eh.a cc1: warning: command line option "-funit-path=/gnulocal/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6/units" is valid for Pascal but not for C cc1: warning: command line option "-fno-unit-path" is valid for Pascal but not for C cc1: warning: command line option "-funit-path=/s1/gcc-3.4.6/gcc/p/units" is valid for Pascal but not for C cc1: warning: command line option "-fautobuild" is valid for Pascal but not for C cc1: warning: command line option "-funit-path=/s1/gcc-3.4.6/gcc/p/test" is valid for Pascal but not for C cc1: warning: command line option "-funit-path=/s1/gcc-3.4.6/gcc/p/test/../rts" is valid for Pascal but not for C Which is backed by the fact that if I run GPC als "compile-only" (gpc -c), I don't get any warnings. I still don't understand it, though. Where does collect2 get these options from? Are they included in the .o file?

...

Compiling a simple "hello,world" program works, with no warnings:

gd@hilb31:/tmp> gpc -Wall -o hello hello.pas gd@hilb31:/tmp> ./hello Hello, World

BTW, you made sure this is the newly installed GPC here, not an older version, did you?

Yes, there was no gpc on that machine beforehand. It has the same problems, though, when I add some of the triggering options: gd@hilb31:/tmp> /gnulocal/bin/gpc -Wall -o hello hello.pas gd@hilb31:/tmp> ./hello Hello, World gd@hilb31:/tmp> /gnulocal/bin/gpc -Wall --no-unit-path -o hello hello.pas cc1: warning: command line option "-fno-unit-path" is valid for Pascal but not for C gd@hilb31:/tmp> ./hello Hello, World So - what can I try next? regards, gert -- Gert Doering gd@medat.de MEDAT Muenchen Tel: 089/126808-0 Fax: -50

Frank Heckenbach wrote:

Gert Doering wrote:

...

OK, here we go. This is how it's called:

---PC_WITH_FLAGS--- /s1/gpc-build-20060325-3.4.6/gcc/xgpc -B/s1/gpc-build-20060325-3.4.6/gcc/ --unit-path=/gnulocal/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6/units -I /gnulocal/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6/units -I ../rts --no-unit-path --unit-path=/s1/gcc-3.4.6/gcc/p/units --autobuild -g -O3 -W -Wall -Wno-unused -o a.out --unit-path=/s1/gcc-3.4.6/gcc/p/test --unit-path=/s1/gcc-3.4.6/gcc/p/test/../rts --unit-path=/s1/gcc-3.4.6/gcc/p/test/../units -I /s1/gcc-3.4.6/gcc/p/test -I /s1/gcc-3.4.6/gcc/p/test/../units --executable-path=. -Werror /s1/gcc-3.4.6/gcc/p/test/abso1.pas ---PC_WITH_FLAGS---

If I run that on "hello.pas" I get the same warnings from "cc1".

Adding "-v" to the gpc command line suggests that the warnings might come from "collect2":

Ah, collect2 ... :-/

...

... GNU Pascal Compiler PreProcessor version 20060325, based on gcc-3.4.6

{$include "..."} search starts here: {$include <...>} search starts here: /gnulocal/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6/units ../rts /s1/gcc-3.4.6/gcc/p/test /s1/gcc-3.4.6/gcc/p/test/../units End of search list. as -u -mppc -o /tmp//cchPIwsI.o /tmp//cckcaRBw.s /s1/gpc-build-20060325-3.4.6/gcc/collect2 -bpT:0x10000000 -bpD:0x20000000 -btextro -bnodelcsect -bexport:/usr/lib/libg.exp -o a.out /lib/crt0.o -L/s1/gpc-build-20060325-3.4.6/gcc -L/gnulocal/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6 -L/gnulocal/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6/../../.. /tmp//cchPIwsI.o -lgpc -lm /s1/gpc-build-20060325-3.4.6/gcc/libgcc.a /s1/gpc-build-20060325-3.4.6/gcc/libgcc_eh.a -lg -lc /s1/gpc-build-20060325-3.4.6/gcc/libgcc.a /s1/gpc-build-20060325-3.4.6/gcc/libgcc_eh.a cc1: warning: command line option "-funit-path=/gnulocal/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6/units" is valid for Pascal but not for C cc1: warning: command line option "-fno-unit-path" is valid for Pascal but not for C cc1: warning: command line option "-funit-path=/s1/gcc-3.4.6/gcc/p/units" is valid for Pascal but not for C cc1: warning: command line option "-fautobuild" is valid for Pascal but not for C cc1: warning: command line option "-funit-path=/s1/gcc-3.4.6/gcc/p/test" is valid for Pascal but not for C cc1: warning: command line option "-funit-path=/s1/gcc-3.4.6/gcc/p/test/../rts" is valid for Pascal but not for C

I still don't understand it, though. Where does collect2 get these options from? Are they included in the .o file?

I also wonder. Strangely, in the collect2 command line above, these options don't even appear. OTOH, I think collect2 does some fairly convoluted stuff (e.g., to output C++ templates AFAIK), so I wouldn't even be surprised if the options are embedded in the .o files or something ... :-(

The driver passes options to collect2 via environment (see `set_collect_gcc_options' in `gpc.c'). The problem is that the driver does not remove options which are invalid for C compiler. In principle other languages should have the same problem, I wonder how (if???) they handle it. -- Waldek Hebisch hebisch@math.uni.wroc.pl

Frank Heckenbach wrote:

Waldek Hebisch wrote:

...

The driver passes options to collect2 via environment (see `set_collect_gcc_options' in `gpc.c'). The problem is that the driver does not remove options which are invalid for C compiler. In principle other languages should have the same problem, I wonder how (if???) they handle it.

Do you know what collect2 has to compile here at all? Perhaps other languages don't need to, and perhaps we can avoid it as well ...

I do not know more details, all I know is just from quick scan trough collect2 sources. Perhaps we should ask on gcc list? -- Waldek Hebisch hebisch@math.uni.wroc.pl

Hi, another very old thread that I can now revive a bit... also full quoted to spur your memory :-) On Thu, Jul 06, 2006 at 07:32:31PM +0200, Frank Heckenbach wrote:

Waldek Hebisch wrote:

...

Frank Heckenbach wrote:

...

Waldek Hebisch wrote:

...

The driver passes options to collect2 via environment (see `set_collect_gcc_options' in `gpc.c'). The problem is that the driver does not remove options which are invalid for C compiler. In principle other languages should have the same problem, I wonder how (if???) they handle it.

Do you know what collect2 has to compile here at all? Perhaps other languages don't need to, and perhaps we can avoid it as well ...

I do not know more details, all I know is just from quick scan trough collect2 sources. Perhaps we should ask on gcc list?

Can you (Gert) check what it does? Perhaps catch the input file to collect2 and send it to us?

Frank

Actually the input file is not overly helpful, as it really only is the output of "as" - a plain .o file. But collect2 creates a C file on its own (!) and links that. Digging through the code, I found an option ("-debug") that will make collect2 really verbose, and it will show what programs it calls, and what it does. Looking at the output (appended below in all its glory) it seems that collect2 seems to collect some "constructor" stuff, builds a C program from that, and calls gcc to compile this. Actually, it prints that it has "0 constructors", but "10 frame tables"... I do not have the slightest idea why it would want to do so, or whether this is unavoidable... - but you can nicely see the compiler invocation with the "wrong" flags. The "... is valid for Pascal but not for C" line is coming from opts.c in gcc, function complain_wrong_lang(). So, here we go. "h2.pas" is a simple "hello, world" program: ---- snip ---- program h2; begin writeln( 'world 2' ); end. ---- snap ---- gd@hilb31:/tmp> gpc -Wl,-debug -v -fno-unit-path -save-temps -o h2 h2.pas Reading specs from /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/specs Configured with: ../gcc-3.4.6/configure --prefix=/gnu/gpc --enable-languages=pascal Thread model: aix gpc version 20060325, based on gcc-3.4.6 /gnu_61/gpc/bin/../libexec/gcc/rs6000-ibm-aix/3.4.6/gpc1 -E -quiet -v -iprefix /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/ h2.pas -famtmpfile=/tmp//ccCRckKT.gpa -fno-unit-path -o h2.i GNU Pascal Compiler PreProcessor version 20060325, based on gcc-3.4.6 /gnu_61/gpc/bin/../libexec/gcc/rs6000-ibm-aix/3.4.6/gpc1 -fpreprocessed h2.i -quiet -dumpbase h2.pas -auxbase h2 -famtmpfile=/tmp//ccCRckKT.gpa -fno-unit-path -version -o h2.s GNU Pascal version 20060325, based on gcc-3.4.6 (rs6000-ibm-aix) compiled by GNU C version 4.2.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 as -u -mppc -o h2.o h2.s /gnu_61/gpc/bin/../libexec/gcc/rs6000-ibm-aix/3.4.6/collect2 -bpT:0x10000000 -bpD:0x20000000 -btextro -bnodelcsect -o h2 /lib/crt0.o -L/gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6 -L/gnu_61/gpc/bin/../lib/gcc -L/gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6 -L/gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/../../.. -L/gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/../../.. -debug h2.o -lgpc -lm /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/libgcc.a /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/libgcc_eh.a -lc /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/libgcc.a /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/libgcc_eh.a Convert string '/gnu_61/gpc/bin/../libexec/gcc/rs6000-ibm-aix/3.4.6/:/gnu_61/gpc/bin/../libexec/gcc/:/gnu/gpc/libexec/gcc/rs6000-ibm-aix/3.4.6/:/gnu/gpc/libexec/gcc/rs6000-ibm-aix/3.4.6/:/gnu/gpc/libexec/gcc/rs6000-ibm-aix/:/gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/:/gnu/gpc/lib/gcc/rs6000-ibm-aix/:/usr/libexec/gcc/rs6000-ibm-aix/3.4.6/:/usr/libexec/gcc/rs6000-ibm-aix/:/usr/lib/gcc/rs6000-ibm-aix/3.4.6/:/usr/lib/gcc/rs6000-ibm-aix/:/gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/../../../../rs6000-ibm-aix/bin/rs6000-ibm-aix/3.4.6/:/gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/../../../../rs6000-ibm-aix/bin/:/gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/../../../../rs6000-ibm-aix/bin/rs6000-ibm-aix/3.4.6/:/gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/../../../../rs6000-ibm-aix/bin/' into prefixes, separator = ':' - add prefix: /gnu_61/gpc/bin/../libexec/gcc/rs6000-ibm-aix/3.4.6/ - add prefix: /gnu_61/gpc/bin/../libexec/gcc/ - add prefix: /gnu/gpc/libexec/gcc/rs6000-ibm-aix/3.4.6/ - add prefix: /gnu/gpc/libexec/gcc/rs6000-ibm-aix/3.4.6/ - add prefix: /gnu/gpc/libexec/gcc/rs6000-ibm-aix/ - add prefix: /gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/ - add prefix: /gnu/gpc/lib/gcc/rs6000-ibm-aix/ - add prefix: /usr/libexec/gcc/rs6000-ibm-aix/3.4.6/ - add prefix: /usr/libexec/gcc/rs6000-ibm-aix/ - add prefix: /usr/lib/gcc/rs6000-ibm-aix/3.4.6/ - add prefix: /usr/lib/gcc/rs6000-ibm-aix/ - add prefix: /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/../../../../rs6000-ibm-aix/bin/rs6000-ibm-aix/3.4.6/ - add prefix: /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/../../../../rs6000-ibm-aix/bin/ - add prefix: /gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/../../../../rs6000-ibm-aix/bin/rs6000-ibm-aix/3.4.6/ - add prefix: /gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/../../../../rs6000-ibm-aix/bin/ Convert string '/bin:.:/local/bin:/medat/bin:/usr/linux/bin:/usr/local/bin:/gnu/bin:/gnulocal/bin:/usr/vac/bin:/opt/freeware/bin:/usr/bin:/etc:/usr/sbin:/usr/bin/X11:/sbin:/usr/java/jre/bin:/usr/java/bin:/medat/modem/bin:/ora/app/oracle/product/11.1.0/bin:/home/dba/bin:/ora/medat/bin:/gnulocal/bin:/home/gd/bin' into prefixes, separator = ':' - add prefix: /bin/ - add prefix: ./ - add prefix: /local/bin/ - add prefix: /medat/bin/ - add prefix: /usr/linux/bin/ - add prefix: /usr/local/bin/ - add prefix: /gnu/bin/ - add prefix: /gnulocal/bin/ - add prefix: /usr/vac/bin/ - add prefix: /opt/freeware/bin/ - add prefix: /usr/bin/ - add prefix: /etc/ - add prefix: /usr/sbin/ - add prefix: /usr/bin/X11/ - add prefix: /sbin/ - add prefix: /usr/java/jre/bin/ - add prefix: /usr/java/bin/ - add prefix: /medat/modem/bin/ - add prefix: /ora/app/oracle/product/11.1.0/bin/ - add prefix: /home/dba/bin/ - add prefix: /ora/medat/bin/ - add prefix: /gnulocal/bin/ - add prefix: /home/gd/bin/ Looking for 'real-ld' Looking for 'collect-ld' Looking for 'ld' Looking for 'ld' Looking for '/usr/ucb/nm' - failed to locate using absolute path Looking for 'gnm' Looking for 'gnm' Looking for 'nm' Looking for 'nm' Looking for 'gstrip' Looking for 'gstrip' Looking for 'strip' Looking for 'strip' Looking for 'gpc' Looking for 'gpc' Convert string '/gnu/lib:/gnu/samba/lib:/corba/v158/ACE_wrappers/lib' into prefixes, separator = ':' - add prefix: /gnu/lib/ - add prefix: /gnu/samba/lib/ - add prefix: /corba/v158/ACE_wrappers/lib/ searching for: /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/libgpc.a found: /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/libgpc.a searching for: /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/libm.a searching for: /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/libm.so searching for: /gnu_61/gpc/bin/../lib/gcc/libm.a searching for: /gnu_61/gpc/bin/../lib/gcc/libm.so searching for: /gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/libm.a searching for: /gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/libm.so searching for: /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/../../../libm.a searching for: /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/../../../libm.so searching for: /gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/../../../libm.a searching for: /gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/../../../libm.so searching for: /gnu/lib/libm.a searching for: /gnu/lib/libm.so searching for: /gnu/samba/lib/libm.a searching for: /gnu/samba/lib/libm.so searching for: /corba/v158/ACE_wrappers/lib/libm.a searching for: /corba/v158/ACE_wrappers/lib/libm.so searching for: /lib/libm.a found: /lib/libm.a searching for: /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/libc.a searching for: /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/libc.so searching for: /gnu_61/gpc/bin/../lib/gcc/libc.a searching for: /gnu_61/gpc/bin/../lib/gcc/libc.so searching for: /gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/libc.a searching for: /gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/libc.so searching for: /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/../../../libc.a searching for: /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/../../../libc.so searching for: /gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/../../../libc.a searching for: /gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/../../../libc.so searching for: /gnu/lib/libc.a searching for: /gnu/lib/libc.so searching for: /gnu/samba/lib/libc.a searching for: /gnu/samba/lib/libc.so searching for: /corba/v158/ACE_wrappers/lib/libc.a searching for: /corba/v158/ACE_wrappers/lib/libc.so searching for: /lib/libc.a found: /lib/libc.a List of libraries: /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/libgpc.a, /lib/libm.a, /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/libgcc.a, /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/libgcc_eh.a, /lib/libc.a, sec=2 class=2 type=0 _GLOBAL__F___divdi3 sec=2 class=2 type=0 _GLOBAL__F___moddi3 sec=2 class=2 type=0 _GLOBAL__F___udivdi3 sec=2 class=2 type=0 _GLOBAL__F___umoddi3 sec=2 class=2 type=0 _GLOBAL__F___udiv_w_sdiv sec=2 class=2 type=0 _GLOBAL__F___udivmoddi4 sec=2 class=2 type=0 _GLOBAL__F__Unwind_GetGR sec=2 class=2 type=0 _GLOBAL__F___register_frame_info_bases sec=2 class=2 type=0 _GLOBAL__F___gnat_default_lock sec=2 class=2 type=0 _GLOBAL__F___gcc_personality_v0 collect2 version 3.4.6 ld_file_name = /bin/ld c_file_name = /gnu/bin/gpc nm_file_name = /bin/nm strip_file_name = /bin/strip c_file = /tmp//ccGqyPUX.c o_file = /tmp//ccqwtITO.o COLLECT_GCC_OPTIONS = '-famtmpfile=/tmp//ccCRckKT.gpa' '-v' '-fno-unit-path' '-save-temps' '-o' 'h2' COLLECT_GCC = gpc COMPILER_PATH = /gnu_61/gpc/bin/../libexec/gcc/rs6000-ibm-aix/3.4.6/:/gnu_61/gpc/bin/../libexec/gcc/:/gnu/gpc/libexec/gcc/rs6000-ibm-aix/3.4.6/:/gnu/gpc/libexec/gcc/rs6000-ibm-aix/3.4.6/:/gnu/gpc/libexec/gcc/rs6000-ibm-aix/:/gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/:/gnu/gpc/lib/gcc/rs6000-ibm-aix/:/usr/libexec/gcc/rs6000-ibm-aix/3.4.6/:/usr/libexec/gcc/rs6000-ibm-aix/:/usr/lib/gcc/rs6000-ibm-aix/3.4.6/:/usr/lib/gcc/rs6000-ibm-aix/:/gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/../../../../rs6000-ibm-aix/bin/rs6000-ibm-aix/3.4.6/:/gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/../../../../rs6000-ibm-aix/bin/:/gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/../../../../rs6000-ibm-aix/bin/rs6000-ibm-aix/3.4.6/:/gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/../../../../rs6000-ibm-aix/bin/ LIBRARY_PATH = /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/:/gnu_61/gpc/bin/../lib/gcc/:/gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/:/usr/lib/gcc/rs6000-ibm-aix/3.4.6/:/gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/../../../../rs6000-ibm-aix/lib/rs6000-ibm-aix/3.4.6/:/gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/../../../../rs6000-ibm-aix/lib/:/gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/../../../../rs6000-ibm-aix/lib/rs6000-ibm-aix/3.4.6/:/gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/../../../../rs6000-ibm-aix/lib/:/gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/../../../rs6000-ibm-aix/3.4.6/:/gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/../../../:/gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/../../../rs6000-ibm-aix/3.4.6/:/gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/../../../:/lib/rs6000-ibm-aix/3.4.6/:/lib/:/usr/lib/rs6000-ibm-aix/3.4.6/:/usr/lib/ 0 constructor(s) found 0 destructor(s) found 10 frame table(s) found [Leaving h2] write_c_file - output name is h2, prefix is h2 ========== output_file = h2, c_file = /tmp//ccGqyPUX.c #ifdef __cplusplus extern "C" { #endif write_c_file - output name is h2, prefix is h2 static int count; typedef void entry_pt(); extern void *x6 __asm__ ("_GLOBAL__F___divdi3"); extern void *x7 __asm__ ("_GLOBAL__F___moddi3"); extern void *x8 __asm__ ("_GLOBAL__F___udivdi3"); extern void *x9 __asm__ ("_GLOBAL__F___umoddi3"); extern void *x10 __asm__ ("_GLOBAL__F___udiv_w_sdiv"); extern void *x11 __asm__ ("_GLOBAL__F___udivmoddi4"); extern void *x12 __asm__ ("_GLOBAL__F__Unwind_GetGR"); extern void *x13 __asm__ ("_GLOBAL__F___register_frame_info_bases"); extern void *x14 __asm__ ("_GLOBAL__F___gnat_default_lock"); extern void *x15 __asm__ ("_GLOBAL__F___gcc_personality_v0"); static void *frame_table[] = { &x6, &x7, &x8, &x9, &x10, &x11, &x12, &x13, &x14, &x15, 0 }; struct object { void *pc_begin; void *pc_end; void *fde_begin; void *fde_array; __SIZE_TYPE__ count; struct object *next; }; extern void __register_frame_info_table (void *, struct object *); extern void *__deregister_frame_info (void *); static void reg_frame () { static struct object ob; __register_frame_info_table (frame_table, &ob); } static void dereg_frame () { __deregister_frame_info (frame_table); } void _GLOBAL__FI_h2() { static entry_pt *ctors[] = { reg_frame, }; entry_pt **p; if (count++ != 0) return; p = ctors + 1; while (p > ctors) (*--p)(); } void _GLOBAL__FD_h2() { static entry_pt *dtors[] = { dereg_frame, }; entry_pt **p; if (--count != 0) return; p = dtors; while (p < dtors + 1) (*p++)(); } #ifdef __cplusplus } #endif ========== end of c_file ========== export_file = /tmp//ccsRlM3F.x ========== end of export_file /gnu/bin/gpc -x c -c -o /tmp//ccqwtITO.o -famtmpfile=/tmp//ccCRckKT.gpa -fno-unit-path -fno-profile-arcs -fno-test-coverage -fno-branch-probabilities -fno-exceptions -w /tmp//ccGqyPUX.c cc1: warning: command line option "-fno-unit-path" is valid for Pascal but not for C /bin/ld -bpT:0x10000000 -bpD:0x20000000 -btextro -bnodelcsect -o h2 /lib/crt0.o /tmp//ccqwtITO.o -L/gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6 -L/gnu_61/gpc/bin/../lib/gcc -L/gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6 -L/gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/../../.. -L/gnu/gpc/lib/gcc/rs6000-ibm-aix/3.4.6/../../.. h2.o -lgpc -lm /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/libgcc.a /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/libgcc_eh.a -lc /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/libgcc.a /gnu_61/gpc/bin/../lib/gcc/rs6000-ibm-aix/3.4.6/libgcc_eh.a -binitfini:_GLOBAL__FI_h2:_GLOBAL__FD_h2 [Leaving /tmp//ccGqyPUX.c] [Leaving /tmp//ccqwtITO.o] [Leaving /tmp//ccsRlM3F.x] -- MEDAT Computer-Systeme GmbH +--------------------------------------------- Albrecht. 14 | HRB Muenchen 56 206, USt-IdNr. DE129411894 D-80636 Muenchen | Geschaeftsfuehrer: Tel: +49 89 126808-0 | - Dr. Peter-K. Escher-Vetter Fax: +49 89 126808-50 | - Dipl.-Ing- Erwin Mayr M: g.doering@medat.de +