[Bug c/55105] use of LD_LIBRARY_PATH incorrect for AIX -- cause trunk build to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55105 --- Comment #1 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2012-10-30 07:58:20 UTC --- Feels like a dup of bug#52623, or vice-versa. Haven't tried --disable-build-poststage1-with-cxx recently, not sure if this still should work with current trunk.
[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392 --- Comment #14 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2012-08-30 07:33:16 UTC --- Indeed, the old buffer is freed before being copied. Yep, this isn't a regression. In fact, with 4.4.3 it was the /empty string/ having the size of 1 in the comment#0 testcase, so bug#40518 actually improved things here. However, doesn't any operation with (const _CharT*, size_type) as input parameter potentially have a problem with ( own.c_str(), own.size()+1 ) ?
[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #4 from Michael Haubenwallner michael.haubenwallner at salomon dot
at 2012-08-29 10:50:22 UTC ---
(In reply to comment #0)
Extending the testcase shows even more bad behavior in 4.4.3 and earlier:
#include string
#include cassert
int main()
{
std::string s1, s2;
s1.assign(s2.c_str(), 1);
assert( s1.size() == 1 );
std::string s3;
assert( s3.size() == 0 ); // up to gcc-4.4.3 fail here
}
[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392
--- Comment #8 from Michael Haubenwallner michael.haubenwallner at salomon dot
at 2012-08-29 15:20:50 UTC ---
Actually, valgrind does show an Invalid write of size 1 for this testcase,
unrelated to the default string at all:
{
std::string s1 = a;
s1.assign(s1.c_str(), 2);
}
So I'm proposing this fix here:
--- basic_string.tcc.orig 2012-08-29 17:12:53.349220855 +0200
+++ basic_string.tcc2012-08-29 17:13:37.021326394 +0200
@@ -262,7 +262,7 @@
{
__glibcxx_requires_string_len(__s, __n);
_M_check_length(this-size(), __n, basic_string::assign);
- if (_M_disjunct(__s) || _M_rep()-_M_is_shared())
+ if (_M_disjunct(__s) || _M_rep()-_M_is_shared() || this-size() __n)
return _M_replace_safe(size_type(0), this-size(), __s, __n);
else
{
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #37 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2012-04-16 13:29:06 UTC --- A few more references: The fix for this one issue is: https://www-304.ibm.com/support/docview.wss?uid=isg1IZ98134 But this introduces /usr/ccs/bin/as coredump during gcc bootstrap (strstream.o): https://www-304.ibm.com/support/docview.wss?uid=isg1IV01126 Just guessing, but maybe the whole thing was introduced by: https://www-304.ibm.com/support/docview.wss?uid=isg1IZ87535 Based on the filesets shown in the APARs for each AIX release/TL/SP, here's a list of maybe broken/working AIX levels, although I'm unable to verify for sure, as the broken machines got the interim fix installed here for IV01126 (supersedes interim fix for IZ98134): +--++ | broken since | fixed since | -+--++ AIX 5.3 TL9 | works | TL10 | SP6 (1107) | still broken | TL11 | SP6 (1107) | SP8 (1140) | TL12 | SP3 (1107) | SP5 (1140) | -+--++ AIX 6.1 TL2 | works | TL3 | SP9 (1112) | still broken | TL4 | SP9 (1112) | SP11 (1140) | TL5 | SP5 (1112) | SP7 (1140) | TL6 | SP4 (1112) | SP6 (1140) | TL7 | works | -+--++ AIX 7.1 TL0 | SP3 (1115) | still broken | TL1 | works | -+--++ Even if AIX 7.1 TL0 SP4 was released at 1140 too, it doesn't seem to contain IV01126 - maybe TL0 SP5 will do.
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 --- Comment #15 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2012-03-28 08:21:37 UTC --- (In reply to comment #14) Do you see any technical issue why Import Files cannot be used this way for filename-based versioning over the traditional onefile-membername-based versioning? I think that import files can be used the way you suggest. Ok, thank you! I am not sure I understand why you write that libNAME.so is broken. AIX can search for a bare shared object named libNAME.so. It isn't broken in a technical sense from AIX' point of view, it is broken in the package manager's point of view, not allowing for /any/ kind of versioning at all (neither via filename nor via archive member with F_LOADONLY flag), as well as breaking multilib. Also, I still believe that your Linux solution will require linking with -brtl or -bsvr4. Yes, and the main (because technical) reason is to keep static linking possible. This also is the reason I've named the commandline switch *able-aix-svr4 for now, but I don't have a hard opinion here, because --disable-static _would_ allow (administrative-wise) for import files even without -brtl/-bsvr4 (easiest via symlink libNAME.a - libNAME.so.1). As the name aix-svr4 implies runtime linking, maybe aix-soname is more suitable... So - what I'm still unsure is: *) how far to go with disable-static (symlink libNAME.a-libNAME.so.1), maybe upon aix-svr4=compat only? *) which name and values for the configure-switch are as obvious as possible: 1 : --enable-aix-svr4=[no | compat | yes] 1l: --enable-aix-svr4=[no | yes | only] # less forceful 2 : --enable-aix-soname=[no | compat | yes] 2l: --enable-aix-soname=[no | yes | only] # less forceful 3 : --with-aix-soname=[aix,no | both | svr4,yes] 3l: --with-aix-soname=[aix,no | both,yes | svr4] # less forceful Where less forceful means to take 'yes' to provide both (A)ix+(L)inux, needing 'only' to drop (A)ix, while the others take 'yes' to provide (L)inux _only_, needing 'compat' or 'both' to provide (A)ix too. Also, I'd like to _allow_ for package /maintainers/ to set either 'both' or 'only' (whichever name the values will have) as default value via LT_INIT (usually upon some API/SONAME bump), while still allowing for package /managers/ to override. Using above names, this would be: for (A)ix+(L)inux for (L)inux only (1 ) LT_INIT([ aix-svr4=compat ]) LT_INIT([ aix-svr4]) (1l) LT_INIT([ aix-svr4 ]) LT_INIT([ aix-svr4=only ]) (2 ) LT_INIT([ aix-soname=compat ]) LT_INIT([ aix-soname ]) (2l) LT_INIT([ aix-soname]) LT_INIT([ aix-soname=only ]) (3 ) LT_INIT([ aix-soname=both ]) LT_INIT([ aix-soname ]) (3l) LT_INIT([ aix-soname]) LT_INIT([ aix-soname=svr4 ]) More/better ideas? Thank you!
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 --- Comment #17 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2012-03-28 14:20:52 UTC --- (In reply to comment #16) Symbolic linking or hard linking libNAME.so.1 to libNAME.so doesn't work? I seem to remember something strange about the way AIX loader followed symbolic links. The real (archive) file needs to be (available as) libNAME.so.1, which is what the loader will search for. So there is no symbolic link involved at runtime, unless we also do the libNAME.so.1 - libNAME.so.1.2.3 symlink, which libtool already does for the (B)roken variant. Maybe these symlink troubles with the AIX loader are related to those .nfsXXX files seen sometimes? But still: Good to know we should not symlink libNAME.so.1 - libNAME.so.1.2.3. For versioning one can use libNAME.1.so or libNAME-1.so -- as long as .so is the file extension. This would imply to use '-lNAME.1' or '-lNAME-1' for the linker. But the linker usually gets '-lNAME', hence libNAME.so (or libNAME.a) needs to be available. However, libNAME.so may be a symlink to libNAME.so.2 already, while libNAME.so.1 is still around for binaries built when libNAME.so was a symlink to libNAME.so.1. (Isn't this what the SONAME is for at all?)
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 --- Comment #11 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2012-03-23 09:31:41 UTC --- Unless IBM does, I don't want to change any default here, nor force anyone to use -brtl. What I'm after is: Give package managers another choice how to build the packages, out of: A: libNAME.a(libNAME.so.1) (libtool default) B: libNAME.so (supported by libtool) C: libNAME.so.1(shr.o) (new) Using autoconf+libtool, the variants could be selected using: A: default (same as --disable-aix-svr4) A B : LDFLAGS=-Wl,-brtl B : LDFLAGS=-Wl,-brtl --disable-static A C: --enable-aix-svr4 C: --enable-aix-svr4 --disable-static (*able-aix-svr4 feels more correct than *able-aix-soname) For the FLOSS developers: Most of them don't care AIX (among others) at all. However, they use libtool (or something else) that allows them to not care. For XLC: There is nothing specific to GCC, Import Files work with XLC too, and I don't want to change anything within collect2 or GNU-ld - just the build-scripts (libtoolco). For multilib: I've seen package managers building a package twice, and merge both (libNAME.so.1) into libNAME.a. This works for A as well as C, but does not work for B. (In reply to comment #10) An additional problem is Binutils strip command does not support the -e/-E command line option to set F_LOADONLY. This should be fixed anyway.
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 --- Comment #12 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2012-03-23 10:29:15 UTC --- (In reply to comment #11) Give package managers another choice how to build the packages, out of: A: libNAME.a(libNAME.so.1) (libtool default) B: libNAME.so (supported by libtool) C: libNAME.so.1(shr.o) (new) Using autoconf+libtool, the variants could be selected using: A: default (same as --disable-aix-svr4) Err, aix-svr4 chooses between B or C only, so this should read: A: default A B : LDFLAGS=-Wl,-brtl B : LDFLAGS=-Wl,-brtl --disable-static A C: --enable-aix-svr4 C: --enable-aix-svr4 --disable-static
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 --- Comment #13 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2012-03-23 16:39:53 UTC --- Hmm, err, A and B aren't created at the same time by libtool. Instead, this table really should include static-only libs too: (S)tatic: libNAME.a(static.o) (A)ix:libNAME.a(libNAME.so.1) (B)roken: libNAME.so (L)inux: libNAME.so.1(shr.o) | (default:yes) | (default:yes) | (default:no) | (default:) | | enable-static | enable-shared | enable-aix-svr4 | LDFLAGS| --+--+---+---+-+--+ 1 | S: yes | no| irrelevant| irrelevant | 2 | A : yes | yes | no || 3 | S B : yes | yes | no | -brtl| 4 | B : no| yes | no | -brtl| 5 | A L : yes | yes |compat | irrelevant | 6 | S L : yes | yes | yes | irrelevant | 7 |L : no| yes | yes | irrelevant | --+--+---+---+-+--+ Besides shared and/or static, package managers would have a choice of three: 1 and 2: traditional AIX only (3 and 4: broken) 5 : SVR4 with compatibility to traditional AIX 6 and 7: SVR4 only But - first of all: Besides those administrative issues, do you see any technical issue why Import Files cannot be used this way for filename-based versioning over the traditional onefile-membername-based versioning?
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 --- Comment #6 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2012-03-22 09:10:29 UTC --- Traditionally, yes. However, there are Import Files: They can definitively help for the versioning issue, and can probably help for the multilib issue too. However, they cannot be used for static linking, so we might want to use them with the -brtl linker flag only (which would be enabled by -bsvr4 too). I'm planning to start an RFC on the gcc-ml soon...
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 --- Comment #8 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2012-03-22 20:33:01 UTC --- I'm still grafting some RFC for gcc-ml with more background info for the not-so-experienced ones, however I don't mind to discuss that here - eventually resulting in a better RFC if still needed afterwards. This is how I'm successfully using Import Files already, to provide the soname feature with runtime linking enabled: * Create the list of exported symbols from object files. but with extra weak keyword, for the import file later. * Create shr.o using -G linker flag, using that list of exported symbols. * Set F_LOADONLY on shr.o. * Create shr.imp, where first line is the soname:#! libNAME.so.1(shr.o) second line is the bitwidth: # 32 rest is list of symbols: symbol eventually flagged as weak:weak_symbol weak * Create libNAME.so.1 as archive, containing shr.o and shr.imp * Create symlink libNAME.so - libNAME.so.1 The reason I do this with -brtl only is that this variant doesn't allow to statically link shr.o any more, so I cannot create libNAME.a this way. While I do not use multilib here, the file format still allows for the AIX way of multilib, with these differences to the above for 64bit: * Create shr_64.o * Create shr_64.imp * Specify # 64 in shr_64.imp Finally, libNAME.so.1 would contain: shr.o shr.imp shr_64.o shr_64.imp The name of the archive members is just some convention to avoid confusion, AIX would allow for more than one archive member with identical name, especially if they are shared objects with different bitwidth, using the -X32 and -X64 toolchain flags. What /really/ matters is the second line in the import file to read: # 64 You're welcome to read the history on how I've sorted out this variant: http://bugs.gentoo.org/213277
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 --- Comment #3 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2012-03-21 09:38:00 UTC --- (In reply to comment #2) We should disable libquadmath on AIX. It is not needed or useful there. Have you tried adding --disable-libquadmath when configuring GCC? For --enable-languages=c,c++ only, I can bootstrap using --disable-libquadmath. Haven't tried other languages needing their own target libraries. But the problem isn't with libquadmath itself, but with config-ml.in setting LD_LIBRARY_PATH to find the multilib-wise libstdc++.a, and (interesting enough) the AIX 7.1 loader listening to LD_LIBRARY_PATH now. Consider these simple commands to trigger the configure-error in ppc64/libquadmath: $ ./gcc/xgcc xgcc: fatal error: no input files compilation terminated. $ LD_LIBRARY_PATH=`pwd`/powerpc-ibm-aix7.1.0.0/ppc64/libstdc++-v3/src/.libs ./gcc/xgcc exec(): 0509-036 Cannot load program ./gcc/xgcc because of the following errors: 0509-150 Dependent module /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/powerpc-ibm-aix7.1.0.0/ppc64/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6) could not be loaded. 0509-103 The module has an invalid magic number. Unfortunately, the AIX loader stops searching at the first matching archive filename found, even if it doesn't contain a matching shared object. However, ldd shipped with AIX 7.1 still ignores LD_LIBRARY_PATH: $ ldd ./gcc/xgcc ./gcc/xgcc needs: /usr/lib/libc.a(shr.o) /usr/lib/libiconv.a(shr4.o) /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/prev-powerpc-ibm-aix7.1.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6) /unix /usr/lib/libcrypt.a(shr.o) /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./prev-gcc/libgcc_s.a(shr.o) $ LD_LIBRARY_PATH=`pwd`/powerpc-ibm-aix7.1.0.0/ppc64/libstdc++-v3/src/.libs ldd ./gcc/xgcc ./gcc/xgcc needs: /usr/lib/libc.a(shr.o) /usr/lib/libiconv.a(shr4.o) /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/prev-powerpc-ibm-aix7.1.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6) /unix /usr/lib/libcrypt.a(shr.o) /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./prev-gcc/libgcc_s.a(shr.o)
[Bug bootstrap/47923] Errors when installing GCC 4.5.2 on AIX 6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47923 Michael Haubenwallner michael.haubenwallner at salomon dot at changed: What|Removed |Added CC||michael.haubenwallner at ||salomon dot at --- Comment #9 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2012-03-21 14:20:42 UTC --- Do you have most recent TechLevel and/or ServicePack installed? AIX 6.1 is known to break with any ServicePack since 2011 calendarweek 12 (1112) and before 2011 calendarweek 40 (1140).
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 --- Comment #4 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2012-03-21 14:27:06 UTC --- (In reply to comment #3) But the problem isn't with libquadmath itself, but with config-ml.in setting LD_LIBRARY_PATH to find the multilib-wise libstdc++.a, and (interesting enough) the AIX 7.1 loader listening to LD_LIBRARY_PATH now. This is bug#46981 actually.
[Bug bootstrap/52623] New: 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 Bug #: 52623 Summary: 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: michael.haubenwall...@salomon.at Host: powerpc-ibm-aix7.1.0.0 Target: powerpc-ibm-aix7.1.0.0 Build: powerpc-ibm-aix7.1.0.0 Created attachment 26923 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26923 Output of 'gmake bootstrap' (single job) Bootstrapping gcc-4.7.0-RC-20120314 on powerpc-ibm-aix7.1.0.0 fails because of 32bit gcc/xgcc cannot load a 64bit libstdc++.a. It works when I do configure with --disable-build-poststage1-with-cxx Prerequisites: Installed binary: gcc-4.6.2 in /opt/freeware/ from perzl.org, Self-built: gmp-5.0.1, configured with ABI=32 mpfr-3.0.0, mpc-0.8.2, Toplevel configured with --enable-languages=c,c++ 'gmake bootstrap' with single job The last lines in the output of 'gmake bootstrap' (from attached bootstrap.out.bz2): --- Adding multilib support to Makefile in /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/gcc-4.7.0-RC-20120314/libquadmath with_multisubdir=pthread Running configure in multilib subdir ppc64 pwd: /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/powerpc-ibm-aix7.1.0.0 configure: creating cache ./config.cache checking build system type... powerpc-ibm-aix7.1.0.0 checking host system type... powerpc-ibm-aix7.1.0.0 checking target system type... powerpc-ibm-aix7.1.0.0 checking for a BSD-compatible install... /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/gcc-4.7.0-RC-20120314/install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/gcc-4.7.0-RC-20120314/libquadmath/../install-sh -c -d checking for gawk... nawk checking whether gmake sets $(MAKE)... yes checking for --enable-version-specific-runtime-libs... no checking for style of include used by gmake... GNU checking for powerpc-ibm-aix7.1.0.0-gcc... /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./gcc/xgcc -B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./gcc/ -B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/bin/ -B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/lib/ -isystem /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/include -isystem /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/sys-include -maix64 checking for suffix of object files... configure: error: in `/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/powerpc-ibm-aix7.1.0.0/ppc64/libquadmath': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libquadmath] Error 1 gmake[1]: Leaving directory `/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build' gmake: *** [bootstrap] Error 2 --- The interesting lines in powerpc-ibm-aix7.1.0.0/ppc64/libquadmath/config.log (attached as powerpc-ibm-aix7.1.0.0_ppc64_libquadmath_config.log.bz2): --- configure:3239: checking for C compiler version configure:3248: /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./gcc/xgcc -B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./gcc/ -B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/bin/ -B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/lib/ -isystem /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/include -isystem /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/sys-include -maix64 --version 5 Could not load program /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./gcc/xgcc: Dependent module /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/powerpc-ibm-aix7.1.0.0/ppc64/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6) could not be loaded. The module has an invalid magic number. configure:3259: $? = 255 ---
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 --- Comment #1 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2012-03-19 17:20:23 UTC --- Created attachment 26924 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26924 powerpc-ibm-aix7.1.0.0/ppc64/libquadmath/config.log
[Bug target/46887] Invalid AIX linker flag '-bnoerok', it has to be '-bernotok'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46887 --- Comment #9 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-12-12 16:17:48 UTC --- (In reply to comment #5) The problem still exists, but classpath is maintained upstream, not by GCC. Checking out the GNU classpath project from savannah (CVS HEAD), there is neither -bnoerok nor -bernotok nor -berok inside any file, nor a file ltcf-cxx.sh at all, so where does it come from (it's still in gcc-4.7 snapshots)? Or what/where/who is classpath upstream?
[Bug other/47591] libiberty Makefile uses native cc (solaris) with option -print-multi-os-directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47591 --- Comment #2 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-09-09 15:32:53 UTC --- Created attachment 25235 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25235 output of 'gmake install' for gcc-4.6.1, using xlc v6 on aix5.3 Same here, however with gcc-4.6.1 (as well as gcc-4.5.3) on powerpc-ibm-aix5.3.0.0 (gmp configured with ABI=32). As xlc (used as cc) doesn't understand -print-multi-os-directory, it does print its manpage to stdout, passed to 'mkdir' as arguments. Luckily I've not done the 'make install' as root, otherways I would have something like a new directory /dev/null. now. So please take into account that mkdir `cc --help` gets run with AIX xlc. Thank you! BTW: Detecting CC=cc -qlanglvl=extc89 exposed another (minor) problem in the toplevel Makefile, eventually setting LDFLAGS=-Wl,-bbigtoc when using gcc as host compiler - see the first two lines in this output file for the results. However, this doesn't lead to any build error.
[Bug target/46481] long double should default to 64bit even for aix6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46481 --- Comment #2 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-07-06 11:26:37 UTC --- Seems this is fixed since gcc-4.6.0 by http://gcc.gnu.org/viewcvs?view=revisionrevision=169981.
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #31 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-05-17 07:17:57 UTC --- (In reply to comment #29) I'm now running AIX 6.1, oslevel -s returns 6100-06-03-1048 and the problem seems to persist with newer versions of gcc as well. I installed gcc 4.4.6 today after having issues trying to build GNU barcode from source. gcc -v ld: 0711-596 SEVERE ERROR: Object main.o An RLD for section 2 (.data) refers to symbol 944, but the storage class of the symbol is not C_EXT or C_HIDEXT. This most likely is bug#46072 comment#10, which is a subsequent AIX bug already known to IBM (bug#46072 comment#18).
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #26 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-05-17 14:52:36 UTC --- (In reply to comment #25) The fixed assembler is available as an efix for customers who ask. We did do this here, but the efix'ed assembler just dumps core upon some C++ construct found in strstream.cc (and others) - IBM is already aware of this.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #21 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-04-08 07:53:44 UTC --- (In reply to comment #20) mean? Does this mean IBM consider it a GCC bug? I don't find the explanations on the page too useful. The notification for this APAR also contained this text: The record has been closed. A programming error was found. The problem will be corrected. A fix is pending.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #18 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-04-07 07:59:00 UTC --- (In reply to comment #15) ld: 0711-596 SEVERE ERROR: Object expand.o An RLD for section 2 (.data) refers to symbol 852, but the storage class of the symbol is not C_EXT or C_HIDEXT. I got this when I tried to build GNU's make on 5.3 TL10 SP02 with just the assembler APAR. I tried two versions of GCC: 4.2.0 and 4.5.2. IBM is aware of the issue (via me and others). The last tidbit I have is that it appears as if it is another assembler bug but that is not confirmed yet. I don't have a fix nor do I have an APAR number yet. Looks like this one is it: https://www-304.ibm.com/support/docview.wss?uid=isg1IZ98134
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #28 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-04-01 12:24:32 UTC --- Looks like IBM fixed their Assembler to ignore invalid .line pseudo-ops again: https://www-304.ibm.com/support/docview.wss?uid=isg1IZ87535
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #11 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-03-23 07:46:49 UTC --- (In reply to comment #10) IZ81343 (or one of its sister APARs) fixes the original issue. But, it leaves a new issue. The new error looks like: Perry, have you seen this on AIX 5.3 or 6.1 ?
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #24 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-02-25 09:49:30 UTC --- (In reply to comment #23) Using your suggestion for gmake bootstrap STAGE1_FLAGS=-0 gets me much further in the build. The problem has moved to building libgomp, and the failure appears to be due to the fact that AIX nm needs nm -B to be compatible with the AIX ld. This acutally looks like bug#33637.
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #25 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-02-25 09:53:57 UTC --- Ohw, and then there is bug#47032 (caused by bug#46481) you might stumble upon in libgfortran.
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #20 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-02-24 20:42:46 UTC --- (In reply to comment #19) /usr/bin/gcc -c -g -fkeep-inline-functions -DIN_GCC ... This is a problem in /usr/bin/gcc, not in the GCC sources you're compiling. (In reply to comment #1) $ gmake bootstrap STAGE1_CFLAGS=-O Richard, does this workaround work for you?
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #6 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-02-09 09:03:05 UTC --- (In reply to comment #5) Created attachment 23120 [details] Patch to simply not use bss section with .bs, but private-data-section instead I'm going to try this patch with gcc-4.2.4 now... This patch works quite well here.
[Bug target/47032] libgfortran references complex long double functions missing on AIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47032 --- Comment #11 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-02-08 22:14:19 UTC --- (In reply to comment #10) #including math.h and then trying a link test should give correct results because it will fail to find __copysignl128 in libm While this is absolutely true, the major problem here is that gcc should not have switched to 128bit long double at all with AIX 6.1 (bug#46481). Especially not without linking against libc128.a AIX library and adding the long double bitwidth as another multilib criterion for libgcc/libstdc++/libwhatever, to allow for the 64bit long double, where all the math functions are available, and which is still the default with xlc. BTW: Using pthread as multilib criterion seems unnecessary these days...
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 Michael Haubenwallner michael.haubenwallner at salomon dot at changed: What|Removed |Added CC||michael.haubenwallner at ||salomon dot at --- Comment #3 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-01-25 08:29:49 UTC --- Same here with gcc-4.2.4 on AIX5.3 after upgrading from TL10 to TL12. (need to figure out the exact details of the problem myself yet) Which information is necessary here to help this getting fixed?
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
--- Comment #4 from Michael Haubenwallner michael.haubenwallner at salomon dot
at 2011-01-25 12:52:22 UTC ---
What exactly is the difference for gcc between not initializing a static
variable and initializing it to zero?
This is the difference in the generated assembler file:
$ cat mytest.c
static int myvar;
int main(void)
{
return myvar;
}
#if defined(IVAL)
static int myvar = IVAL;
#endif
For the compilation:
$ gcc -g mytest.c -DIVAL=0
(success)
$ gcc -g mytest.c
ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 29) in object
/tmp//cc26KLXk.o:
The symbol refers to a csect with symbol number 0, which was not
found. The new symbol cannot be associated with a csect and
is being ignored.
collect2: ld returned 12 exit status
(fail)
For the analysis:
$ gcc -g -S mytest.c -o mytestu.s
$ gcc -g -S mytest.c -o mytest0.s -DIVAL=0
$ diff -u mytestu.s mytest0.s
--- mytestu.s 2011-01-25 13:39:43.0 +0100
+++ mytest0.s 2011-01-25 13:40:01.0 +0100
@@ -42,7 +42,7 @@
.byte 31
.align 2
FE..main:
- .bs _mytest.bss_
+ .bs _mytest.rw_[RW]
.stabx myvar:S-1,myvar,133,0
.es
_section_.text:
Both gcc-4.5.1 and gcc-4.2.4 do make this difference.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #5 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-01-25 15:40:07 UTC --- Created attachment 23120 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23120 Patch to simply not use bss section with .bs, but private-data-section instead I'm going to try this patch with gcc-4.2.4 now...
[Bug target/47032] libgfortran references complex long double functions missing on AIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47032 Michael Haubenwallner michael.haubenwallner at salomon dot at changed: What|Removed |Added CC||michael.haubenwallner at ||salomon dot at --- Comment #6 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-01-25 19:56:14 UTC --- This looks like a dupe of bug#46481.
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #14 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2010-12-13 12:46:25 UTC --- (In reply to comment #9) Is the 64K limit really new? Is this really a change in AIX as or did something else change and start generating files referencing line numbers larger than 64K? I believe the line number field in XCOFF is defined in /usr/include/linenum.h. According to that file, in 32 bit mode, line numbers are represented by an unsigned short, whose maximum value is 65535. In 64 bit mode, line numbers are represented by unsigned int. I have not seen this error while bootstrapping GCC on AIX. The error looks correct. What else changed? Update from IBM customer support: Pseudo operation '.line' works as designed. However, the bounds checking was introduced in AIX 6.1 TL04 SP07 and similar SP's for other TL's.
[Bug target/46887] Invalid AIX linker flag '-bnoerok', it has to be '-bernotok'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46887 --- Comment #2 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2010-12-13 22:18:57 UTC --- It did hit me in gcc-4.2.4 (languages=c,c++) in Gentoo Prefix on AIX, where I do have some automagic patches to enable runtime linking by default as well as full soname support (still to be sorted out with libtool upstream). So I'm unable to hit this problem with vanilla gcc-4.2.4, even not with LDFLAGS=-Wl,-brtl for unknown reason. For gcc-trunk, I've just searched the sources for 'bnoerok' and still found it, although I'm unsure if this would hit me whenever I start using gcc-java. If this code is old and unused, I'm fine with its removal during normal development.
[Bug target/46887] New: Invalid AIX linker flag '-bnoerok', it has to be '-bernotok'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46887
Summary: Invalid AIX linker flag '-bnoerok', it has to be
'-bernotok'
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michael.haubenwall...@salomon.at
The AIX linker does not understand '-bnoerok', but '-bernotok'.
While there have been more occurences in older releases, there is still one in
current trunk:
libjava/classpath/ltcf-cxx.sh:no_undefined_flag=' ${wl}-bnoerok'
This has to be -bernotok.
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #10 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2010-11-30 12:22:43 UTC --- (In reply to comment #9) I believe the line number field in XCOFF is defined in /usr/include/linenum.h. According to that file, in 32 bit mode, line numbers are represented by an unsigned short, whose maximum value is 65535. In 64 bit mode, line numbers are represented by unsigned int. Ohw, indeed. Is the 64K limit really new? Is this really a change in AIX as or did something else change and start generating files referencing line numbers larger than 64K? AFAICS, AIX as changed somewhere around SP6100-04-07-1036 so that it actually does check the 64k limit (as well as the zero limit) now. On AIX5.3, linenum.h also declares l_lnno as unsigned short in 32bit, but the assembler does not choke on any line in test.s from comment#3 there. I have not seen this error while bootstrapping GCC on AIX. The error looks correct. What else changed? Before installing SP6100-04-07-1036 I've also been able to bootstrap gcc-4.2.4 without any problems using AIX as/ld. But this is broken since SP6100-04-07-1036 is installed. However - as a side note, applying attachment#22583 to gcc-4.2.4 breaks bootstrapping gcc-4.2.4 even on AIX 5.3 (which doesn't choke on .line =0 or =64k) both with and without STAGE1_CFLAGS=-O (to not trigger this problem in the gcc used to bootstrap) with 'Bootstrap comparison failure' due to different .line numbers in stage 2 and 3.
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 Michael Haubenwallner michael.haubenwallner at salomon dot at changed: What|Removed |Added Attachment #22538|0 |1 is obsolete|| --- Comment #11 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2010-11-30 15:22:36 UTC --- Created attachment 22580 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22580 emit unsigned .line values 0, and 64k in 32bit mode Based on comment#9 this patch now emits the line number: * as unsigned int (%u), * when 0, * when 64k (=USHRT_MAX) in 32bit mode. However, I still do think filtering for line0 here is a workaround, as invalid line numbers shouldn't reach the emit-function at all. (In reply to comment #10) applying attachment#22583 to gcc-4.2.4 breaks bootstrapping gcc-4.2.4 This was because variable 'line' got hidden in that patch.
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #6 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2010-11-29 09:05:53 UTC --- I'm in contact with IBM vi a customer's support channel - initially for another problem, and have added this 64k-line-limit recently. Although no reply yet, I'll add updates here when available.
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #4 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2010-11-26 13:54:41 UTC --- Created attachment 22538 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22538 Workaround to emit .line values 0 and 64k only For now, I'm using this patch to get the debug-info working good enough for me. However, I don't believe this is the proper fix.
[Bug target/46481] long double should default to 64bit even for aix6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46481 Michael Haubenwallner michael.haubenwallner at salomon dot at changed: What|Removed |Added Target||powerpc-ibm-aix6.1.0.0 Version|4.2.4 |4.5.1 Depends on||19115 --- Comment #1 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2010-11-26 15:41:40 UTC --- This is the same problem for any version since gcc-4.2.4.
[Bug target/46655] New: AIX6.1 native assembler requires '.line' numbers greater than zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 Summary: AIX6.1 native assembler requires '.line' numbers greater than zero Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: michael.haubenwall...@salomon.at Bootstrapping gcc-4.5.1 on AIX6.1 with recent native assembler fails with: /build/gcc/./gcc/xgcc -B/build/gcc/./gcc/ -B/install/powerpc-ibm-aix6.1.0.0/bin/ -B/install/powerpc-ibm-aix6.1.0.0/lib/ -isystem /install/powerpc-ibm-aix6.1.0.0/include -isystem /install/powerpc-ibm-aix6.1.0.0/sys-include-g -O2 -pthread -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -mlong-double-128 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../.././gcc -I/source/gcc-4.5.1/libgcc -I/source/gcc-4.5.1/libgcc/. -I/source/gcc-4.5.1/libgcc/../gcc -I/source/gcc-4.5.1/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _mul_sf.o -MT _mul_sf.o -MD -MP -MF _mul_sf.dep -DFINE_GRAINED_LIBRARIES -DL_mul_sf -c ../../.././gcc/fp-bit.c Assembler: /tmp//ccI8aKR8.s: line 160: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. gmake[5]: *** [_mul_sf.o] Error 1 gmake[5]: Leaving directory `/build/gcc/powerpc-ibm-aix6.1.0.0/pthread/libgcc' gmake[4]: *** [multi-do] Error 1 gmake[4]: Leaving directory `/build/gcc/powerpc-ibm-aix6.1.0.0/libgcc' gmake[3]: *** [all-multi] Error 2 gmake[3]: Leaving directory `/build/gcc/powerpc-ibm-aix6.1.0.0/libgcc' gmake[2]: *** [all-stage1-target-libgcc] Error 2 gmake[2]: Leaving directory `/build/gcc' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/build/gcc' gmake: *** [bootstrap] Error 2 Running that xgcc command with -save-temps -v tells: /build/gcc/./gcc/as -u -mppc -o _mul_sf.o fp-bit.s Assembler: fp-bit.s: line 160: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. The line 160 in fp-bit.s is: 160.line 0 Although this was accepted before installing AIX patch SP6100-04-07-1036, it is questionable what a line-number zero is for. Also I've found this old message: http://gcc.gnu.org/ml/gcc-bugs/1999-12/msg00088.html
[Bug target/46655] AIX6.1 native assembler requires '.line' numbers greater than zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
Michael Haubenwallner michael.haubenwallner at salomon dot at changed:
What|Removed |Added
Target||powerpc-ibm-aix6.1.0.0
Host||powerpc-ibm-aix6.1.0.0
Known to fail||4.2.4
Build||powerpc-ibm-aix6.1.0.0
--- Comment #1 from Michael Haubenwallner michael.haubenwallner at salomon dot
at 2010-11-25 10:17:31 UTC ---
The configure arguments used were:
$ /source/gcc-4.5.1.pr46655/configure --{prefix,with-{gmp,mpfr,mpc}}=/install
As the bootstrap compiler gcc-4.2.0 from AIX Toolbox for Linux Applications
has the same problem, and this is debug-info only, '-O' was used as workaround:
$ gmake bootstrap STAGE1_CFLAGS=-O
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #3 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2010-11-25 12:30:37 UTC --- Huh - AIX-as also doesn't accept line numbers =65536 any more since SP6100-04-07-1036 it seems, as I get an error on .line 118674 from insn-automata.c later in bootstrap of gcc-4.5.1, after modifying gcc/xcoffout.c to emit line numbers 0 only. For reference: $ cat test.s .line 1 .line -1 # invalid: ok .line 0 # invalid: ok .line 65536 # invalid: huh? .line 65535 $ /usr/bin/as -u -mppc test.s Assembler: test.s: line 2: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. test.s: line 3: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. test.s: line 4: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. While line numbers =0 is this one gcc bug, IMO not accepting line numbers =64k is an AIX-as bug.
[Bug bootstrap/38546] configure: too many arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38546 Michael Haubenwallner michael.haubenwallner at salomon dot at changed: What|Removed |Added CC||michael.haubenwallner at ||salomon dot at --- Comment #2 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2010-11-24 16:34:48 UTC --- dup of bug#33637
[Bug target/46481] New: long double should default to 64bit even for aix6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46481 Summary: long double should default to 64bit even for aix6.1 Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: michael.haubenwall...@salomon.at For AIX6.1, long double was changed from 64 to 128bit by default since gcc-4.2.4 as of bug#19115. It seems the reason to do so was because frexpl() in libc.a expects 128bit. But this is a known bug in libc.a, and thus should not be the reason to switch to 128bit by default. There is a static 64bit frexpl() replacement in math.h (attachment#15004, bug#34794 comment#5) to work around this bug: /* * frexpl(), ldexpl(), and modfl() have preexisting shared versions which are * 128-bit only. 64-bit versions must be made available for C99 for the * default 64-bit long double. These cannot simply be macros because the * actual routines will be the incorrect form in 64-bit mode if the user * forces the actual routines to be used through undef or macro suppression * per the standard. */ So the proper fix for bug#19115 would have been to use the working replacement of frexpl() in libstdc++ - but AFAICS this is not a problem any more. Another reason: Passing a 128bit long double to printf(%Lf) breaks subsequent (at least) arguments when not linked against libc128.a. The manpage printf(3) on AIX says: Library Standard C Library (libc.a) or the Standard C Library with 128-Bit long doubles (libc128.a) as well as: *An optional L specifying that a following e, E, f, g, or G conversion specifier applies to a long double parameter. If linked with libc.a, long double is the same as double (64bits). If linked with libc128.a and libc.a, long double is 128 bits. Also, there is another important comment in math.h: /* * The following interfaces are available only for the * non-default 128-bit long double mode. By default long * double is the same as double (64-bit) and should use the * the double precision versions of these routines. * * Many of these routine may not actually exist. The standards interfaces * are redefined in 128-mode later in this file. The redefinitions are * are added here to cause link errors rather than runtime errors * when attempting to use these routines in 128-bit long double mode. * Without these redefinitions the 64-bit versions in the libraries * would be invoked at runtime. */ So for now, I'd say 128bit long double support is still incomplete with gcc (if not with aix at all). Thank you!
