[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #268 from The Written Word --- (In reply to Larkin Nickle from comment #262) > Created attachment 51182 [details] > GCC 11.1 patch to net dwarf2 debugging symbols > > Rebuilding with this patch. Should hopefully net me actual dwarf2 debug > symbols. What if you use the GCC --gdwarf-2 option instead of this patch? Does the patch just set the default DWARF version? Seems like if GCC supports DWARF >2, --gdwarf-2 should generate just v2 DWARF info.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #267 from The Written Word --- (In reply to Larkin Nickle from comment #266) > I'll try that 7.9.1 as a last resort; I noticed that 7.3.1 was able to read > dwarf4 symbols from a previous 4.9.2 build I did so I'm testing building > 11.1 patched to produce debug symbols similarly. 7.9.1 was the last version that had support for HP-UX.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #265 from The Written Word --- (In reply to Larkin Nickle from comment #264) > Oh, and I should mention this is what I get with 7.3.1 or 7.5.1: > > Reading symbols from > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1...BFD: > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1 symbol > number 7214 references nonexistent SHT_SYMTAB_SHNDX section > Can't read symbols from > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1: File in > wrong format There's a GDB 7.9.1 at http://hpux.connect.org.uk/hppd/hpux/Gnu/gdb-7.9.1/. Does it work better?
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #253 from The Written Word --- (In reply to The Written Word from comment #245) > (In reply to John Buddery from comment #238) > > Was your 11.1 build successful ? > > Our rebuild of 11.1.0 completed successfully. I haven't tested it though. I > am going to try earlier GCC releases and build on 11.23/IA as well. A build on 11.23/IA worked using similar patches to 11.31/IA.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #252 from The Written Word --- (In reply to Larkin Nickle from comment #249) > Then, if libcpp's Makefile is patched so that charset.c is built with -O1, I > eventually run into other errors: > > ../../../../sources/gcc-11.1.0-new/libgcc/libgcov-interface.c: In function > 'gcov_clear': > ../../../../sources/gcc-11.1.0-new/libgcc/libgcov-interface.c:143:1: > internal compiler error: Illegal instruction > 143 | } > | ^ > libbacktrace could not find executable to open I tried building 10.3.0 using the same patches as in 11.1.0 and ran into the above for the 10.3.0 build.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #248 from The Written Word --- (In reply to John Buddery from comment #247) > For clarification, I assume this is using the HP aCC compiler for binutils > etc., rather than the bundled /usr/ccs/bin cc ? Correct.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #246 from The Written Word --- Created attachment 51163 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51163=edit Build script and patches Build script for zlib, gmp, mpfr, mpc, binutils 2.25.1, 2.30, 2.32, and GCC 4.4.6, 4.6.4, 4.7.4, 4.8.5, 4.9.5, and 11.1.0. Build instructions for GCC 9.4.0 and 10.3.0 included but not tested yet. Patches for all of the above included as well. Work-in-progress.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #245 from The Written Word --- (In reply to John Buddery from comment #238) > Was your 11.1 build successful ? Our rebuild of 11.1.0 completed successfully. I haven't tested it though. I am going to try earlier GCC releases and build on 11.23/IA as well.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #243 from The Written Word --- (In reply to John Buddery from comment #238) > It seems binutils 2.32 and earlier works fine in 32 bit mode, but 2.33.1 and > later require a 64 bit build for 64 bit objects to work reliably. I can build up to and including 2.32 with the HP C compiler. Starting with 2.33.1, they add -std=gnu99. Might be possible to fix this but I might retry with 2.32.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #241 from The Written Word --- (In reply to John Buddery from comment #240) > One question about PR66319 - it's marked as resolved, so is this committed > as a patch in the trunk ? It's resolved for HP-UX/PA but my HP-UX/IA patch was never committed.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #239 from The Written Word --- (In reply to John Buddery from comment #238) > Thanks, I'll give it a go. > > It seems binutils 2.32 and earlier works fine in 32 bit mode, but 2.33.1 and > later require a 64 bit build for 64 bit objects to work reliably. > > Was your 11.1 build successful ? Ran out of disk space so had to restart :(
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #237 from The Written Word --- (In reply to John Buddery from comment #228) > gcov-tool.c avoids build errors from ftwbuf differences on HP, apply if you > hit errors but may need tidying up. Instead of this patch, try the patch for PR66319 instead.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #236 from The Written Word --- (In reply to John Buddery from comment #235) > Interesting - that's with a 32 bit gas? $ file bin/gcc111/ia64-hp-hpux11.31/bin/as bin/gcc111/ia64-hp-hpux11.31/bin/as:ELF-32 executable object file - IA64 $% bin/gcc111/ia64-hp-hpux11.31/bin/as --version GNU assembler (GNU Binutils) 2.30 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `ia64-hp-hpux11.31'. > It could be a change between 2.30 and 2.36 I guess, I might see if I can > narrow it down. We prefer to build with HP C and only use GCC when we must. 2.36 didn't build as easily out-of-the-box with HP C and we haven't tried to fix it so we've stuck with 2.30 for newer GCC releases.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #234 from The Written Word --- (In reply to John Buddery from comment #233) > One additional note - when building the patched binutils 2.36, it must be > built as 64 bit executables. > > It seems that a 32 bit gas does not produce 64 bit object files properly on > this platform, causing the linker to crash when making the 64 bit > libstdc++.so. > > Build binutils as 64 bit, by using a configure something like: > > CFLAGS="-O2 -mlp64" ./configure -prefix=/usr/local Odd. We currently have a build of 11.1.0 going with as from binutils-2.30 built using the HP C compiler and: $ file ./.o/prev-ia64-hp-hpux11.31/libstdc++-v3/src/.libs/libstdc++.so ./.o/prev-ia64-hp-hpux11.31/hpux64/libstdc++-v3/src/.libs/libstdc++.so ./.o/prev-ia64-hp-hpux11.31/libstdc++-v3/src/.libs/libstdc++.so:ELF-32 shared object file - IA64 ./.o/prev-ia64-hp-hpux11.31/hpux64/libstdc++-v3/src/.libs/libstdc++.so: ELF-64 shared object file - IA64
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #231 from The Written Word --- (In reply to John Buddery from comment #228) > These patches are for 11.1.0, but should work on earlier versions too. With > this I have a working gcc which I've tested on several large projects. You don't #undef MAKE_DECL_ONE_ONLY in gcc/config/ia64/hpux.h? If you skip it, do you skip it on earlier GCC builds as well?
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #150 from The Written Word --- (In reply to Peter Bisroev from comment #149) > (In reply to The Written Word from comment #148) > > (In reply to The Written Word from comment #144) > > > We have a build running that seems to be going well. We are using > > > gcc-4.9.4 > > > to build 8.3.0. I will attach the current patch set we are building > > > against. > > > > We're running into the same issues as encountered in comment#74. I think > > this is because of our patch to address PR66319 so I am attempting a build > > without it. We will then probably run into the problem in comment#76 but > > I'll try to fix that manually and continue the build. > > Did you build your 4.9.4 or you are using a pre-built one? I am trying to > build 4.9.4 using my 4.7.4 but at the end of stage1 I get > -- > conftest.c:15:3: internal compiler error: Illegal instruction > -- > This is a similar error as described in comment#21. We built 4.9.4. Try 4.9.3 and you might have more success. On 4.9.4, you need to look at PR60465. I think comment#63 here also provides a workaround but we chose to revert the commit that caused the problem.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #148 from The Written Word --- (In reply to The Written Word from comment #144) > We have a build running that seems to be going well. We are using gcc-4.9.4 > to build 8.3.0. I will attach the current patch set we are building against. We're running into the same issues as encountered in comment#74. I think this is because of our patch to address PR66319 so I am attempting a build without it. We will then probably run into the problem in comment#76 but I'll try to fix that manually and continue the build.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #146 from The Written Word --- (In reply to The Written Word from comment #142) > (In reply to Peter Bisroev from comment #133) > > The tests are from are binutils-2.32. > > > > - gas.log > > FAIL: .file file names > > FAIL: .file file names ordering > > FAIL: .equ redefinitions (ELF) > > FAIL: .set with expression > > FAIL: good .bss / .struct data allocation directives > > FAIL: gas/elf/missing-build-notes > > FAIL: ia64 xdata (ilp32) > > FAIL: ia64 unwind descriptors > > > > - binutils.log (they look like gas related failures) > > FAIL: assembler generated build notes > > FAIL: --localize-hidden test 1 > > FAIL: readelf -S bintest > > > > Are any of these tests critical and would you want me to look at them in > > more detail? > > I get the same test failures with binutils-2.32. For binutils-2.25.1, test failures are: $ grep FAIL gas.log FAIL: .file file names FAIL: .equ redefinitions (ELF) FAIL: .set with expression FAIL: ia64 psn FAIL: ia64 xdata (ilp32) FAIL: ia64 unwind descriptors FAIL: lns-duplicate FAIL: lns-common-1 For binutils-2.26, test failures are: $ grep FAIL gas.log FAIL: .file file names FAIL: .equ redefinitions (ELF) FAIL: .set with expression FAIL: ia64 unwind descriptors FAIL: lns-duplicate FAIL: lns-common-1
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 The Written Word changed: What|Removed |Added Attachment #46623|0 |1 is obsolete|| --- Comment #145 from The Written Word --- Created attachment 47799 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47799=edit gcc-8.3.0 patches v2 v2 of our patch set.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #144 from The Written Word --- (In reply to Peter Bisroev from comment #135) > I just had a chance to do some testing tonight. So attempting to bootstrap > 8.3.0 in stock configuration gives PCREL21B style errors in stage1 as have > been shown before. If I compile stage1 with '-O2' only, stage1 compiles, but > straight away we get > -- > /home/pbisroev/src/build/./gcc/xgcc -B/home/pbisroev/src/build/./gcc/ -xc > -nostdinc /dev/null -S -o /dev/null > -fself-test=/home/pbisroev/src/gcc-8.3.0/gcc/testsuite/selftests > cc1: internal compiler error: Segmentation fault > -- This succeeds with our gcc-8.3.0 build: $ /opt/build/china/gcc-8.3.0/.obj/prev-gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj/prev-gcc -xc -nostdinc /dev/null -S -o /dev/null -fself-test=/opt/build/china/gcc-8.3.0/gcc/testsuite/selftests -fself-test: 40028 pass(es) in 1.02 seconds We have a build running that seems to be going well. We are using gcc-4.9.4 to build 8.3.0. I will attach the current patch set we are building against.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #143 from The Written Word --- (In reply to Peter Bisroev from comment #131) > ... > > After a bit of digging around looks > like my ar and ranlib binaries from binutils are not working properly. For > example: > > $ ./ar --help > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylsp' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyolsp' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyfnd' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextuc' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylenguc' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextarr' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylstate' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyprevious' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyextra' in load module > '/usr/lib/hpux32/libl.so.1'. > Killed > > But those symbols are present in libl.so from what I can see. For now I am > still using HP's ar and ranlib, will take a look into what is going on with > binutils ar and ranlib a bit later. We solve this by setting LEXLIB in the environment to a static verison of the flex library. You could probably also set LEXLIB="-L -Wl,+b, -lfl".
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #142 from The Written Word --- (In reply to Peter Bisroev from comment #133) > The tests are from are binutils-2.32. > > - gas.log > FAIL: .file file names > FAIL: .file file names ordering > FAIL: .equ redefinitions (ELF) > FAIL: .set with expression > FAIL: good .bss / .struct data allocation directives > FAIL: gas/elf/missing-build-notes > FAIL: ia64 xdata (ilp32) > FAIL: ia64 unwind descriptors > > - binutils.log (they look like gas related failures) > FAIL: assembler generated build notes > FAIL: --localize-hidden test 1 > FAIL: readelf -S bintest > > Are any of these tests critical and would you want me to look at them in > more detail? I get the same test failures with binutils-2.32.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #99 from The Written Word --- (In reply to C. Heide from comment #98) > (In reply to The Written Word from comment #97) > > (In reply to C. Heide from comment #73) > > > With that change, and some other cajoling (the previously mentioned > > > duplicate symbols and operand64 problem, and -O1 to work around the ICE), > > > I > > > can now get gcc-8.3 to do a full bootstrap on HP-UX 11.23 ia64. > > > > No issues with PCH or libsupc++ like I'm seeing? > > No, but the only "working" build I've had so far was with the "#undef > MAKE_DECL_ONE_ONLY" hack and had the duplicate symbol problem. If I remove > that hack as recommended, I then get a segfault ICE even earlier than you > do, where the stage 2 compiler seems completely broken and crashes even on a > single empty function (haven't been able to do much with that yet). What linker patch do you have installed?
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #97 from The Written Word --- (In reply to C. Heide from comment #73) > With that change, and some other cajoling (the previously mentioned > duplicate symbols and operand64 problem, and -O1 to work around the ICE), I > can now get gcc-8.3 to do a full bootstrap on HP-UX 11.23 ia64. No issues with PCH or libsupc++ like I'm seeing?
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #96 from The Written Word --- (In reply to dave.anglin from comment #91) > On 2019-07-23 5:53 p.m., bugzilla-gcc at thewrittenword dot com wrote: > > In file included from > > /opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/cmath:43, > > from > > /opt/build/china/gcc-8.3.0/libstdc++-v3/include/precompiled/stdc++.h:41: > > /opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/ext/type_traits.h:103:34: > > internal compiler error: Segmentation fault > > struct __add_unsigned; > > ^ > Disable precompiled headers for now. This will make it easier to find > problems. Thanks. That worked. But the build failed again, with what looks like a similar segfault: libtool: compile: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -shared-libgcc -B/opt/build/china/gcc-8.3.0/.obj/./gcc -nostdinc++ -L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/src -L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/src/.libs -L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/libsupc++/.libs -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include -I/opt/build/china/gcc-8.3.0/libstdc++-v3/../libgcc -I/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/ia64-hp-hpux11.31 -I/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include -I/opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=atexit_thread.lo -g -O2 -c /opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++/atexit_thread.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o atexit_thread.o cc1plus: warning: -Wabi won't warn about anything [-Wabi] cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, which is also used by default cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7 In file included from /opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/bits/move.h:55, from /opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/bits/nested_exception.h:40, from /opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++/exception:144, from /opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++/new:40, from /opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++/atexit_thread.cc:26: /opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:363:36: internal compiler error: Segmentation fault struct __is_pointer_helper<_Tp*> ^
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #95 from The Written Word --- (In reply to dave.anglin from comment #92) > On 2019-07-23 5:48 p.m., bugzilla-gcc at thewrittenword dot com wrote: > > Yeah, we had PR64919 applied and backed out only the "#undef > > MAKE_DECL_ONE_ONLY" to work around the duplicate symbols error. We also have > > fixes for PR60465, PR64919, PR66319, PR85412, PR87338, PR90714, r214747, and > > Debian's ia64-disable-selective-scheduling.patch applied, in addition to > > some > > local -O2=>-O0 workarounds. > Maybe you could upload your full patch set so others can see details. Done.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #94 from The Written Word --- Created attachment 46623 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46623=edit gcc-8.3.0 patches Patches currently being used to build gcc-8.3.0 on HP-UX/IA
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #88 from The Written Word --- (In reply to The Written Word from comment #78) > (In reply to dave.anglin from comment #77) > > > > I think you need to define _XOPEN_SOURCE_EXTENDED. See for example > > config/pa/pa-hpux11.h. > > Yep. I forgot about PR66319. Ok, that fixed the nftw issue. Anyone encounter this: gmake[5]: Entering directory `/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include' mkdir -p ./ia64-hp-hpux11.31/bits/stdc++.h.gch /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -shared-libgcc -B/opt/build/china/gcc-8.3.0/.obj/./gcc -nostdinc++ -L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/src -L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/src/.libs -L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/libsupc++/.libs -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-x c++-header -nostdinc++ -g -O2 -I/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/ia64-hp-hpux11.31 -I/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include -I/opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /opt/build/china/gcc-8.3.0/libstdc++-v3/include/precompiled/stdc++.h \ -o ia64-hp-hpux11.31/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/cmath:43, from /opt/build/china/gcc-8.3.0/libstdc++-v3/include/precompiled/stdc++.h:41: /opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/ext/type_traits.h:103:34: internal compiler error: Segmentation fault struct __add_unsigned; ^
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #87 from The Written Word --- (In reply to EML from comment #80) > During stage0 - MPFR will ICE in GCC4.9.3 due to TLS. You need to go into > the MPFR directory and re-run the same configure line from config.log, but > add --disable-thread-safe. We haven't had any issues with MPFR. We're using 3.1.6 built with the HP C compiler.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #86 from The Written Word --- (In reply to C. Heide from comment #79) > (In reply to The Written Word from comment #75) > > > > I think a local patch might be doing this. Rebuild without it. > > I did have some other patches applied from other PRs, from previous > desperate attempts to get anything working, including PR90714, PR85412, > PR87338, and tips from PR64919. > > I'm doing some more testing with combinations of them, and so far I've found > that if I start from a fresh 8.3 and apply only the essential ones, the fix > here, the operand64 removal, the nftw workaround, and -O1 to work around the > stage 2 ICE, I don't get the duplicate symbols but the compiler segfaults in > libgcc configure tests in stage 2. > > If I add the '#undef MAKE_DECL_ONE_ONLY' fix from PR64919 (is it even still > relevant? It does seem to be for the stage 2 libgcc segfault symptom I > see.), I start getting the duplicate symbols in stage 1 libstdc++. Yeah, we had PR64919 applied and backed out only the "#undef MAKE_DECL_ONE_ONLY" to work around the duplicate symbols error. We also have fixes for PR60465, PR64919, PR66319, PR85412, PR87338, PR90714, r214747, and Debian's ia64-disable-selective-scheduling.patch applied, in addition to some local -O2=>-O0 workarounds.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #78 from The Written Word --- (In reply to dave.anglin from comment #77) > > I think you need to define _XOPEN_SOURCE_EXTENDED. See for example > config/pa/pa-hpux11.h. Yep. I forgot about PR66319.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #76 from The Written Word --- (In reply to The Written Word from comment #75) > (In reply to The Written Word from comment #74) > > > > I'm getting further in the build on HP-UX 11.31/IA but when linking > > libstdc++.la, I get lots of: > > ld: Duplicate symbol "typeinfo for __gnu_cxx::__concurrence_unlock_error" in > > files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and > > .libs/libstdc++.lax/libsupc++convenience.a/guard.o > > ld: Duplicate symbol "typeinfo for __gnu_cxx::__concurrence_lock_error" in > > files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and > > .libs/libstdc++.lax/libsupc++convenience.a/guard.o > > ld: Duplicate symbol "typeinfo name for __gnu_cxx::__concurrence_lock_error" > > in files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and > > .libs/libstdc++.lax/libsupc++convenience.a/guard.o > > ... > > I think a local patch might be doing this. Rebuild without it. Getting further. Now erroring out with: /opt/build/china/gcc-8.3.0/.obj/./prev-gcc/xg++ -B/opt/build/china/gcc-8.3.0/.obj/./prev-gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -nostdinc++ -B/opt/build/china/gcc-8.3.0/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/src/.libs -B/opt/build/china/gcc-8.3.0/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/libsupc++/.libs -I/opt/build/china/gcc-8.3.0/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/include/ia64-hp-hpux11.31 -I/opt/build/china/gcc-8.3.0/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/include -I/opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++ -L/opt/build/china/gcc-8.3.0/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/src/.libs -L/opt/build/china/gcc-8.3.0/.obj/prev-ia64-hp-hpux11.31/libstdc++-v3/libsupc++/.libs -fno-PIE -c -DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/opt/build/china/gcc-8.3.0/gcc -I/opt/build/china/gcc-8.3.0/gcc/. -I/opt/build/china/gcc-8.3.0/gcc/../include -I./../intl -I/opt/build/china/gcc-8.3.0/gcc/../libcpp/include -I/opt/TWWfsw/libgmp61/include -I/opt/TWWfsw/libmpfr31/include -I/opt/TWWfsw/libmpc10/include -I/opt/build/china/gcc-8.3.0/gcc/../libdecnumber -I/opt/build/china/gcc-8.3.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/opt/build/china/gcc-8.3.0/gcc/../libbacktrace -I/opt/TWWfsw/libisl016/include -o gcov-tool.o -MT gcov-tool.o -MMD -MP -MF ./.deps/gcov-tool.TPo /opt/build/china/gcc-8.3.0/gcc/gcov-tool.c /opt/build/china/gcc-8.3.0/gcc/gcov-tool.c: In function 'int unlink_profile_dir(const char*)': /opt/build/china/gcc-8.3.0/gcc/gcov-tool.c:85:23: error: invalid conversion from 'int (*)(const char*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)' [-fpermissive] return nftw(path, unlink_gcda_file, 64, FTW_DEPTH | FTW_PHYS); ^~~~ In file included from /opt/build/china/gcc-8.3.0/gcc/gcov-tool.c:39: /usr/include/ftw.h:273:38: note: initializing argument 2 of 'int nftw(const char*, int (*)(const char*, const stat*, int, FTW), int, int)' inline int nftw(const char *a,int (*b)(const char *, const struct ~~^ stat *, int, struct FTW), int c, int d) gmake[3]: *** [gcov-tool.o] Error 1
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #75 from The Written Word --- (In reply to The Written Word from comment #74) > (In reply to C. Heide from comment #73) > > With that change, and some other cajoling (the previously mentioned > > duplicate symbols and operand64 problem, and -O1 to work around the ICE), I > > can now get gcc-8.3 to do a full bootstrap on HP-UX 11.23 ia64. > > > > I haven't run the GCC testsuite yet, but it was able to build an internal > > C++ app and pass its unit tests, though it did still need the duplicate > > symbol workaround when linking (added -Wl,+allowdups). > > I'm getting further in the build on HP-UX 11.31/IA but when linking > libstdc++.la, I get lots of: > ld: Duplicate symbol "typeinfo for __gnu_cxx::__concurrence_unlock_error" in > files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and > .libs/libstdc++.lax/libsupc++convenience.a/guard.o > ld: Duplicate symbol "typeinfo for __gnu_cxx::__concurrence_lock_error" in > files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and > .libs/libstdc++.lax/libsupc++convenience.a/guard.o > ld: Duplicate symbol "typeinfo name for __gnu_cxx::__concurrence_lock_error" > in files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and > .libs/libstdc++.lax/libsupc++convenience.a/guard.o > ... I think a local patch might be doing this. Rebuild without it.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #74 from The Written Word --- (In reply to C. Heide from comment #73) > With that change, and some other cajoling (the previously mentioned > duplicate symbols and operand64 problem, and -O1 to work around the ICE), I > can now get gcc-8.3 to do a full bootstrap on HP-UX 11.23 ia64. > > I haven't run the GCC testsuite yet, but it was able to build an internal > C++ app and pass its unit tests, though it did still need the duplicate > symbol workaround when linking (added -Wl,+allowdups). I'm getting further in the build on HP-UX 11.31/IA but when linking libstdc++.la, I get lots of: ld: Duplicate symbol "typeinfo for __gnu_cxx::__concurrence_unlock_error" in files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and .libs/libstdc++.lax/libsupc++convenience.a/guard.o ld: Duplicate symbol "typeinfo for __gnu_cxx::__concurrence_lock_error" in files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and .libs/libstdc++.lax/libsupc++convenience.a/guard.o ld: Duplicate symbol "typeinfo name for __gnu_cxx::__concurrence_lock_error" in files .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o and .libs/libstdc++.lax/libsupc++convenience.a/guard.o ...
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #54 from The Written Word --- (In reply to EML from comment #52) > objdump -h -s foo > Contents of section .rodata: > 40007f8 48656c6c 6f732057 6f726c64 00Hellos World. > > > So gcc 4.9.x also puts the string into rodata? > > (Not sure I'm reading all the files correctly, so perhaps I'm just reading > it all wrong) I'm seeing the string in .rodata as well regardless of compiler version: $ gobjdump -h -s -j .rodata a.out a.out: file format elf32-ia64-hpux-big Sections: Idx Name Size VMA LMA File off Algn 10 .rodata 000d 040007c8 040007c8 07c8 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA Contents of section .rodata: 40007c8 48656c6c 6f732057 6f726c64 00Hellos World. And the HP C compiler has it in .rodata as well: $ cc a.out $ gobjdump -h -s -j .rodata a.out a.out: file format elf32-ia64-hpux-big Sections: Idx Name Size VMA LMA File off Algn 11 .rodata 000e 040007c0 040007c0 07c0 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA Contents of section .rodata: 40007c0 48656c6c 6f732057 6f726c64 0a00 Hellos World..
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #53 from The Written Word --- (In reply to EML from comment #52) > Note, regardless of reverting the gprel patch, GCC 8 puts the data in > .rodata. > > However, doesn't gcc 4.9.x do the same thing, it just moves it to GOT with > ltoffx? > > .file "foo.c" > .pred.safe_across_calls p1-p5,p16-p63 > .section.text, "ax", "progbits" > .Ltext0: > .section.rodata,"a","progbits" > .align 8 > .LC0: > stringz "Hellos World" > .section.text, "ax", "progbits" > > > Isn't LC0 here also in .rodata? > > objdump -h -s fooContents of section .rodata: > 40007f8 48656c6c 6f732057 6f726c64 00Hellos World. > > > So gcc 4.9.x also puts the string into rodata? > > (Not sure I'm reading all the files correctly, so perhaps I'm just reading > it all wrong) gcc-4.4.6 does: .file "hello.c" .pred.safe_across_calls p1-p5,p16-p63 .section.rodata,"a","progbits" .align 8 .LC0: stringz "Hellos World" .section.text, "ax", "progbits" .align 16 gcc-4.6.4 does: .file "hello.c" .pred.safe_across_calls p1-p5,p16-p63 .section.rodata,"a","progbits" .align 8 .LC0: stringz "Hellos World" .section.text, "ax", "progbits" .align 16 gcc-4.7.4 does: .pred.safe_across_calls p1-p5,p16-p63 .section.rodata,"a","progbits" .align 8 .LC0: stringz "Hellos World" .section.text, "ax", "progbits" .align 16 gcc-4.8.5 does: .pred.safe_across_calls p1-p5,p16-p63 .section.rodata,"a","progbits" .align 8 .LC0: stringz "Hellos World" .section.text, "ax", "progbits" .align 16 gcc-4.9.4 (with gprel patch reverted) does: .file "hello.c" .pred.safe_across_calls p1-p5,p16-p63 .section.rodata,"a","progbits" .align 8 .LC0: stringz "Hellos World" .section.text, "ax", "progbits" .align 16 gcc-8.3.0 (first stage) does: .section.text, "ax", "progbits" .section.rodata,"a","progbits" .align 8 .LC0: stringz "Hellos World" .section.text, "ax", "progbits" .align 16
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #51 from The Written Word
---
(In reply to dave.anglin from comment #50)
> On 2019-07-05 4:28 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> > I am uploading hello.c, hello.s, and hello.c.313r.dfinish.
> I'm still puzzled why .LC0 ends up in .rodata.
>
> (insn 30 2 34 2 (set (reg:DI 120 out0 [+-4 ])
> (minus:DI (symbol_ref/f:SI ("*.LC0") [flags 0x2] *.LC0>)
> (reg:DI 1 r1))) "hello.c":5 108 {*gprel64_offset}
> (nil))
This is a diff of the RTL between two gcc-8.3.0 versions, one with PR60465
reverted and one without:
--- without-PR60465/hello.c.313r.dfinish2019-07-05 20:37:38 +
+++ with-PR60465/hello.c.313r.dfinish2019-07-05 20:26:13 +
@@ -31,16 +31,16 @@
(note 22 21 2 2 NOTE_INSN_PROLOGUE_END)
(note 2 22 30 2 NOTE_INSN_FUNCTION_BEG)
(insn 30 2 34 2 (set (reg:DI 120 out0 [+-4 ])
-(plus:DI (high:DI (symbol_ref/f:SI ("*.LC0") [flags 0x2] ))
-(reg:DI 1 r1))) "hello.c":5 110 {*load_symptr_high}
+(minus:DI (symbol_ref/f:SI ("*.LC0") [flags 0x2] )
+(reg:DI 1 r1))) "hello.c":5 108 {*gprel64_offset}
(nil))
(insn 34 30 31 2 (unspec_volatile [
(const_int 3 [0x3])
] UNSPECV_INSN_GROUP_BARRIER) "hello.c":5 364 {insn_group_barrier}
(nil))
(insn 31 34 32 2 (set (reg:DI 120 out0 [+-4 ])
-(lo_sum:DI (mem/u/c:DI (reg:DI 120 out0 [+-4 ]) [0 S8 A64])
-(symbol_ref/f:SI ("*.LC0") [flags 0x2] ))) "hello.c":5 111 {*load_symptr_low}
+(plus:DI (reg:DI 1 r1)
+(reg:DI 120 out0 [+-4 ]))) "hello.c":5 206 {adddi3}
(nil))
(call_insn 32 31 33 2 (parallel [
(set (reg:SI 8 r8)
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #49 from The Written Word --- Created attachment 46565 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46565=edit hello.c compiled with -da /opt/build/china/gcc-8.3.0/.obj-/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj-/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include -g -da hello.c
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #48 from The Written Word --- Created attachment 46564 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46564=edit hello.s assembly output of hello.c /opt/build/china/gcc-8.3.0/.obj-/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj-/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include -S hello.c
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #47 from The Written Word --- Created attachment 46563 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46563=edit Hello.c test program
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #46 from The Written Word --- (In reply to dave.anglin from comment #45) > > You could dump the RTL by adding "-da" to the compile options. Then, you > could upload the "final" file. I am uploading hello.c, hello.s, and hello.c.313r.dfinish.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #43 from The Written Word --- (In reply to dave.anglin from comment #42) > On 2019-07-05 12:57 a.m., bugzilla-gcc at thewrittenword dot com wrote: > > I can now duplicate what you're seeing: > > $ diff -u gcc-4.9.4/hello.s gcc-8.3.0/hello.s > > --- gcc-4.9.3/hello.s2019-07-05 04:55:49 + > > +++ gcc-8.3.0/hello.s 2019-07-05 04:55:44 + > > @@ -1,5 +1,6 @@ > > .file "hello.c" > > .pred.safe_across_calls p1-p5,p16-p63 > > + .section.text, "ax", "progbits" > > .section.rodata,"a","progbits" > With 8.3.0 assembly output, what happens if you change ".rodata" to ".data"? > It may > be that hpux can't handle gprel in .rodata. > > The other possibility is gp is wrong. > > .align 8 > > .LC0: > > @@ -19,9 +20,9 @@ > > mov r32 = b0 > > mov r35 = r1 > > .body > > - addl r36 = @ltoffx(.LC0), r1 > > + movl r36 = @gprel(.LC0) > > ;; > > - ld8.mov r36 = [r36], .LC0 > > + add r36 = r1, r36 > > br.call.sptk.many b0 = puts# > > mov r1 = r35 > > mov r14 = r0 $ /opt/build/china/gcc-8.3.0/.obj-/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj-/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31 /lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include hello.s hello.s: Assembler messages: hello.s:4: Warning: ignoring changed section attributes for .data $ ./a.out `
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #41 from The Written Word
---
(In reply to The Written Word from comment #39)
> (In reply to EML from comment #25)
> > I have applied the patch and tried your other suggestions, still the stage1
> > compiler has the same problems generating executables.
> >
> > In analyzing the intermediate files between working (gcc 4.93) and not
> > (bootstrap 8.3), the intermediate files seem similar until the "mach" stage
> >
> > The problem seems to be in out the compiler decides to reference a string in
> > the source.
> >
> > My program is:
> >
> > #include
> >
> > int main()
> > {
> > printf("Hellos World\n");
> > return 0;
> > }
> >
> > The generated .s file for Working does this:
> >
> > .LC0:
> > stringz "Hellos World"
> >
> >
> >
> > addl r36 = @ltoffx(.LC0), r1
> > ;;
> > ld8.mov r36 = [r36], .LC0
> >
> > The non-working .s file does this:
> >
> > .LC0:
> > stringz "Hellos World"
> >
> >
> >
> > movl r36 = @gprel(.LC0)
> > ;;
> > add r36 = r1, r36
> >
> >
> > If I replace those 3 lines and run the assembler+linker by hand - the
> > non-working foo.s will run correctly
>
> I can now duplicate what you're seeing:
> $ diff -u gcc-4.9.4/hello.s gcc-8.3.0/hello.s
> --- gcc-4.9.3/hello.s2019-07-05 04:55:49 +
> +++ gcc-8.3.0/hello.s 2019-07-05 04:55:44 +
> @@ -1,5 +1,6 @@
> .file "hello.c"
> .pred.safe_across_calls p1-p5,p16-p63
> + .section.text, "ax", "progbits"
> .section.rodata,"a","progbits"
> .align 8
> .LC0:
> @@ -19,9 +20,9 @@
> mov r32 = b0
> mov r35 = r1
> .body
> - addl r36 = @ltoffx(.LC0), r1
> + movl r36 = @gprel(.LC0)
> ;;
> - ld8.mov r36 = [r36], .LC0
> + add r36 = r1, r36
> br.call.sptk.many b0 = puts#
> mov r1 = r35
> mov r14 = r0
>
> $ grep LTOFF /gcc/config.status
> D["HAVE_AS_LTOFFX_LDXMOV_RELOCS"]=" 1"
If I revert the patch for PR60465 (added as an attachment), then looking at the
difference between gcc-4.9.4/hello.s and gcc-8.3.0/hello.s gives:
--- gcc-4.9.4/hello.s2019-07-05 04:55:49 +
+++ gcc-8.3.0/hello.s 2019-07-05 11:25:09 +
@@ -1,5 +1,6 @@
.file "hello.c"
.pred.safe_across_calls p1-p5,p16-p63
+ .section.text, "ax", "progbits"
.section.rodata,"a","progbits"
.align 8
.LC0:
Reverting the patch doesn't bring us any closer to the segfault in libstdc++-v3
though.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #40 from The Written Word --- Created attachment 46560 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46560=edit Revert PR60465
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #39 from The Written Word
---
(In reply to EML from comment #25)
> I have applied the patch and tried your other suggestions, still the stage1
> compiler has the same problems generating executables.
>
> In analyzing the intermediate files between working (gcc 4.93) and not
> (bootstrap 8.3), the intermediate files seem similar until the "mach" stage
>
> The problem seems to be in out the compiler decides to reference a string in
> the source.
>
> My program is:
>
> #include
>
> int main()
> {
> printf("Hellos World\n");
> return 0;
> }
>
> The generated .s file for Working does this:
>
> .LC0:
> stringz "Hellos World"
>
>
>
> addl r36 = @ltoffx(.LC0), r1
> ;;
> ld8.mov r36 = [r36], .LC0
>
> The non-working .s file does this:
>
> .LC0:
> stringz "Hellos World"
>
>
>
> movl r36 = @gprel(.LC0)
> ;;
> add r36 = r1, r36
>
>
> If I replace those 3 lines and run the assembler+linker by hand - the
> non-working foo.s will run correctly
I can now duplicate what you're seeing:
$ diff -u gcc-4.9.4/hello.s gcc-8.3.0/hello.s
--- gcc-4.9.3/hello.s2019-07-05 04:55:49 +
+++ gcc-8.3.0/hello.s 2019-07-05 04:55:44 +
@@ -1,5 +1,6 @@
.file "hello.c"
.pred.safe_across_calls p1-p5,p16-p63
+ .section.text, "ax", "progbits"
.section.rodata,"a","progbits"
.align 8
.LC0:
@@ -19,9 +20,9 @@
mov r32 = b0
mov r35 = r1
.body
- addl r36 = @ltoffx(.LC0), r1
+ movl r36 = @gprel(.LC0)
;;
- ld8.mov r36 = [r36], .LC0
+ add r36 = r1, r36
br.call.sptk.many b0 = puts#
mov r1 = r35
mov r14 = r0
$ grep LTOFF /gcc/config.status
D["HAVE_AS_LTOFFX_LDXMOV_RELOCS"]=" 1"
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #38 from The Written Word --- I rebuilt 8.3.0 with minimal patches and am seeing the same failure as before. From /ia64-hp-hpux11.31/libstdc++-v3/config.log: configure:7964: checking for ANSI C header files configure:7984: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-c -O2 -g conftest.c >&5 configure:7984: $? = 0 configure:8057: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-o conftest -O2 -g conftest.c >&5 configure:8057: $? = 0 configure:8057: ./conftest /opt/build/china/gcc-8.3.0/libstdc++-v3/configure: line 1940: 18830 Segmentation fault (core dumped) ./conftest$ac_exeext If I compile the conftest.c program between gcc-4.9.4 and the 8.3.0 stage 1 compiler: --- gcc-4.9.4/conftest.s 2019-07-05 04:50:23 + +++ /opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/conftest.s 2019-07-05 04:50:13 + @@ -27,42 +27,26 @@ ;; ld4 r14 = [r14] ;; - addp4 r14 = 0,r14 - ;; cmp.eq p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L3 addl r14 = @ltoffx(__SB_masks#), r1 ;; ld8.mov r14 = [r14], __SB_masks# ;; ld4 r14 = [r14] - ;; - addp4 r14 = 0,r14 ld4 r15 = [r34] ;; shladd r15 = r15, 2, r0 ;; add r14 = r15, r14 ;; - addp4 r14 = 0,r14 + addp4 r14 = r14, r0 ;; ld4 r14 = [r14] ;; and r14 = 64, r14 ;; cmp4.ne p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L4 br .L5 ;; @@ -73,33 +57,15 @@ mov r14 = r8 ;; cmp4.eq p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L5 .L4: ld4 r14 = [r34] ;; cmp4.ge p6, p7 = 96, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L6 ld4 r14 = [r34] ;; cmp4.lt p6, p7 = 122, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L6 .L5: addl r14 = @ltoffx(__SB_masks#), r1 @@ -108,42 +74,26 @@ ;; ld4 r14 = [r14] ;; - addp4 r14 = 0,r14 - ;; cmp.eq p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L7 addl r14 = @ltoffx(__SB_masks#), r1 ;; ld8.mov r14 = [r14], __SB_masks# ;; ld4 r14 = [r14] - ;; - addp4 r14 = 0,r14 ld4 r15 = [r34] ;; shladd r15 = r15, 2, r0 ;; add r14 = r15, r14 ;; - addp4 r14 = 0,r14 + addp4 r14 = r14, r0 ;; ld4 r14 = [r14] ;; and r14 = 64, r14 ;; cmp4.eq p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L8 br .L9 ;; @@ -154,33 +104,15 @@ mov r14 = r8 ;; cmp4.ne p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L9 .L8: ld4 r14 = [r34] ;; cmp4.ge p6, p7 = 96, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L9 ld4 r14 = [r34] ;; cmp4.ge p6, p7 = 122, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L6 .L9: ld4 r36 = [r34] @@ -190,22 +122,10 @@ ld4 r14 = [r34] ;; cmp4.ge p6, p7 = 96, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L10 ld4 r14 = [r34] ;; cmp4.lt p6, p7 = 122, r14 -
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #30 from The Written Word --- (In reply to dave.anglin from comment #29) > On 2019-07-03 7:20 p.m., bugzilla-gcc at thewrittenword dot com wrote: > > configure:8057: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc > > -B/opt/build/china/gcc-8.3.0/.obj/./gcc/ > > -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/i > > a64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include > > -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-o conftest -O2 > > -g > > conftest.c >&5 > > configure:8057: $? = 0 > > configure:8057: ./conftest > > /opt/build/china/gcc-8.3.0/libstdc++-v3/configure[20]: 1572 > > Memoryfault(coredum > > p) > > The configure test needs to be debugged in the same manner as the "hello > world" program. Yeah, we've already looked at the difference between 4.9.4/8.3.0 assembly but want to rebuild 8.3.0 with as few patches as possible to ensure the issue isn't some patch we've introduced.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #28 from The Written Word --- (In reply to EML from comment #17) > Note that in certain cases, the MPFR library won't build depending on the > CFLAGS used (in particular the default -g -O2), this is due to problems with > thread local storage. You can work around this by configuring MPFR with > --disable-thread-safe We are building GCC against mpfr-3.1.6 but MPFR wasn't a difficult build on HP-UX/IA. We are building with the HP C compiler though. The MPFR testsuite passed all but one test which was a PASS. And, ./configure shows -DMPFR_USE_THREAD_SAFE=1.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #27 from The Written Word --- (In reply to dave.anglin from comment #26) > On 2019-07-03 6:06 p.m., elowe at elowe dot com wrote: > > If I replace those 3 lines and run the assembler+linker by hand - the > > non-working foo.s will run correctly > So, HAVE_AS_LTOFFX_LDXMOV_RELOCS is probably not defined. The configure > script is > likely not detecting this assembler capability correctly. > > Are you using bash shell? If not, I suggest that you use it instead of HP > shell. It's set to 1 for us. We're getting a segfault while building libstdc++-v3 with 8.3.0: configure:7964: checking for ANSI C header files configure:7984: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-c -O2 -g conftest.c >&5 configure:7984: $? = 0 configure:8057: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/i a64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-o conftest -O2 -g conftest.c >&5 configure:8057: $? = 0 configure:8057: ./conftest /opt/build/china/gcc-8.3.0/libstdc++-v3/configure[20]: 1572 Memoryfault(coredum p) configure:8057: $? = 139 Using the stage 1 8.3.0 compiler, we can get a simple "hello world" program to compile.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #24 from The Written Word --- (In reply to EML from comment #22) > Thanks for the hints and options > > on IA64, I used the GNU AS (2.32), but the HP LD (ld: 92453-07 linker ld HP > Itanium(R) B.12.65 IPF/IPF) Do you have this patch applied as you're using binutils 2.32? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87338?
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #15 from The Written Word --- (In reply to dave.anglin from comment #12) > It might help to compile stage1 with -O2 or -Os. How does one do this? After ./configure, "gmake CFLAGS=-Os"? BOOT_CFLAGS applies to stage2/3.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #13 from The Written Word --- (In reply to dave.anglin from comment #12) > It might help to compile stage1 with -O2 or -Os. This might reduce offset > and get a newer version > of gcc to build. gcc-8.3.0 seems to have built okay on Debian. gcc-9 so > far has failed to build on ia64. Ok, I'll try. I'll try to reach out to the Debian/ia maintainers again.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #14 from The Written Word --- (In reply to dave.anglin from comment #10) > I don't know the status of Jim Wilson who is listed as ia64 maintainer. We reached out to Jim Wilson in 2016 and got a reply back. He no longer has access to any ia64 machines.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #11 from The Written Word --- (In reply to dave.anglin from comment #10) > On 2019-05-07 5:29 a.m., redi at gcc dot gnu.org wrote: > > Dave, are you aware of anybody testing ia64-hpux? > > Should it be deprecated if nobody is maintaining it? > I don't have or access to a ia64 box. > > I don't know the status of Jim Wilson who is listed as ia64 maintainer. > > Albert Chin is the only person that I know who > might be actively using it. > > My access to the hppa box that I use for hppa-hpux support requires support > from NRC Canada but > all colleagues there have retired. It was down for a few weeks until > yesterday when I got a network person > to reboot it. > > So, maybe it's time to deprecate hpux. I'm still working on hppa-linux. We are still using it but haven't been able to build anything post 4.9.4. We tried to find someone to pay to bring this port up-to-date but had no success. Open to other suggestions but deprecating it might be the only way forward.
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #20 from The Written Word --- Created attachment 44536 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44536=edit stdlib.h long_double patch for HP-UX 11.31/PA Tested against 7.3.0 and 8.2.0.
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #19 from The Written Word --- (In reply to dave.anglin from comment #18) > On 2018-08-12 8:10 AM, bugzilla-gcc at thewrittenword dot com wrote: > > This is the patch I came up with. What do you think? > > Did you check that "make check" in the fixincludes build directory works > and there are no issues left? See README in fixincludes directory. > > If this works, please add a ChangeLog entry to the patch and send it to > gcc-patches. > CC Bruce Korb and myself. > > It would be good if you could post test results for 11.31 to > gcc-testresults. This will > help find further problems. Ok, will take care of all of the above. Found one issue in my patch which I'm testing now. Once I have something that passes the above, will submit.
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #17 from The Written Word --- (In reply to The Written Word from comment #16) > Created attachment 44529 [details] > stdlib.h long_double patch This is the patch I came up with. What do you think?
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #16 from The Written Word --- Created attachment 44529 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44529=edit stdlib.h long_double patch
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599
--- Comment #14 from The Written Word
---
(In reply to The Written Word from comment #13)
> (In reply to The Written Word from comment #10)
> > (In reply to John David Anglin from comment #9)
> > > It would help to see the uses of long_double in stdlib.h.
> >
> > /usr/include/stdlib.h has:
> >
> > # ifndef _LONG_DOUBLE
> > #define _LONG_DOUBLE
> > # if !defined(__ia64) || !defined(_PROTOTYPES) ||
> > defined(_LONG_DOUBLE_STRUCT)
> > typedef struct {
> > uint32_t word1, word2, word3, word4;
> > } long_double;
> > extern long_double strtold __((const char * __restrict, char **
> > __restrict));
> > # else /* !__ia64 || !_PROTOTYPES || _LONG_DOUBLE_STRUCT */
> > #ifdef _INCLUDE_HPUX_SOURCE
> > typedef long double long_double;
> > #endif /* _INCLUDE_HPUX_SOURCE */
> > extern long double strtold __((const char * __restrict, char **
> > __restrict));
> > # endif /* !__ia64 ||!_PROTOTYPES ||_LONG_DOUBLE_STRUCT */
> > #endif /* _LONG_DOUBLE */
>
> I think the problem on 11.31 is that the strtold() definition is in the
> above. We can't simply remove it all and change long_double->long double in
> the remainder of the file to get the function definition changed.
Hmm, maybe two new rules, the first to remove everything before "extern long
double strtold" and change long_double->long double and the second to remove
the two lines after "extern long double strtold". Let me try to come up with
something.
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599
--- Comment #13 from The Written Word
---
(In reply to The Written Word from comment #10)
> (In reply to John David Anglin from comment #9)
> > It would help to see the uses of long_double in stdlib.h.
>
> /usr/include/stdlib.h has:
>
> # ifndef _LONG_DOUBLE
> #define _LONG_DOUBLE
> # if !defined(__ia64) || !defined(_PROTOTYPES) ||
> defined(_LONG_DOUBLE_STRUCT)
> typedef struct {
> uint32_t word1, word2, word3, word4;
> } long_double;
> extern long_double strtold __((const char * __restrict, char ** __restrict));
> # else /* !__ia64 || !_PROTOTYPES || _LONG_DOUBLE_STRUCT */
> #ifdef _INCLUDE_HPUX_SOURCE
> typedef long double long_double;
> #endif /* _INCLUDE_HPUX_SOURCE */
> extern long double strtold __((const char * __restrict, char ** __restrict));
> # endif /* !__ia64 ||!_PROTOTYPES ||_LONG_DOUBLE_STRUCT */
> #endif /* _LONG_DOUBLE */
I think the problem on 11.31 is that the strtold() definition is in the above.
We can't simply remove it all and change long_double->long double in the
remainder of the file to get the function definition changed.
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #12 from The Written Word --- (In reply to The Written Word from comment #11) > Created attachment 44528 [details] > stdlib.h long_double patch My first attempt but it didn't work.
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #11 from The Written Word --- Created attachment 44528 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44528=edit stdlib.h long_double patch
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599
--- Comment #10 from The Written Word
---
(In reply to John David Anglin from comment #9)
> It would help to see the uses of long_double in stdlib.h.
/usr/include/stdlib.h has:
# ifndef _LONG_DOUBLE
#define _LONG_DOUBLE
# if !defined(__ia64) || !defined(_PROTOTYPES) || defined(_LONG_DOUBLE_STRUCT)
typedef struct {
uint32_t word1, word2, word3, word4;
} long_double;
extern long_double strtold __((const char * __restrict, char ** __restrict));
# else /* !__ia64 || !_PROTOTYPES || _LONG_DOUBLE_STRUCT */
#ifdef _INCLUDE_HPUX_SOURCE
typedef long double long_double;
#endif /* _INCLUDE_HPUX_SOURCE */
extern long double strtold __((const char * __restrict, char ** __restrict));
# endif /* !__ia64 ||!_PROTOTYPES ||_LONG_DOUBLE_STRUCT */
#endif /* _LONG_DOUBLE */
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 --- Comment #17 from The Written Word --- Created attachment 44456 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44456=edit gcc/config/rs6000/aix53.h patch for gcc-5.5.0 Needed this patch to build 5.5.0 successfully on AIX 5.3.
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 --- Comment #16 from The Written Word --- Created attachment 44455 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44455=edit gcc/config/rs6000/aix53.h for gcc-6.4.0 Needed this patch to build 6.4.0 successfully on AIX 5.3.
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 --- Comment #15 from The Written Word --- Created attachment 3 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3=edit gcc/config/rs6000/aix53.h patch Similar to r227907 but for AIX 5.3 Have used this to successfully build gcc-8.1.0 on AIX 5.3.
[Bug fortran/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #7 from The Written Word --- (In reply to Dominique d'Humieres from comment #6) > This looks like a target issue. Have you ever build gcc on HP-UX 11.31/PA? Definitely a target issue. With some patches I can build gcc 4.x on 11.31/PA. I am building 8.1.0 now with a fixinc patch to address the issue I am raising in this PR. I don't know how to quickly test a fixinc patch without doing a full rebuild so it's taking awhile. Should know by the end of the day.
[Bug fortran/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599
--- Comment #5 from The Written Word
---
(In reply to The Written Word from comment #4)
> On HP-UX 11.23/PA, this isn't an issue because of the following in
> fixincludes/inclhack.def:
> /*
> * HP-UX long_double
> */
> fix = {
> hackname = hpux_long_double;
> mach = "*-*-hpux10*";
> mach = "*-*-hpux11.[0123]*";
> files = stdlib.h;
> select= "extern[ \t]long_double[ \t]strtold";
> bypass= "long_double_t";
> sed = "/^#[ \t]*ifndef _LONG_DOUBLE/,/\\/\\* _LONG_DOUBLE
> \\*\\//D";
> sed = "s/long_double/long double/g";
>
> test_text = "# ifndef _LONG_DOUBLE\n"
> "#define _LONG_DOUBLE\n"
> " typedef struct {\n"
> " unsigned int word1, word2, word3, word4;\n"
> " } long_double;\n"
> "# endif /* _LONG_DOUBLE */\n"
> "extern long_double strtold(const char *, char **);\n";
> };
Actually, it's:
/*
* HP-UX long_double
*/
fix = {
hackname = hpux_long_double;
mach = "*-*-hpux10*";
mach = "*-*-hpux11.[012]*";
files = stdlib.h;
select= "extern[ \t]long_double[ \t]strtold";
bypass= "long_double_t";
sed = "/^#[ \t]*ifndef _LONG_DOUBLE/,/\\/\\* _LONG_DOUBLE \\*\\//D";
sed = "s/long_double/long double/g";
test_text = "# ifndef _LONG_DOUBLE\n"
"#define _LONG_DOUBLE\n"
" typedef struct {\n"
" unsigned int word1, word2, word3, word4;\n"
" } long_double;\n"
"# endif /* _LONG_DOUBLE */\n"
"extern long_double strtold(const char *, char **);\n";
};
[Bug fortran/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599
The Written Word changed:
What|Removed |Added
Version|7.2.0 |8.1.0
--- Comment #4 from The Written Word
---
hppa2.0w-hp-hpux11.31/libgfortran/kinds.h has:
...
typedef long double GFC_REAL_16;
typedef complex long double GFC_COMPLEX_16;
#define HAVE_GFC_REAL_16
#define HAVE_GFC_COMPLEX_16
#define GFC_REAL_16_HUGE 1.18973149535723176508575932662800702e4932l
#define GFC_REAL_16_LITERAL_SUFFIX l
#define GFC_REAL_16_LITERAL(X) (X ## l)
#define GFC_REAL_16_DIGITS 113
#define GFC_REAL_16_RADIX 2
And gcc/include-fixed/stdlib.h has:
#ifdef _INCLUDE_STDC__SOURCE_199901
# if defined(__ia64)
/* pragmas needed to support -B protected */
#pragma extern strtold
# endif /* __ia64 */
# ifndef _LONG_DOUBLE
#define _LONG_DOUBLE
# if !defined(__ia64) || !defined(_PROTOTYPES) || defined(_LONG_DOUBLE_STRUCT)
typedef struct {
uint32_t word1, word2, word3, word4;
} long_double;
extern long_double strtold __((const char * __restrict, char ** __restrict));
# else /* !__ia64 || !_PROTOTYPES || _LONG_DOUBLE_STRUCT */
#ifdef _INCLUDE_HPUX_SOURCE
typedef long double long_double;
#endif /* _INCLUDE_HPUX_SOURCE */
extern long double strtold __((const char * __restrict, char ** __restrict));
# endif /* !__ia64 ||!_PROTOTYPES ||_LONG_DOUBLE_STRUCT */
#endif /* _LONG_DOUBLE */
#endif /* _INCLUDE_STDC__SOURCE_199901 */
So, the strtold definition being used in io/read.c is:
extern long_double strtold __((const char * __restrict, char ** __restrict));
On HP-UX 11.23/PA, this isn't an issue because of the following in
fixincludes/inclhack.def:
/*
* HP-UX long_double
*/
fix = {
hackname = hpux_long_double;
mach = "*-*-hpux10*";
mach = "*-*-hpux11.[0123]*";
files = stdlib.h;
select= "extern[ \t]long_double[ \t]strtold";
bypass= "long_double_t";
sed = "/^#[ \t]*ifndef _LONG_DOUBLE/,/\\/\\* _LONG_DOUBLE \\*\\//D";
sed = "s/long_double/long double/g";
test_text = "# ifndef _LONG_DOUBLE\n"
"#define _LONG_DOUBLE\n"
" typedef struct {\n"
" unsigned int word1, word2, word3, word4;\n"
" } long_double;\n"
"# endif /* _LONG_DOUBLE */\n"
"extern long_double strtold(const char *, char **);\n";
};
We also have the following in the same file for HP-UX 11.31/PA:
/*
* We cannot use the above rule on 11.31 because it removes the strtold
* definition. ia64 is OK with no hack, PA needs some help.
*/
fix = {
hackname = hpux_long_double_2;
mach = "hppa*-*-hpux11.3*";
files = stdlib.h;
select= "#[ \t]*if[ \t]*!defined\\(__ia64\\) \\|\\| "
"defined\\(_PROTOTYPES\\) \\|\\| "
"defined\\(_LONG_DOUBLE_STRUCT\\)";
c_fix = format;
c_fix_arg = "# if !defined(_PROTOTYPES) || defined(_LONG_DOUBLE_STRUCT)";
test_text = "# if !defined(__ia64) || "
"!defined(_PROTOTYPES) || "
"defined(_LONG_DOUBLE_STRUCT)\n";
};
Maybe the above is no longer working?
[Bug fortran/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #3 from The Written Word --- 6.4.0 and 7.3.0 exhibit the same error.
[Bug bootstrap/68663] Build failure on AIX 7.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68663 The Written Word changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #10 from The Written Word --- (In reply to The Written Word from comment #9) > (In reply to David Edelsohn from comment #7) > > I use GCC 4.6 to bootstrap. It appears that the error is caused by the > > "system" bootstrap compiler, which I think is GCC 4.4 in your case. It is > > generating code with too large displacements. > > > > Also, some of the configure options are unusual. > > Ok, will try something later than 4.4. Thanks. Ok, things are working now. Thanks.
[Bug fortran/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #2 from The Written Word --- (In reply to The Written Word from comment #1) > I get a similar error with 8.1.0. And with 5.5.0.
[Bug bootstrap/86630] gcc/graphite.c build failure on AIX 5.2 and 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86630 --- Comment #3 from The Written Word --- (In reply to Richard Biener from comment #2) > GCC assumes that inttypes.h contains PRIx64 It does. gcc/system.h has: /* Define this so that inttypes.h defines the PRI?64 macros even when compiling with a C++ compiler. Define it here so in the event inttypes.h gets pulled in by another header it is already defined. */ #define __STDC_FORMAT_MACROS However, as I built with ISL, gcc/graphite.c includes the ISL .h files before gcc/system.h meaning __STDC_FORMAT_MACROS gets defined after inttypes.h is pulled in, avoiding the definition of PRIx64. This #include order in gcc/graphite.c was fixed for gcc-6 so this problem seems to be limited to gcc-5 so I need to find a way around this.
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553
--- Comment #14 from The Written Word
---
Adding -bnoquiet to the linker command-line I get:
(ld): halt 4
(ld): setopt r/o->w
(ld): setopt nortl
(ld): setopt nortllib
(ld): setopt symbolic:-1
(ld): setfflag 4
(ld): savename ./shr.o
(ld): filelist 133 3
(ld): setopt noprogram
(ld): noentry
NOENTRY: There is no entry point.
(ld): i _muldi3_s.o
(ld): i /tmp//cckXJM4j.o
(ld): i _negdi2_s.o
(ld): i _lshrdi3_s.o
(ld): i _ashldi3_s.o
(ld): i _ashrdi3_s.o
(ld): i _cmpdi2_s.o
(ld): i _ucmpdi2_s.o
(ld): i _clear_cache_s.o
(ld): i _trampoline_s.o
(ld): i __main_s.o
(ld): i _absvsi2_s.o
(ld): i _absvdi2_s.o
(ld): i _addvsi3_s.o
(ld): i _addvdi3_s.o
(ld): i _subvsi3_s.o
(ld): i _subvdi3_s.o
(ld): i _mulvsi3_s.o
(ld): i _mulvdi3_s.o
(ld): i _negvsi2_s.o
(ld): i _negvdi2_s.o
(ld): i _ctors_s.o
(ld): i _ffssi2_s.o
(ld): i _ffsdi2_s.o
(ld): i _clz_s.o
(ld): i _clzsi2_s.o
(ld): i _clzdi2_s.o
(ld): i _ctzsi2_s.o
(ld): i _ctzdi2_s.o
(ld): i _popcount_tab_s.o
(ld): i _popcountsi2_s.o
(ld): i _popcountdi2_s.o
(ld): i _paritysi2_s.o
(ld): i _paritydi2_s.o
(ld): i _powisf2_s.o
(ld): i _powidf2_s.o
(ld): i _powixf2_s.o
(ld): i _powitf2_s.o
(ld): i _mulsc3_s.o
(ld): i _muldc3_s.o
(ld): i _mulxc3_s.o
(ld): i _multc3_s.o
(ld): i _divsc3_s.o
(ld): i _divdc3_s.o
(ld): i _divxc3_s.o
(ld): i _divtc3_s.o
(ld): i _bswapsi2_s.o
(ld): i _bswapdi2_s.o
(ld): i _clrsbsi2_s.o
(ld): i _clrsbdi2_s.o
(ld): i _fixunssfsi_s.o
(ld): i _fixunsdfsi_s.o
(ld): i _fixunsxfsi_s.o
(ld): i _fixsfdi_s.o
(ld): i _fixdfdi_s.o
(ld): i _fixxfdi_s.o
(ld): i _fixtfdi_s.o
(ld): i _fixunssfdi_s.o
(ld): i _fixunsdfdi_s.o
(ld): i _fixunsxfdi_s.o
(ld): i _fixunstfdi_s.o
(ld): i _floatdisf_s.o
(ld): i _floatdidf_s.o
(ld): i _floatdixf_s.o
(ld): i _floatditf_s.o
(ld): i _floatundisf_s.o
(ld): i _floatundidf_s.o
(ld): i _floatundixf_s.o
(ld): i _floatunditf_s.o
(ld): i _divdi3_s.o
(ld): i _moddi3_s.o
(ld): i _udivdi3_s.o
(ld): i _umoddi3_s.o
(ld): i _udiv_w_sdiv_s.o
(ld): i _udivmoddi4_s.o
(ld): i _pack_sf_s.o
(ld): i _unpack_sf_s.o
(ld): i _addsub_sf_s.o
(ld): i _mul_sf_s.o
(ld): i _div_sf_s.o
(ld): i _fpcmp_parts_sf_s.o
(ld): i _compare_sf_s.o
(ld): i _eq_sf_s.o
(ld): i _ne_sf_s.o
(ld): i _gt_sf_s.o
(ld): i _ge_sf_s.o
(ld): i _lt_sf_s.o
(ld): i _le_sf_s.o
(ld): i _unord_sf_s.o
(ld): i _si_to_sf_s.o
(ld): i _sf_to_si_s.o
(ld): i _negate_sf_s.o
(ld): i _make_sf_s.o
(ld): i _sf_to_df_s.o
(ld): i _thenan_sf_s.o
(ld): i _sf_to_usi_s.o
(ld): i _usi_to_sf_s.o
(ld): i _pack_df_s.o
(ld): i _unpack_df_s.o
(ld): i _addsub_df_s.o
(ld): i _mul_df_s.o
(ld): i _div_df_s.o
(ld): i _fpcmp_parts_df_s.o
(ld): i _compare_df_s.o
(ld): i _eq_df_s.o
(ld): i _ne_df_s.o
(ld): i _gt_df_s.o
(ld): i _ge_df_s.o
(ld): i _lt_df_s.o
(ld): i _le_df_s.o
(ld): i _unord_df_s.o
(ld): i _si_to_df_s.o
(ld): i _df_to_si_s.o
(ld): i _negate_df_s.o
(ld): i _make_df_s.o
(ld): i _df_to_sf_s.o
(ld): i _thenan_df_s.o
(ld): i _df_to_usi_s.o
(ld): i _usi_to_df_s.o
(ld): i ppc64-fp_s.o
(ld): i ibm-ldouble_s.o
(ld): i enable-execute-stack_s.o
(ld): i unwind-dw2_s.o
(ld): i unwind-dw2-fde_s.o
(ld): i unwind-sjlj_s.o
(ld): i unwind-c_s.o
(ld): i cxa_atexit_s.o
(ld): i cxa_finalize_s.o
(ld): i atexit_s.o
(ld): i on_exit_s.o
(ld): i emutls_s.o
(ld): i libgcc.a
(ld): lib /usr/lib/libc.a
LIBRARY: Shared object libc.a[shr.o]: 2884 symbols imported.
LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported.
LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported.
LIBRARY: Shared object libc.a[aio.o]: 18 symbols imported.
LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported.
LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported.
LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported.
FILELIST: Number of previously inserted files processed: 133
(ld): exports libgcc.map
EXPORTS: Symbols exported: 132
(ld): exports /tmp//ccKVYDLo.x
EXPORTS: Symbols exported: 2
(ld): initfini _GLOBAL__FI_shr_o _GLOBAL__FD_shr_o
(ld): resolve
RESOLVE: 448 of 5365 symbols were kept.
(ld): addgl /usr/lib/glink.o
ADDGL: Glink code added for 6 symbols.
(ld): er full
ld: 0711-318 ERROR: Undefined symbols were found.
The following symbols are in error:
SymbolInpndx TY CL Source-File(Object-File) OR
Import-File{Shared-object}
RLD: Address Section Rld-type Referencing
Symbol
--
__gcc_unwind_dbase[30]ER UA /tmp//ccyTJl8f.c(/tmp//cckXJM4j.o)
0384 .dataR_POS[76]
<__gcc_unwind_dbase>
__dso_handle [6] ER UA
/opt/build/china/gcc-8.1.0/libgcc/config/rs6000/atexit.c(atexit_s.o)
00c4 .dataR_POS[394]
<__dso_handle>
ER: The return code is 8.
ld: 0711-317 ERROR: Undefined symbol: __gcc_unwind_dbase
ld: 0711-317 ERROR: Undefined symbol: __dso_handle
collect2: error: ld returned 8 exit status
ar: A file or directory in
[Bug bootstrap/86559] Build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86559 --- Comment #4 from The Written Word --- gcc-7.3.0 exhibits the same problem.
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 --- Comment #13 from The Written Word --- (In reply to The Written Word from comment #10) > (In reply to Jonathan Wakely from comment #8) > > Created attachment 44406 [details] > > Undefine macros for long double math functions > > > > Does this fix the build? > > I am trying a similar patch. I basically #undef'd everything to get a clean > build of that file and restarted the build from scratch so we'll see. Was able to progress further with the build. The error is now: libtool: link: /opt/build/china/gcc-8.1.0/.obj/./gcc/xgcc -shared-libgcc -B/opt/build/china/gcc-8.1.0/.obj/./gcc -nostdinc++ -L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/src -L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/src/.libs -L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/libsupc++/.libs -B/tmp/gcc8/powerpc-ibm-aix5.3.11.0/bin/ -B/tmp/gcc8/powerpc-ibm-aix5.3.11.0/lib/ -isystem /tmp/gcc8/powerpc-ibm-aix5.3.11.0/include -isystem /tmp/gcc8/powerpc-ibm-aix5.3.11.0/sys-include-shared -o .libs/libstdc++.so.6 .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o ../libsupc++/.libs/libsupc++convenience.a ../src/c++98/.libs/libc++98convenience.a ../src/c++11/.libs/libc++11convenience.a -L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/libsupc++/.libs -L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/src -L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/src/.libs -lm -L/opt/build/china/gcc-8.1.0/.obj/./gcc -lc -lgcc_s -Wl,-bnoentry -Wl,-bE:.libs/libstdc++.exp -Wl,-berok collect2: fatal error: library libgcc_s not found compilation terminated. gmake[6]: *** [libstdc++.la] Error 1 gmake[6]: Leaving directory `/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/src' Seems there are build errors for libgcc_s. From earlier in the build: mkdir pthread if test svr4 != aix ; then /opt/build/china/gcc-8.1.0/.obj/./gcc/xgcc -B/opt/build/china/gcc-8.1.0/.obj/./gcc/ -B/tmp/gcc8/powerpc-ibm-aix5.3.11.0/bin/ -B/tmp/gcc8/powerpc-ibm-aix5.3.11.0/lib/ -isystem /tmp/gcc8/powerpc-ibm-aix5.3.11.0/include -isystem /tmp/gcc8/powerpc-ibm-aix5.3.11.0/sys-include-O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -mlong-double-128 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -shared -Wl,-bnortl -nodefaultlibs -Wl,-bE:libgcc.map -o pthread/shr.o -g -O2 -pthread -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o _pack_sf_s.o _unpack_sf_s.o _addsub_sf_s.o _mul_sf_s.o _div_sf_s.o _fpcmp_parts_sf_s.o _compare_sf_s.o _eq_sf_s.o _ne_sf_s.o _gt_sf_s.o _ge_sf_s.o _lt_sf_s.o _le_sf_s.o _unord_sf_s.o _si_to_sf_s.o _sf_to_si_s.o _negate_sf_s.o _make_sf_s.o _sf_to_df_s.o _thenan_sf_s.o _sf_to_usi_s.o _usi_to_sf_s.o _pack_df_s.o _unpack_df_s.o _addsub_df_s.o _mul_df_s.o _div_df_s.o _fpcmp_parts_df_s.o _compare_df_s.o _eq_df_s.o _ne_df_s.o _gt_df_s.o _ge_df_s.o _lt_df_s.o _le_df_s.o _unord_df_s.o _si_to_df_s.o _df_to_si_s.o _negate_df_s.o _make_df_s.o _df_to_sf_s.o _thenan_df_s.o _df_to_usi_s.o _usi_to_df_s.o ppc64-fp_s.o ibm-ldouble_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde_s.o unwind-sjlj_s.o unwind-c_s.o cxa_atexit_s.o cxa_finalize_s.o atexit_s.o on_exit_s.o emutls_s.o libgcc.a -lc `case pthread in *pthread*) echo -L/usr/lib/threads -lpthreads -lc_r /usr/lib/libc.a ;; *) echo -lc ;; esac` ; rm -f pthread/tmp-libgcc_s.a ; ar -X32_64 -X32_64 rc pthread/tmp-libgcc_s.a pthread/shr.o ; mv pthread/tmp-libgcc_s.a pthread/libgcc_s.a ; rm -f pthread/shr.o ; fi ; if test aix != aix ; then case pthread in *64*) shr='shr_64' ;; *) shr='shr' ;;
[Bug bootstrap/86630] gcc/graphite.c build failure on AIX 5.2 and 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86630 --- Comment #1 from The Written Word --- AIX 6.1 exhibits a similar error.
[Bug c/86630] New: gcc/graphite.c build failure on AIX 5.2 and 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86630 Bug ID: 86630 Summary: gcc/graphite.c build failure on AIX 5.2 and 5.3 Product: gcc Version: 5.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bugzilla-gcc at thewrittenword dot com Target Milestone: --- I tried building gcc-5.5.0 on AIX 5.2 and 5.3 as follows: $ gtar Jxf gcc-5.5.0.tar.xz $ cd gcc-5.5.0 $ mkdir .obj $ cd .obj $ PATH=/opt/TWWfsw/gcc49/bin:$PATH /opt/fsw/bash42/bin/bash \ ../configure SHELL=/opt/fsw/bash42/bin/bash \ CONFIG_SHELL=/opt/fsw/bash42/bin/bash LDR_CNTRL=MAXDATA=0x7000 \ LDFLAGS="-Wl,-brtl -Wl,blibpath:/opt/TWWfsw/libisl016/lib:\ /opt/TWWfsw/libgmp61/lib:/opt/TWWfsw/libmpc10/lib:\ /opt/TWWfsw/libmpfr31/lib:/usr/lib" --enable-nls \ --with-included-gettext --enable-shared --enable-threads \ --enable-languages="c,c++,fortran,lto" --with-gmp=/opt/TWWfsw/libgmp61 \ --with-isl=/opt/TWWfsw/libisl016 --with-mpc=/opt/TWWfsw/libmpc10 \ --with-mpfr=/opt/TWWfsw/libmpfr31 --with-local-prefix=/tmp/gcc5 \ --prefix=/tmp/gcc5 ... $ PATH=/opt/TWWfsw/gcc49/bin:$PATH LDR_CNTRL=MAXDATA=0x7000 \ SHELL=/opt/fsw/bin/bash CONFIG_SHELL=/opt/fsw/bin/bash gmake ... The build failed with the following: g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/opt/build/china/gcc-5.5.0/gcc -I/opt/build/china/gcc-5.5.0/gcc/. -I/opt/build/china/gcc-5.5.0/gcc/../include -I./../intl -I/opt/build/china/gcc-5.5.0/gcc/../libcpp/include -I/opt/TWWfsw/libgmp61/include -I/opt/TWWfsw/libmpfr31/include -I/opt/TWWfsw/libmpc10/include -I/opt/build/china/gcc-5.5.0/gcc/../libdecnumber -I/opt/build/china/gcc-5.5.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/opt/build/china/gcc-5.5.0/gcc/../libbacktrace -I/opt/TWWfsw/libisl016/include -o graphite.o -MT graphite.o -MMD -MP -MF ./.deps/graphite.TPo /opt/build/china/gcc-5.5.0/gcc/graphite.c In file included from /opt/build/china/gcc-5.5.0/gcc/system.h:1116:0, from /opt/build/china/gcc-5.5.0/gcc/graphite.c:45: /opt/build/china/gcc-5.5.0/gcc/wide-int.h: In member function 'void generic_wide_int::dump() const': /opt/build/china/gcc-5.5.0/gcc/hwint.h:110:38: error: expected ')' before 'PRIx64' #define HOST_WIDE_INT_PRINT_HEX "%#" PRIx64 ^ /opt/build/china/gcc-5.5.0/gcc/wide-int.h:870:22: note: in expansion of macro 'HOST_WIDE_INT_PRINT_HEX' fprintf (stderr, HOST_WIDE_INT_PRINT_HEX ",", val[len - 1 - i]); ^ /opt/build/china/gcc-5.5.0/gcc/hwint.h:110:38: error: expected ')' before 'PRIx64' #define HOST_WIDE_INT_PRINT_HEX "%#" PRIx64 ^ /opt/build/china/gcc-5.5.0/gcc/wide-int.h:871:20: note: in expansion of macro 'HOST_WIDE_INT_PRINT_HEX' fprintf (stderr, HOST_WIDE_INT_PRINT_HEX "], precision = %d\n", ^ gmake[3]: *** [graphite.o] Error 1 gmake[3]: Leaving directory `/opt/build/china/gcc-5.5.0/.obj/gcc'
[Bug other/60465] [4.9/5 Regression] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #49 from The Written Word --- (In reply to Sergei Trofimovich from comment #48) > I suggest filing a new bug report with details of what/how does not compile > anymore. Perhaps it's easy to tweak. Ok.
[Bug other/60465] [4.9/5 Regression] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 The Written Word changed: What|Removed |Added CC||bugzilla-gcc@thewrittenword ||.com --- Comment #47 from The Written Word --- This patch caused a regression on HP-UX/IA between gcc-4.9.3 and gcc-4.9.4. Reverting the patch makes the build on this platform succeed for 4.9.4. However, considering this platform is probably not even actively maintained on GCC anymore, this report might be meaningless.
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #37 from The Written Word --- (In reply to The Written Word from comment #36) > I can build 4.9.3 on HP-UX 11.31/IA but not 4.9.4. So, looks like something > changed to break the build in 4.9.4. I reverted the patch for PR60465 and was able to build 4.9.4.
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #36 from The Written Word --- (In reply to The Written Word from comment #35) > I am trying to build 4.9.4 with a patched 4.7.4 and am running into the > following failure: > /opt/build/china/gcc-4.9.4/.obj/./gcc/xgcc > -B/opt/build/china/gcc-4.9.4/.obj/./gcc/ > -B/opt/build/gcc49/ia64-hp-hpux11.31/bin/ > -B/opt/build/gcc49/ia64-hp-hpux11.31/lib/ -isystem > /opt/build/gcc49/ia64-hp-hpux11.31/include -isystem > /opt/build/gcc49/ia64-hp-hpux11.31/sys-include-g -O2 -O2 -g -O2 > -DIN_GCC-DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wno-narrowing > -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -isystem ./include -g > -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -I. -I. -I../.././gcc > -I/opt/build/china/gcc-4.9.4/libgcc -I/opt/build/china/gcc-4.9.4/libgcc/. > -I/opt/build/china/gcc-4.9.4/libgcc/../gcc > -I/opt/build/china/gcc-4.9.4/libgcc/../include -DHAVE_CC_TLS -o emutls.o > -MT emutls.o -MD -MP -MF emutls.dep -fexceptions -c > /opt/build/china/gcc-4.9.4/libgcc/emutls.c -fvisibility=hidden -DHIDE_EXPORTS > /opt/build/china/gcc-4.9.4/libgcc/emutls.c: In function > '__emutls_get_address': > /opt/build/china/gcc-4.9.4/libgcc/emutls.c:188:1: internal compiler error: > in simplify_subreg, at simplify-rtx.c:5917 > } > ^ > > Should I build this with -O0 as well? I can build 4.9.3 on HP-UX 11.31/IA but not 4.9.4. So, looks like something changed to break the build in 4.9.4.
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #35 from The Written Word --- I am trying to build 4.9.4 with a patched 4.7.4 and am running into the following failure: /opt/build/china/gcc-4.9.4/.obj/./gcc/xgcc -B/opt/build/china/gcc-4.9.4/.obj/./gcc/ -B/opt/build/gcc49/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc49/ia64-hp-hpux11.31/lib/ -isystem /opt/build/gcc49/ia64-hp-hpux11.31/include -isystem /opt/build/gcc49/ia64-hp-hpux11.31/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -I. -I. -I../.././gcc -I/opt/build/china/gcc-4.9.4/libgcc -I/opt/build/china/gcc-4.9.4/libgcc/. -I/opt/build/china/gcc-4.9.4/libgcc/../gcc -I/opt/build/china/gcc-4.9.4/libgcc/../include -DHAVE_CC_TLS -o emutls.o -MT emutls.o -MD -MP -MF emutls.dep -fexceptions -c /opt/build/china/gcc-4.9.4/libgcc/emutls.c -fvisibility=hidden -DHIDE_EXPORTS /opt/build/china/gcc-4.9.4/libgcc/emutls.c: In function '__emutls_get_address': /opt/build/china/gcc-4.9.4/libgcc/emutls.c:188:1: internal compiler error: in simplify_subreg, at simplify-rtx.c:5917 } ^ Should I build this with -O0 as well?
[Bug fortran/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #1 from The Written Word --- I get a similar error with 8.1.0.
[Bug fortran/86599] New: Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599
Bug ID: 86599
Summary: Problems building libgfortran from 7.2.0 on HP-UX
11.31/PA
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzilla-gcc at thewrittenword dot com
Target Milestone: ---
I tried building gcc-7.2.0 on HP-UX 11.31/PA as follows:
$ gtar Jxf gcc-7.2.0.tar.xz
$ cd gcc-7.2.0
$ mkdir .obj
$ cd .obj
$ PATH=/opt/TWWfsw/gcc49/bin:$PATH ../configure \
SHELL=/opt/fsw/bash42/bin/bash --enable-nls --with-included-gettext \
--enable-shared --enable-languages=c,c++,fortran \
--with-gmp=/opt/TWWfsw/libgmp61 --with-isl=/opt/TWWfsw/libisl016 \
--with-mpc=/opt/TWWfsw/libmpc10 --with-mpfr=/opt/TWWfsw/libmpfr31 \
--with-gnu-as --with-as=/opt/TWWfsw/gcc7/hppa2.0-hp-hpux11.31/bin/as \
--with-local-prefix=/tmp/gcc7 --prefix=/tmp/gcc7
...
$ PATH=/opt/TWWfsw/gcc49/bin:$PATH \
ac_cv_prog_OBJCOPY="/opt/TWWfsw/gcc7/bin/gobjcopy" \
ac_cv_prog_OBJDUMP="/opt/TWWfsw/gcc7/bin/gobjdump" gmake
The build failed with the following:
libtool: compile: /opt/build/china/gcc-7.2.0/.obj/./gcc/xgcc
-B/opt/build/china
/gcc-7.2.0/.obj/./gcc/ -B/tmp/gcc7/hppa2.0w-hp-hpux11.31/bin/
-B/tmp/gcc7/hppa2.
0w-hp-hpux11.31/lib/ -isystem /tmp/gcc7/hppa2.0w-hp-hpux11.31/include -isystem
/
tmp/gcc7/hppa2.0w-hp-hpux11.31/sys-include -DHAVE_CONFIG_H -I.
-I/opt/build/chin
a/gcc-7.2.0/libgfortran -iquote/opt/build/china/gcc-7.2.0/libgfortran/io
-I/opt/
build/china/gcc-7.2.0/libgfortran/../gcc
-I/opt/build/china/gcc-7.2.0/libgfortran/../gcc/config
-I/opt/build/china/gcc-7.2.0/libgfortran/../libquadmath -I../.././gcc
-I/opt/build/china/gcc-7.2.0/libgfortran/../libgcc -I../libgcc
-I/opt/build/china/gcc-7.2.0/libgfortran/../libbacktrace -I../libbacktrace
-I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules -g -O2 -MT
read.lo -MD -MP -MF .deps/read.Tpo -c
/opt/build/china/gcc-7.2.0/libgfortran/io/read.c -fPIC -DPIC -o .libs/read.o
/opt/build/china/gcc-7.2.0/libgfortran/io/read.c: In function 'convert_real':
/opt/build/china/gcc-7.2.0/libgfortran/io/read.c:177:30: error: incompatible
types when assigning to type 'GFC_REAL_16 {aka long double}' from type
'long_double {aka struct }'
*((GFC_REAL_16*) dest) = gfc_strtold (buffer, );
^
gmake[3]: *** [read.lo] Error 1
gmake[3]: Leaving directory
`/opt/build/china/gcc-7.2.0/.obj/hppa2.0w-hp-hpux11.31/libgfortran'
I was able to build on HP-UX 11.23/PA.
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 --- Comment #11 from The Written Word --- (In reply to Jonathan Wakely from comment #7) > As I suspected, something is doing: > > #define fabsl(X) fabs((double) (X)) > #define acosl(X) acos((double) (X)) > etc. > > This would probably be solved by any fix for PR 79700, which would have to > add this to : > > #undef fabsl > > But I'm not sure when PR 79700 will get fixed. Is it just a matter of someone finding the time to fix 79700 or is it just too low a priority?
[Bug bootstrap/68663] Build failure on AIX 7.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68663 --- Comment #9 from The Written Word --- (In reply to David Edelsohn from comment #7) > I use GCC 4.6 to bootstrap. It appears that the error is caused by the > "system" bootstrap compiler, which I think is GCC 4.4 in your case. It is > generating code with too large displacements. > > Also, some of the configure options are unusual. Ok, will try something later than 4.4. Thanks.
[Bug bootstrap/68663] Build failure on AIX 7.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68663 --- Comment #8 from The Written Word --- (In reply to The Written Word from comment #6) > gcc-5.5.0 and 7.2.0 errored out in the same way but I am able to build > gcc-8.1.0 successfully. gcc-6.4.0 seems to have built insn-output.c > successfully. gcc-6.4.0 just died somewhere else with the same error: g++ -std=gnu++98 -fno-PIE -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasync hronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing -format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-ma cros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/opt/build/c hina/gcc-6.4.0/gcc -I/opt/build/china/gcc-6.4.0/gcc/. -I/opt/build/china/gcc-6.4 .0/gcc/../include -I./../intl -I/opt/build/china/gcc-6.4.0/gcc/../libcpp/include -I/opt/TWWfsw/libgmp61/include -I/opt/TWWfsw/libmpfr31/include -I/opt/TWWfsw/li bmpc10/include -I/opt/build/china/gcc-6.4.0/gcc/../libdecnumber -I/opt/build/ch ina/gcc-6.4.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/opt/build/china/gcc-6 .4.0/gcc/../libbacktrace -I/opt/TWWfsw/libisl016/include -o rs6000.o -MT rs6000 .o -MMD -MP -MF ./.deps/rs6000.TPo /opt/build/china/gcc-6.4.0/gcc/config/rs6000/ rs6000.c /tmp//ccsn8s2Z.s: Assembler messages: /tmp//ccsn8s2Z.s:177152: Error: value of 0001 too large for field of 2 bytes at 0007e722 /tmp//ccsn8s2Z.s:177680: Error: value of 00010004 too large for field of 2 bytes at 0007ed12 /tmp//ccsn8s2Z.s:178850: Error: value of 00010008 too large for field of 2 bytes at 0007fb5e /tmp//ccsn8s2Z.s:179521: Error: value of 0001000c too large for field of 2 bytes at 00080246 ...
[Bug bootstrap/68663] Build failure on AIX 7.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68663 --- Comment #6 from The Written Word --- (In reply to David Edelsohn from comment #5) > GCC 4.9 is quite old now and out of service. If there is a bug in GCC 4.9, > it will not be fixed because there are no bug fix releases planned. Understood. > You never showed an example of the assembly line representing the error > message to allow someone to observe the exact assembly instruction and > operands in question. I've attached insn-output.s. Looks like the problematic lines are of the form: bl ._Z17gen_rtx_CONST_INT12machine_modex nop mr 0,3 stw 0,0(28) .line 3466 lwz 0,LC..1(2) <-- line 1361 .eb 3466 .line 3468 mr 3,0 addi 1,31,96 ... bl ._Z17gen_rtx_CONST_INT12machine_modex nop mr 0,3 stw 0,0(28) .line 14 lwz 0,LC..2(2) <-- line 1495 .eb 14 .line 16 mr 3,0 addi 1,31,96 ... bl ._Z17gen_rtx_CONST_INT12machine_modex nop mr 0,3 stw 0,0(28) .line 14 lwz 0,LC..3(2) <-- line 1628 .eb 14 .line 16 mr 3,0 addi 1,31,96 gcc-5.5.0 and 7.2.0 errored out in the same way but I am able to build gcc-8.1.0 successfully. gcc-6.4.0 seems to have built insn-output.c successfully.
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 --- Comment #10 from The Written Word --- (In reply to Jonathan Wakely from comment #8) > Created attachment 44406 [details] > Undefine macros for long double math functions > > Does this fix the build? I am trying a similar patch. I basically #undef'd everything to get a clean build of that file and restarted the build from scratch so we'll see.
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 --- Comment #9 from The Written Word --- (In reply to Jonathan Wakely from comment #7) > As I suspected, something is doing: > > #define fabsl(X) fabs((double) (X)) > #define acosl(X) acos((double) (X)) > etc. /usr/include/math.h on this platform has: #ifdef _ISOC99_SOURCE #ifdef __LONGDOUBLE128 ... #else ... #define acosl(__x) acos((double) (__x)) #define fabsl(__x) fabs((double) (__x)) ... #endif
[Bug bootstrap/68663] Build failure on AIX 7.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68663 --- Comment #4 from The Written Word --- (In reply to The Written Word from comment #3) > (In reply to David Edelsohn from comment #2) > > Group Bull, Perzl, and I have been able to build it. Are you using an up to > > date AIX Assembler? > > Hmm. Let me try upgrading. Thanks. I upgraded the system to the following: $ oslevel -s 7100-04-05-1720 $ lslpp -h bos.rte.bind_cmds Fileset Level Action Status Date Time Path: /usr/lib/objrepos bos.rte.bind_cmds 7.1.0.0 COMMIT COMPLETE 11/13/10 21:01:20 7.1.0.15 COMMIT COMPLETE 06/18/12 19:54:09 7.1.0.16 COMMIT COMPLETE 10/12/16 21:23:45 7.1.2.19 COMMIT COMPLETE 10/17/16 20:41:47 7.1.3.47 COMMIT COMPLETE 07/10/18 21:18:33 7.1.4.32 APPLYCOMPLETE 07/10/18 21:31:27 Path: /etc/objrepos bos.rte.bind_cmds 7.1.0.0 COMMIT COMPLETE 11/13/10 21:01:20 7.1.0.15 COMMIT COMPLETE 06/18/12 19:54:10 7.1.0.16 COMMIT COMPLETE 10/12/16 21:23:45 7.1.2.19 COMMIT COMPLETE 10/17/16 20:41:47 7.1.3.47 COMMIT COMPLETE 07/10/18 21:18:33 7.1.4.32 APPLYCOMPLETE 07/10/18 21:31:29 I built gcc-4.9.4 and I still get the error: g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables - W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -peda ntic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -D HAVE_CONFIG_H -I. -I. -I/opt/build/china/gcc-4.9.4/gcc -I/opt/build/china/gcc-4. 9.4/gcc/. -I/opt/build/china/gcc-4.9.4/gcc/../include -I./../intl -I/opt/build/c hina/gcc-4.9.4/gcc/../libcpp/include -I/opt/TWWfsw/libgmp61/include -I/opt/TWWfs w/libmpfr31/include -I/opt/TWWfsw/libmpc10/include -I/opt/build/china/gcc-4.9.4 /gcc/../libdecnumber -I/opt/build/china/gcc-4.9.4/gcc/../libdecnumber/dpd -I../l ibdecnumber -I/opt/build/china/gcc-4.9.4/gcc/../libbacktrace -DCLOOG_INT_GMP -I/ opt/TWWfsw/libcloog018/include -I/opt/TWWfsw/libisl015/include -o insn-output.o -MT insn-output.o -MMD -MP -MF ./.deps/insn-output.TPo insn-output.c /tmp//ccGCJgTB.s: Assembler messages: /tmp//ccGCJgTB.s:1361: Error: value of 00012990 too large for field of 2 bytes at 046e /tmp//ccGCJgTB.s:1495: Error: value of 00012990 too large for field of 2 bytes at 05ee /tmp//ccGCJgTB.s:1628: Error: value of 00012990 too large for field of 2 bytes at 0772 /tmp//ccGCJgTB.s:1761: Error: value of 00012990 too large for field of 2 bytes at 08f6 /tmp//ccGCJgTB.s:1913: Error: value of 00012994 too large for field of 2 bytes at 0aa6 /tmp//ccGCJgTB.s:2047: Error: value of 00012990 too large for field of 2 bytes at 0c2a /tmp//ccGCJgTB.s:2183: Error: value of 00012990 too large for field of 2 bytes at 0db6 /tmp//ccGCJgTB.s:2289: Error: value of 00012998 too large for field of 2 bytes at 0eca ... I was able to build gcc-8.1.0 on this system. Trying gcc-5.5.0, 6.4.0, and 7.2.0 now.
[Bug bootstrap/86559] Build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86559 --- Comment #3 from The Written Word --- (In reply to Jonathan Wakely from comment #2) > (In reply to The Written Word from comment #1) > > Might be a duplicate of PR64081. > > Wrong bug number? I was looking at bug 64081 comment 31.
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 --- Comment #5 from The Written Word --- Created attachment 44405 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44405=edit Preprocessed source for math_stubs_long_double.cc
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 --- Comment #2 from The Written Word --- gcc-6.4.0 on AIX 5.3 exhibits a similar failure.
[Bug c/86559] Build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86559 --- Comment #1 from The Written Word --- Might be a duplicate of PR64081.
[Bug c/86559] New: Build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86559 Bug ID: 86559 Summary: Build failure on AIX 5.3 Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bugzilla-gcc at thewrittenword dot com Target Milestone: --- I tried building gcc-7.2.0 on AIX 5.3 as follows: $ gtar Jxf gcc-7.2.0.tar.xz $ cd gcc-7.2.0 $ mkdir .obj $ cd .obj $ PATH=/opt/TWWfsw/gcc47/bin:$PATH LDR_CNTRL=MAXDATA=0x7000 \ ../configure SHELL=/opt/fsw/bash42/bin/bash LDFLAGS="-Wl,-brtl \ -Wl,-blibpath:/opt/TWWfsw/libisl016/lib:/opt/TWWfsw/libgmp61/lib:\ /opt/TWWfsw/libmpc10/lib:/opt/TWWfsw/libmpfr31/lib:/usr/lib" \ --enable-nls --with-included-gettext --enable-shared \ --enable-threads --enable-languages=c,c++ \ --with-gmp=/opt/TWWfsw/libgmp61 --with-isl=/opt/TWWfsw/libisl016 \ --with-mpc=/opt/TWWfsw/libmpc10 --with-mpfr=/opt/TWWfsw/libmpfr31 \ --with-local-prefix=/tmp/gcc7 --prefix=/tmp/gcc7 ... $ PATH=/opt/TWWfsw/gcc47/bin:$PATH LDR_CNTRL=MAXDATA=0x7000 gmake The build failed with the following: g++ -std=gnu++98-g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-array-notation.o c/c-fold.o c/gimple-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-cilkplus.o c-family/array-notation-common.o c-family/cilk.o c-family/c-ubsan.o c-family/c-attribs.o c-family/c-warn.o default-c.o rs6000-c.o \ cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/opt/TWWfsw/libisl016/lib -lisl -L/opt/TWWfsw/libgmp61/lib -L/opt/TWWfsw/libmpfr31/lib -L/opt/TWWfsw/libmpc10/lib -lmpc -lmpfr -lgmp -L./../zlib -lz ld: 0711-783 WARNING: TOC overflow. TOC size: 207328Maximum size: 65536 Extra instructions are being generated for each reference to a TOC symbol if the symbol is in the TOC overflow area. ld: 0711-380 STABSTRING ERROR: Symbol table entry 953, object file attribs.o Length of stabstring in .debug section is invalid. The stabstring is being deleted. ld: 0711-380 STABSTRING ERROR: Symbol table entry 1587, object file c/c-decl.o Length of stabstring in .debug section is invalid. The stabstring is being deleted. ld: 0711-380 STABSTRING ERROR: Symbol table entry 1604, object file c/c-typeck.o Length of stabstring in .debug section is invalid. The stabstring is being deleted. ld: 0711-380 STABSTRING ERROR: Symbol table entry 761, object file c/c-convert.o Length of stabstring in .debug section is invalid. The stabstring is being deleted. ld: 0711-380 STABSTRING ERROR: Symbol table entry 1533, object file c/c-parser.o Length of stabstring in .debug section is invalid. The stabstring is being deleted. ... collect2: error: ld returned 12 exit status gmake[3]: *** [cc1] Error 1 gmake[3]: Leaving directory `/opt/build/china/gcc-7.2.0/.obj/gcc' gmake[2]: *** [all-stage1-gcc] Error 2 gmake[2]: Leaving directory `/opt/build/china/gcc-7.2.0/.obj' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/opt/build/china/gcc-7.2.0/.obj' gmake: *** [all] Error 2 Some info about this system: $ oslevel -s 5300-11-08-1140 $ lslpp -h bos.rte.bind_cmds Fileset Level Action Status Date Time Path: /usr/lib/objrepos bos.rte.bind_cmds 5.3.0.50 COMMIT COMPLETE 01/13/07 19:57:05 5.3.0.51 COMMIT COMPLETE 01/14/07 19:44:07 5.3.8.0 COMMIT COMPLETE 09/05/08 08:06:25 5.3.8.2 COMMIT COMPLETE 09/05/08 08:29:06 5.3.11.4 COMMIT COMPLETE 06/18/12 16:56:58 5.3.11.7 APPLYCOMPLETE 06/18/12 17:28:20
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 --- Comment #1 from The Written Word --- I get a similar failure on AIX 5.2 with gcc-7.2.0 and gcc-8.1.0.
[Bug libstdc++/86553] New: libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553
Bug ID: 86553
Summary: libstdc++-v3 build failure on AIX 5.3
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzilla-gcc at thewrittenword dot com
Target Milestone: ---
I tried building gcc-8.1.0 on AIX 5.3 as follows:
$ gtar Jxf gcc-8.1.0.tar.xz
$ cd gcc-8.1.0
$ mkdir .obj
$ cd .obj
$ PATH=/opt/TWWfsw/gcc47/bin:$PATH LDR_CNTRL=MAXDATA=0x7000 \
../configure SHELL=/opt/fsw/bash42/bin/bash LDFLAGS="-Wl,-brtl \
-Wl,-blibpath:/opt/TWWfsw/libisl016/lib:/opt/TWWfsw/libgmp61/lib:\
/opt/TWWfsw/libmpc10/lib:/opt/TWWfsw/libmpfr31/lib:/usr/lib" \
--enable-nls --with-included-gettext --enable-shared \
--enable-threads --enable-languages=c,c++ \
--with-gmp=/opt/TWWfsw/libgmp61 --with-isl=/opt/TWWfsw/libisl016 \
--with-mpc=/opt/TWWfsw/libmpc10 --with-mpfr=/opt/TWWfsw/libmpfr31 \
--with-local-prefix=/tmp/gcc8 --prefix=/tmp/gcc8
$ PATH=/opt/TWWfsw/gcc47/bin:$PATH LDR_CNTRL=MAXDATA=0x7000 gmake
The build failed with the following:
/opt/fsw/bash42/bin/bash ../../libtool --tag CXX --tag disable-shared
--mode=compile /opt/build/china/gcc-8.1.0/.obj/./gcc/xgcc -shared-libgcc
-B/opt/build/china/gcc-8.1.0/.obj/./gcc -nostdinc++
-L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/src
-L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/src/.libs
-L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/libsupc++/.libs
-B/tmp/gcc8/powerpc-ibm-aix5.3.11.0/bin/
-B/tmp/gcc8/powerpc-ibm-aix5.3.11.0/lib/ -isystem
/tmp/gcc8/powerpc-ibm-aix5.3.11.0/include -isystem
/tmp/gcc8/powerpc-ibm-aix5.3.11.0/sys-include
-I/opt/build/china/gcc-8.1.0/libstdc++-v3/../libgcc
-I/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/include/powerpc-ibm-aix5.3.11.0
-I/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/include
-I/opt/build/china/gcc-8.1.0/libstdc++-v3/libsupc++ -std=gnu++98 -prefer-pic
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=math_stubs_long_double.lo -g -O2 -c -o
math_stubs_long_double.lo
/opt/build/china/gcc-8.1.0/libstdc++-v3/src/c++98/math_stubs_long_double.cc
libtool: compile: /opt/build/china/gcc-8.1.0/.obj/./gcc/xgcc -shared-libgcc
-B/opt/build/china/gcc-8.1.0/.obj/./gcc -nostdinc++
-L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/src
-L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/src/.libs
-L/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/libsupc++/.libs
-B/tmp/gcc8/powerpc-ibm-aix5.3.11.0/bin/
-B/tmp/gcc8/powerpc-ibm-aix5.3.11.0/lib/ -isystem
/tmp/gcc8/powerpc-ibm-aix5.3.11.0/include -isystem
/tmp/gcc8/powerpc-ibm-aix5.3.11.0/sys-include
-I/opt/build/china/gcc-8.1.0/libstdc++-v3/../libgcc
-I/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/include/powerpc-ibm-aix5.3.11.0
-I/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/include
-I/opt/build/china/gcc-8.1.0/libstdc++-v3/libsupc++ -std=gnu++98
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi -fdiagnosti
cs-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=math_stubs_long_double.lo -g -O2 -c
/opt/build/china/gcc-8.1.0/libstdc++-v3/src/c++98/math_stubs_long_double.cc
-fPIC -DPIC -D_GLIBCXX_SHARED -o math_stubs_long_double.o
In file included from
/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++v3/include/cmath:45,
from
/opt/build/china/gcc-8.1.0/libstdc++-v3/src/c++98/math_stubs_long_double.cc:25:
/opt/build/china/gcc-8.1.0/libstdc++-v3/src/c++98/math_stubs_long_double.cc:35:3:
error: 'long double fabs' redeclared as different kind of symbol
fabsl(long double x)
^
/opt/build/china/gcc-8.1.0/.obj/gcc/include-fixed/math.h:312:16: note: previous
declaration 'double fabs(double)'
extern double fabs(double);
^~~~
/opt/build/china/gcc-8.1.0/libstdc++-v3/src/c++98/math_stubs_long_double.cc:35:9:
error: expected primary-expression before 'long'
fabsl(long double x)
^~~~
/opt/build/china/gcc-8.1.0/libstdc++-v3/src/c++98/math_stubs_long_double.cc:35:9:
error: expected ')' before 'long'
/opt/build/china/gcc-8.1.0/libstdc++-v3/src/c++98/math_stubs_long_double.cc:35:3:
note: to match this '('
fabsl(long double x)
^
gmake[6]: *** [math_stubs_long_double.lo] Error 1
gmake[6]: Leaving directory
`/opt/build/china/gcc-8.1.0/.obj/powerpc-ibm-aix5.3.11.0/libstdc++-v3/src/c++98'
gmake[5]: *** [all-recursive] Error 1
[Bug bootstrap/82688] Bootstrap comparison failure on Solaris 10/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82688 --- Comment #3 from The Written Word --- (In reply to Eric Botcazou from comment #2) > The search button is your friend. > > *** This bug has been marked as a duplicate of bug 81926 *** Oops, thanks.
