Hi,
On Wed, Jun 16, 2004 at 08:30:38PM +0200, Frank Heckenbach wrote:
Gert Doering wrote:
I'm trying to build the gpc-20040516 "beta" snapshopt with GCC-3.3.x on AIX 5.1. GCC-3.x itself supports AIX 5, I have a working version on the system (binary install, not compiled-it-myself).
[..]
the line 511 is this one:
TARGET_CPU_CPP_BUILTINS ();...which fully escapes me as for why it might not compile...!??
[..]
Unless you need very particular system conditionals (Pascal programs usually don't), just insert the line
#define rs6000_cpu_cpp_builtins(foo)
in lang.c.
Thanks for your quick reply. Unfortunately, I didn't see it before today because my spam filter didn't know about the GNU Pascal list yet (all e-mails with unknown To:/CC: headers are quarantained as "maybe spam". Stupid me.)
I will try this approach over the weekend.
In the meantime, I tried something else - gcc-3.2.3 with gpc-20040516, again on AIX 5.1 and additionally on AIX 5.2 (in case AIX 5.1 is broken).
The effect is quite different here. It builds all of xgpc and the libgpc.a just fine, but then crashes in trying to build "binobj".
The error is this:
gmake[2]: Entering directory `/s1/gpc-build/gcc/p/utils' ../.././xgpc -B../.././ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/s1/gcc-3.2.3/gcc/p/rts --unit-path=/s1/gcc-3.2.3/gcc/p/units `cat needed-options` "/s1/gcc-3.2.3/gcc/p/utils/binobj.pas" collect2: library libgpc not found gmake[2]: *** [binobj] Error 1 gmake[2]: Leaving directory `/s1/gpc-build/gcc/p/utils' gmake[1]: *** [pascal.utils] Error 2 gmake[1]: Leaving directory `/s1/gpc-build/gcc'
If I change the -B invocation to use an absolute path, the library is found, but the (AIX) ld doesn't really like the result either:
../.././xgpc -B/s1/gpc-build/gcc/ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/s1/gcc-3.2.3/gcc/p/rts --unit-path=/s1/gcc-3.2.3/gcc/p/units `cat needed-options` "/s1/gcc-3.2.3/gcc/p/utils/binobj.pas" ld: 0711-317 ERROR: Undefined symbol: Tempdirectory.1 ld: 0711-317 ERROR: Undefined symbol: Tempstr.4 ld: 0711-317 ERROR: Undefined symbol: Buffer.8 ld: 0711-317 ERROR: Undefined symbol: Zero.3 ld: 0711-317 ERROR: Undefined symbol: Epoch.6 ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status
I've checked with "nm", and it looks like all the stuff should be there:
gd@hilb3:/s1/gpc-build/gcc/p/utils> nm ../../libgpc.a | grep Tempdir Tempdirectory.1 U - Tempdirectory.1 d 37956 8 Tempdirectory.1.P8 d 37952 4 Tempdirectoryset.0 d 37948 4
Since I had the nagging suspicion that there might be something in the pascal libraries that the system ld doesn't understand, I tried installing the GNU binutils, ./configure'd again, and rebuilt.
Built bombed in libgcc (gcc created stuff that gas didn't like).
Removed gas, ./configure'd again, rebuilt.
Same error as above (collect2 not finding libgpc). Trying again with absolute paths and GNU ld linked into the "-B" directory as "real-ld" led to a new error:
../.././xgpc -B/gnulocal/src/gcc-3.2.3/gcc/ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/gnulocal/src/gcc-3.2.3/gcc/p/rts --unit-path=/gnulocal/src/gcc-3.2.3/gcc/p/units `cat needed-options` "binobj.pas"
/gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Tempdirectory.1' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Tempstr.4' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Buffer.8' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(time.o)(.tc+0x4):time.pas: undefined reference to `Zero.3' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(time.o)(.tc+0x4):time.pas: undefined reference to `Epoch.6' collect2: ld returned 1 exit status
(the -B path is different from the example above, because it's a different system - the other one doesn't have the GNU binutils installed yet - but don't let that confuse you)
--> so it seems that actually the library itself has unresolved symbols, and not the "binobj.pas" program it tries to link.
"ranlib" doesn't help either.
Any further ideas how to tackle this? The whole symbol format confuses me - being a C programmer, I'm used to errors about "_crypt" not found, but not without a "_" and neither with trailing numbers...
thanks again,
gert
Gert Doering wrote:
In the meantime, I tried something else - gcc-3.2.3 with gpc-20040516, again on AIX 5.1 and additionally on AIX 5.2 (in case AIX 5.1 is broken).
Incidentally I also have to build GPC on AIX 5 at the moment (powerpc-ibm-aix5.1.0.0).
Although gcc-3.2.1 was already installed on the system, building with it didn't seem to work (unrecognizable insn). So I did this ...
export CC=cc ../gcc-3.3.3/configure --prefix=$HOME/usr --enable-languages=pascal gmake bootstrap
The effect is quite different here. It builds all of xgpc and the libgpc.a just fine, but then crashes in trying to build "binobj".
(BTW, I wouldn't call an error message a crash. To me a crash is a segfault or something like this.)
The error is this:
gmake[2]: Entering directory `/s1/gpc-build/gcc/p/utils' ../.././xgpc -B../.././ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/s1/gcc-3.2.3/gcc/p/rts --unit-path=/s1/gcc-3.2.3/gcc/p/units `cat needed-options` "/s1/gcc-3.2.3/gcc/p/utils/binobj.pas" collect2: library libgpc not found
... and got this as well.
If I change the -B invocation to use an absolute path,
Or do this (which I'm adding in GPC):
--- p/Make-lang.in.orig Mon May 31 02:18:22 2004 +++ p/Make-lang.in Sun Jun 27 20:01:26 2004 @@ -195,7 +195,7 @@ # Flags to pass when building the utilities. (PC is the GPC for the host!) UTILS_FLAGS_TO_PASS=\ SHELL="$(SHELL)" \ - PC="`if [ x"$(GPC_HOST)" = x"$(target)" ]; then echo $(GPC_FOR_TARGET)' '; else echo $(CC) | $(GCC2GPC); fi | $(ADD_RTS_PARENT_DIR)` -I../rts" \ + PC="`if [ x"$(GPC_HOST)" = x"$(target)" ]; then echo $(GPC_FOR_TARGET)' '; else echo $(CC) | $(GCC2GPC); fi | $(ADD_RTS_PARENT_DIR)` -I../rts -L../.." \ CFLAGS="$(CFLAGS)" \ PFLAGS="$(PFLAGS)" \ exeext="$(exeext)" \
the library is found, but the (AIX) ld doesn't really like the result either:
../.././xgpc -B/s1/gpc-build/gcc/ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/s1/gcc-3.2.3/gcc/p/rts --unit-path=/s1/gcc-3.2.3/gcc/p/units `cat needed-options` "/s1/gcc-3.2.3/gcc/p/utils/binobj.pas" ld: 0711-317 ERROR: Undefined symbol: Tempdirectory.1 ld: 0711-317 ERROR: Undefined symbol: Tempstr.4 ld: 0711-317 ERROR: Undefined symbol: Buffer.8 ld: 0711-317 ERROR: Undefined symbol: Zero.3 ld: 0711-317 ERROR: Undefined symbol: Epoch.6 ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status
Then I get that as well.
Since I had the nagging suspicion that there might be something in the pascal libraries that the system ld doesn't understand, I tried installing the GNU binutils, ./configure'd again, and rebuilt.
Built bombed in libgcc (gcc created stuff that gas didn't like).
Yes, the GCC install instructions say this won't work.
/gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Tempdirectory.1' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Tempstr.4' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Buffer.8' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(time.o)(.tc+0x4):time.pas: undefined reference to `Zero.3' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(time.o)(.tc+0x4):time.pas: undefined reference to `Epoch.6' collect2: ld returned 1 exit status
--> so it seems that actually the library itself has unresolved symbols, and not the "binobj.pas" program it tries to link.
Yes. I think I know what's causing this (probably a GPC bug). I'm trying to solve it, will report soon (I hope) ...
Any further ideas how to tackle this? The whole symbol format confuses me - being a C programmer, I'm used to errors about "_crypt" not found, but not without a "_" and neither with trailing numbers...
BTW, I only seem to remember a `_' prefix on DJGPP and such systems (for compatibility with some ancient Dos assemblers, but that's another story) -- unless the programmer puts one there intentionally. The numbers are appended by GCC or the linker for local symbols to avoid collisions when the same name is used in different scopes. But probably that's all irrelevant to the problem.
Frank
I wrote:
Gert Doering wrote:
../.././xgpc -B/s1/gpc-build/gcc/ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/s1/gcc-3.2.3/gcc/p/rts --unit-path=/s1/gcc-3.2.3/gcc/p/units `cat needed-options` "/s1/gcc-3.2.3/gcc/p/utils/binobj.pas" ld: 0711-317 ERROR: Undefined symbol: Tempdirectory.1 ld: 0711-317 ERROR: Undefined symbol: Tempstr.4 ld: 0711-317 ERROR: Undefined symbol: Buffer.8 ld: 0711-317 ERROR: Undefined symbol: Zero.3 ld: 0711-317 ERROR: Undefined symbol: Epoch.6 ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status
I think I know what's causing this (probably a GPC bug). I'm trying to solve it, will report soon (I hope) ...
For now, I'm afraid I only have a work-around for this problem in the RTS. With this applied, I get these results -- all of the failures are for the same reason (static local variables of schema, string or file type). I hope I can provide a better solution soon, but since this isn't common in normal code (and not standard, anyway), GPC should be mostly usable this way.
UNSUPPORTED: asmtest.pas FAIL: bo4-18.pas UNSUPPORTED: crttest.pas FAIL: fjf354.pas FAIL: fjf458a.pas FAIL: fjf458b.pas FAIL: fjf458c.pas FAIL: fjf458d.pas FAIL: fjf459a.pas FAIL: fjf459b.pas UNSUPPORTED: fjf77.pas UNSUPPORTED: gmptest.pas UNSUPPORTED: jj5.pas UNSUPPORTED: longr2.pas UNSUPPORTED: regextest.pas
Frank
Hi,
(answering two mails in one)
On Sun, Jun 27, 2004 at 08:35:40PM +0100, Frank Heckenbach wrote:
Gert Doering wrote:
In the meantime, I tried something else - gcc-3.2.3 with gpc-20040516, again on AIX 5.1 and additionally on AIX 5.2 (in case AIX 5.1 is broken).
Incidentally I also have to build GPC on AIX 5 at the moment (powerpc-ibm-aix5.1.0.0).
Lucky me :-)
Although gcc-3.2.1 was already installed on the system, building with it didn't seem to work (unrecognizable insn). So I did this ...
Interesting. With gcc-3.3.1, *these* problems didn't happen for me.
[..]
The effect is quite different here. It builds all of xgpc and the libgpc.a just fine, but then crashes in trying to build "binobj".
(BTW, I wouldn't call an error message a crash. To me a crash is a segfault or something like this.)
"The build process aborted in an unexpected way". However :-)
[..]
If I change the -B invocation to use an absolute path,
Or do this (which I'm adding in GPC):
--- p/Make-lang.in.orig Mon May 31 02:18:22 2004 +++ p/Make-lang.in Sun Jun 27 20:01:26 2004
I've patched my tree with this, and it fixed the -B problem on both AIX 5.1 and AIX 5.2 (gcc-3.3.3, gpc-20040516).
[..]
Second problem:
ld: 0711-317 ERROR: Undefined symbol: Tempdirectory.1 ld: 0711-317 ERROR: Undefined symbol: Tempstr.4 ld: 0711-317 ERROR: Undefined symbol: Buffer.8 ld: 0711-317 ERROR: Undefined symbol: Zero.3 ld: 0711-317 ERROR: Undefined symbol: Epoch.6 ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status
Then I get that as well.
[..]
Any further ideas how to tackle this? The whole symbol format confuses me - being a C programmer, I'm used to errors about "_crypt" not found, but not without a "_" and neither with trailing numbers...
BTW, I only seem to remember a `_' prefix on DJGPP and such systems (for compatibility with some ancient Dos assemblers, but that's another story) -- unless the programmer puts one there intentionally.
I stand corrected. Re-checked some of the unix system I regularily work on, an none uses an "_" prefix. Must be a leftover memory from Turbo C under DOS...
The numbers are appended by GCC or the linker for local symbols to avoid collisions when the same name is used in different scopes. But probably that's all irrelevant to the problem.
Thanks for explaining what the numbers do.
[..]
For now, I'm afraid I only have a work-around for this problem in the RTS. With this applied, I get these results -- all of the failures are for the same reason (static local variables of schema, string or file type). I hope I can provide a better solution soon, but since this isn't common in normal code (and not standard, anyway), GPC should be mostly usable this way.
I've applied the second patch (to the pascal files) to my tree as well, and now both AIX 5.1 and AIX 5.2 build fine, and most of the test suite passes as well.
I get the same failing modules:
Test Run By gd on 2004-07-06 14:43:30 Native configuration is powerpc-ibm-aix5.1.0.0 (hilb1)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: asmtest.pas FAIL: bo4-18.pas UNSUPPORTED: crttest.pas FAIL: fjf354.pas FAIL: fjf458a.pas FAIL: fjf458b.pas FAIL: fjf458c.pas FAIL: fjf458d.pas FAIL: fjf459a.pas FAIL: fjf459b.pas UNSUPPORTED: fjf77.pas UNSUPPORTED: gmptest.pas UNSUPPORTED: jj5.pas UNSUPPORTED: longr2.pas UNSUPPORTED: regextest.pas
and on
Test Run By gd on 2004-07-06 15:29:41 Native configuration is powerpc-ibm-aix5.2.0.0 (hilb3) ... === gpc Summary ===
# of tests 3910 # of expected passes 3895 # of unexpected failures 8 # of unsupported tests 7
So, thank you very much for the workaround. We will have to rewrite parts of the software (some modules actually use static String and FILE variables), but we expect much more issues with structure alignment and such, converting from AIX xlp to gpc...
Out of curiosity: do you have any idea what's going on inside gpc/gcc here? Why is it breaking the *link* phase? Are various parts of the system disagreeing on the suffix number to use for the linker?
kind regards,
gert
Gert Doering wrote:
So, thank you very much for the workaround. We will have to rewrite parts of the software (some modules actually use static String and FILE variables), but we expect much more issues with structure alignment and such, converting from AIX xlp to gpc...
gpc has the maximum-field-alignment compiler directive: $maximum-field-alignment=value, where value= 8, 16, 32 (or 0 for the default). This even works with $local end $endlocal !
I don't know whether this is helpful or not (as I have no knowledge of AIX or xlp).
Regards,
Adriaan van Os
Gert Doering wrote:
So, thank you very much for the workaround. We will have to rewrite parts of the software (some modules actually use static String and FILE variables),
So I suppose you'd appreciate a solution. ;-) Well, I can probably work on it a bit this weekend ...
Out of curiosity: do you have any idea what's going on inside gpc/gcc here? Why is it breaking the *link* phase? Are various parts of the system disagreeing on the suffix number to use for the linker?
The problem is that such variables must be initialized. (For file types, it should be possible to do it via static initializers internally, and I might do this in the course of a future change, but not at the moment. For strings, it would theoretically be possible to use a static initializer as well, but since this would force the whole (often large) variable into the initialized data section and blow up executable sizes, I don't think this would be appreciated. So in general, I think we must assume that we need initialization code.)
Static variables must be initialized only once, even if they're local (otherwise they'd lose their values when the containing routine is called again which would defeat much of their purpose). I see two ways of doing it:
1. Initialize them from the module/program constructor. That's what I'm doing now. The problem is that we have to violate the scoping internally, and apparently the current way is not correct since the AIX linker probably considers the variable to be initialized as different from the actual local variable and so runs into unresolved references.
2. Initialize them when the routine is called and use a (static) flag to make sure this is done only once. The disadvantage is that the flag would have to be checked on each call which is a little performance disadvantage. So I'd consider it half a kluge, but still a better kludge than the RTS patch.
So I'll try to fix 1., but if I can't do it now, I'll probably do 2.
Frank
Hi,
On Wed, Jul 07, 2004 at 10:16:17AM +0100, Frank Heckenbach wrote:
Gert Doering wrote:
So, thank you very much for the workaround. We will have to rewrite parts of the software (some modules actually use static String and FILE variables),
So I suppose you'd appreciate a solution. ;-)
Indeed :-)
Well, I can probably work on it a bit this weekend ...
I'll happily give it a good testing on AIX 5.1 and 5.2...
Out of curiosity: do you have any idea what's going on inside gpc/gcc here? Why is it breaking the *link* phase? Are various parts of the system disagreeing on the suffix number to use for the linker?
The problem is that such variables must be initialized. (For file types, it should be possible to do it via static initializers internally, and I might do this in the course of a future change, but not at the moment. For strings, it would theoretically be possible to use a static initializer as well, but since this would force the whole (often large) variable into the initialized data section and blow up executable sizes, I don't think this would be appreciated. So in general, I think we must assume that we need initialization code.)
Hmmm. Indeed. Things like (in C)
static char text[10000] = "hello, world\n";
might indeed be very wastive on executable size.
I assume pascal strings work similar - a maximum size is allocated, and only the relevant part is initialized.
Static variables must be initialized only once, even if they're local (otherwise they'd lose their values when the containing routine is called again which would defeat much of their purpose).
This is understood :-)
I see two ways of doing it:
- Initialize them from the module/program constructor. That's what I'm doing now. The problem is that we have to violate the scoping internally, and apparently the current way is not correct since the AIX linker probably considers the variable to be initialized as different from the actual local variable and so runs into unresolved references.
What I do not understand about this: it's not only the AIX linker that breaks here. On the AIX 5.1 system, I have installed GNU ld, and it displayed the same problems with unresolved symbols.
$ ld --version GNU ld version 2.15 Copyright 2002 Free Software Foundation, Inc.
OTOH, on Linux, with GNU ld, everything works.
$ ld --version GNU ld version 2.15.90.0.1.1 20040303 (SuSE Linux) Copyright 2002 Free Software Foundation, Inc.
... so why does the same approach with the same gcc backend (3.3.3) and the same GNU ld work on Linux, and not on AIX?!
- Initialize them when the routine is called and use a (static) flag to make sure this is done only once. The disadvantage is that the flag would have to be checked on each call which is a little performance disadvantage. So I'd consider it half a kluge, but still a better kludge than the RTS patch.
Agreed.
So I'll try to fix 1., but if I can't do it now, I'll probably do 2.
Thanks!
gert
Gert Doering wrote:
Hmmm. Indeed. Things like (in C)
static char text[10000] = "hello, world\n";
might indeed be very wastive on executable size.
I assume pascal strings work similar - a maximum size is allocated, and only the relevant part is initialized.
Yes.
What I do not understand about this: it's not only the AIX linker that breaks here. On the AIX 5.1 system, I have installed GNU ld, and it displayed the same problems with unresolved symbols.
... so why does the same approach with the same gcc backend (3.3.3) and the same GNU ld work on Linux, and not on AIX?!
I'm not sure -- I'd have to learn more about linker internals which I hope to avoid. ;-) However, linkers are quite system specific, so there can be significant differences, even between GNU ld on both targets. (And so are assemblers and parts of the compiler backend, so I'm not even sure which one it is.)
Frank
Frank Heckenbach
Gert Doering wrote:
Out of curiosity: do you have any idea what's going on inside gpc/gcc here? Why is it breaking the *link* phase? Are various parts of the system disagreeing on the suffix number to use for the linker?
The problem is that such variables must be initialized. (For file types, it should be possible to do it via static initializers internally, and I might do this in the course of a future change, but not at the moment. For strings, it would theoretically be possible to use a static initializer as well, but since this would force the whole (often large) variable into the initialized data section and blow up executable sizes, I don't think this would be appreciated. So in general, I think we must assume that we need initialization code.)
IMHO for constants static initializer is preferable. In general case I agree -- code is more flexible.
Static variables must be initialized only once, even if they're local (otherwise they'd lose their values when the containing routine is called again which would defeat much of their purpose). I see two ways of doing it:
- Initialize them from the module/program constructor. That's what I'm doing now. The problem is that we have to violate the scoping internally, and apparently the current way is not correct since the AIX linker probably considers the variable to be initialized as different from the actual local variable and so runs into unresolved references.
AFAICS with qualified identifiers we can move static variables to global scope (mangle name and set DECL_CONTEXT to 0), which should avoid the problem.
Waldek Hebisch wrote:
Static variables must be initialized only once, even if they're local (otherwise they'd lose their values when the containing routine is called again which would defeat much of their purpose). I see two ways of doing it:
- Initialize them from the module/program constructor. That's what I'm doing now. The problem is that we have to violate the scoping internally, and apparently the current way is not correct since the AIX linker probably considers the variable to be initialized as different from the actual local variable and so runs into unresolved references.
AFAICS with qualified identifiers we can move static variables to global scope (mangle name and set DECL_CONTEXT to 0), which should avoid the problem.
I've tried this when I did this initially. According to a note of mine, just setting DECL_CONTEXT to NULL caused some problems (I don't remember exactly which at the moment), but I think I'll have to investigate them again and try to fix them if possible. (Maybe it's because such a declaration shouldn't be in the list that the backend retrieves via getdecls() locally, rather in the global list, but that's just a guess for now ...)
Mangling the (linker) name is also an issue, but even without QI this shouldn't be a big deal (get_unique_identifier or so, since this name is only used internally, unless an explicit name attribute is given, in which case the issue doesn't arise). I'll also apply your QI patches, of course, but right now I need an AIX fix quickly.
Frank
Frank Heckenbach wrote:
Waldek Hebisch wrote:
AFAICS with qualified identifiers we can move static variables to global scope (mangle name and set DECL_CONTEXT to 0), which should avoid the problem.
I've tried this when I did this initially. According to a note of mine, just setting DECL_CONTEXT to NULL caused some problems (I don't remember exactly which at the moment), but I think I'll have to investigate them again and try to fix them if possible. (Maybe it's because such a declaration shouldn't be in the list that the backend retrieves via getdecls() locally, rather in the global list, but that's just a guess for now ...)
Mangling the (linker) name is also an issue, but even without QI this shouldn't be a big deal (get_unique_identifier or so, since this name is only used internally, unless an explicit name attribute is given, in which case the issue doesn't arise). I'll also apply your QI patches, of course, but right now I need an AIX fix quickly.
Without mangling we have problem. With mangling (using get_unique_identifier) all test pass on i386.
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Waldek Hebisch wrote:
AFAICS with qualified identifiers we can move static variables to global scope (mangle name and set DECL_CONTEXT to 0), which should avoid the problem.
I've tried this when I did this initially. According to a note of mine, just setting DECL_CONTEXT to NULL caused some problems (I don't remember exactly which at the moment), but I think I'll have to investigate them again and try to fix them if possible. (Maybe it's because such a declaration shouldn't be in the list that the backend retrieves via getdecls() locally, rather in the global list, but that's just a guess for now ...)
Mangling the (linker) name is also an issue, but even without QI this shouldn't be a big deal (get_unique_identifier or so, since this name is only used internally, unless an explicit name attribute is given, in which case the issue doesn't arise). I'll also apply your QI patches, of course, but right now I need an AIX fix quickly.
Without mangling we have problem. With mangling (using get_unique_identifier) all test pass on i386.
Without doing anything about the getdecls() lists (current_binding_level->names)? Thanks for the information, I'll try it on AIX this weekend.
Frank
Frank Heckenbach wrote:
Waldek Hebisch wrote:
Without mangling we have problem. With mangling (using get_unique_identifier) all test pass on i386.
Without doing anything about the getdecls() lists (current_binding_level->names)? Thanks for the information, I'll try it on AIX this weekend.
I tried the following:
diff -ru gpc-20040516.orig/p/declarations.c gpc-20040516/p/declarations.c --- gpc-20040516.orig/p/declarations.c Wed May 12 02:39:11 2004 +++ gpc-20040516/p/declarations.c Thu Jul 8 13:03:15 2004 @@ -3079,8 +3079,12 @@ DECL_REGISTER (d) = !!(qualifiers & VQ_REGISTER); PASCAL_DECL_TYPED_CONST (d) = !!(qualifiers & VQ_BP_CONST); TREE_STATIC (d) = !!(qualifiers & VQ_STATIC); + if (TREE_STATIC (d)) + DECL_CONTEXT (d) = 0; if (TREE_STATIC (d) + DECL_EXTERNAL (d) + DECL_REGISTER (d) > 1) error ("multiple storage classes in variable declaration"); + { + tree assembler_name0 = 0; if (pascal_global_bindings_p ()) { TREE_PUBLIC (d) = !TREE_STATIC (d) && !DECL_REGISTER (d) && @@ -3088,10 +3092,19 @@ TREE_STATIC (d) = !DECL_EXTERNAL (d); } else - TREE_PUBLIC (d) = DECL_EXTERNAL (d); + { + TREE_PUBLIC (d) = DECL_EXTERNAL (d); + if (TREE_STATIC (d) && !assembler_name) + assembler_name0 = get_unique_identifier ("static_"); + } + DECL_COMMON (d) = !TREE_PUBLIC (d); - SET_DECL_ASSEMBLER_NAME (d, assembler_name ? check_assembler_name (assembler_name) + if (assembler_name0) + SET_DECL_ASSEMBLER_NAME (d, assembler_name0); + else + SET_DECL_ASSEMBLER_NAME (d, assembler_name ? check_assembler_name (assembler_name) : (qualifiers & VQ_EXTERNAL) ? de_capitalize (TREE_VALUE (v)) : TREE_VALUE (v)); + } pascal_decl_attributes (&d, attributes); if (DECL_EXTERNAL (d) || TREE_STATIC (d)) {
Waldek Hebisch wrote:
I tried the following:
diff -ru gpc-20040516.orig/p/declarations.c gpc-20040516/p/declarations.c --- gpc-20040516.orig/p/declarations.c Wed May 12 02:39:11 2004 +++ gpc-20040516/p/declarations.c Thu Jul 8 13:03:15 2004 @@ -3079,8 +3079,12 @@ DECL_REGISTER (d) = !!(qualifiers & VQ_REGISTER); PASCAL_DECL_TYPED_CONST (d) = !!(qualifiers & VQ_BP_CONST); TREE_STATIC (d) = !!(qualifiers & VQ_STATIC);
if (TREE_STATIC (d))DECL_CONTEXT (d) = 0;
Unfortunately, pushdecl() (further below) overrides DECL_CONTEXT, so your patch is ineffective. (Of course, you couldn't notice this, since the problem doesn't arise under Linux.)
The enclosed patch should fix it. (You can undo the previous work-around.)
There was also an obstack problem (gcc-2.x). Maybe that's what I had missed last time I tried it.
But still, consider this patch with caution. I've verified that it doesn't break under Linux/IA32 (gcc-2.8.1, 2.95.3 and 3.3.3) and DJGPP (2.8.1), and fixes the problem under AIX.
I'll test it on more systems when I get to it, but if anyone else can check that it doesn't break (and possibly fix) anything on other systems, this will be appreciated.
Frank
Frank Heckenbach wrote:
Unfortunately, pushdecl() (further below) overrides DECL_CONTEXT, so your patch is ineffective. (Of course, you couldn't notice this, since the problem doesn't arise under Linux.)
I had checked that 3.4 based cross assembler generates different output. However, in 3.4 backend does not append dots and numbers to the name if it has assembler name set, so my 3.4 patch skips setting assembler name on locals. So, probably with 3.4 it is enough to set the assembler name (as DECL_CONTEXT change was ineffective). For 3.3 I did only native test.
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Unfortunately, pushdecl() (further below) overrides DECL_CONTEXT, so your patch is ineffective. (Of course, you couldn't notice this, since the problem doesn't arise under Linux.)
I had checked that 3.4 based cross assembler generates different output. However, in 3.4 backend does not append dots and numbers to the name if it has assembler name set, so my 3.4 patch skips setting assembler name on locals. So, probably with 3.4 it is enough to set the assembler name (as DECL_CONTEXT change was ineffective).
May be. But it shouldn't hurt to set DECL_CONTEXT to NULL_TREE, should it? So it's probably better to do so, so it works with all backends (as far as tested), and describes better what we actually do.
Frank
Frank Heckenbach wrote:
Waldek Hebisch wrote:
I had checked that 3.4 based cross assembler generates different output. However, in 3.4 backend does not append dots and numbers to the name if it has assembler name set, so my 3.4 patch skips setting assembler name on locals. So, probably with 3.4 it is enough to set the assembler name (as DECL_CONTEXT change was ineffective).
May be. But it shouldn't hurt to set DECL_CONTEXT to NULL_TREE, should it? So it's probably better to do so, so it works with all backends (as far as tested), and describes better what we actually do.
Agreed. I had to modify your patch for 3.4 (the 'set_assembler_name' hunk did not apply). After that all test (except for 2 that failed before) pass on AMD64.
Frank Heckenbach wrote:
The enclosed patch should fix it. (You can undo the previous work-around.)
There was also an obstack problem (gcc-2.x). Maybe that's what I had missed last time I tried it.
But still, consider this patch with caution. I've verified that it doesn't break under Linux/IA32 (gcc-2.8.1, 2.95.3 and 3.3.3) and DJGPP (2.8.1), and fixes the problem under AIX.
I'll test it on more systems when I get to it, but if anyone else can check that it doesn't break (and possibly fix) anything on other systems, this will be appreciated.
Built the compiler and ran the testsuite. On Mac OS X, I found no problems with "gpc.diff-local-static" applied to gpc-20040516 and gcc-3.3.2. I didn't apply previously proposed AIX patches (correct me if I should have). Interestingly, AIX and Mac OS X target the same processor (athough there are ABI differences, of course).
Regards,
Adriaan van Os
Adriaan van Os wrote:
Built the compiler and ran the testsuite. On Mac OS X, I found no problems with "gpc.diff-local-static" applied to gpc-20040516 and gcc-3.3.2. I didn't apply previously proposed AIX patches (correct me if I should have).
No, you shouldn't. Thanks for the info.
Interestingly, AIX and Mac OS X target the same processor (athough there are ABI differences, of course).
Yes, it seems to have been more a problem of ABI or linker issues, probably not really related to the processor type.
Frank
Hi Frank,
On Sat, Jul 10, 2004 at 01:14:42PM +0100, Frank Heckenbach wrote:
The enclosed patch should fix it. (You can undo the previous work-around.)
[..]
But still, consider this patch with caution. I've verified that it doesn't break under Linux/IA32 (gcc-2.8.1, 2.95.3 and 3.3.3) and DJGPP (2.8.1), and fixes the problem under AIX.
I've tested your patch under AIX 5.2 today. What shall I say? "It works and doesn't break anything" - thank you very much!
Here's the output of the test suite
Test Run By gd on 2004-07-21 12:12:52 Native configuration is powerpc-ibm-aix5.2.0.0 (hilb3)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: asmtest.pas UNSUPPORTED: crttest.pas UNSUPPORTED: fjf77.pas UNSUPPORTED: gmptest.pas UNSUPPORTED: jj5.pas UNSUPPORTED: longr2.pas UNSUPPORTED: regextest.pas
=== gpc Summary ===
# of tests 3910 # of expected passes 3903 # of unsupported tests 7
/s1/gpc-build-3.3.3-20040706/gcc/xgpc version 20040516, based on gcc-3.3.3 gmake[3]: Leaving directory `/s1/gpc-build-3.3.3-20040706/gcc/p/test'
regards,
gert
-
Adriaan van Os -
Frank Heckenbach -
Gert Doering -
Waldek Hebisch