[Bug c++/111034] New: Precompiled headers still non-deterministic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111034 Bug ID: 111034 Summary: Precompiled headers still non-deterministic Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: skunk at iskunk dot org Target Milestone: --- This is a follow-on of bug #92717. In that bug, it was noted that .gch files are basically GCC memory dumps, and that because ASLR is typically enabled on modern Linux systems, this results in non-deterministic output every time such a file is generated. The solution given was to disable ASLR, e.g. by using "setarch -R". And I confirmed that if I generate the same .gch file multiple times in a tight loop with ASLR disabled, every file comes out identical. That was only a test, however. My production fix was to disable ASLR for the entire build process, with "setarch -R make bootstrap". And that yielded much spottier results. After multiple attempts, maybe 10% of the pairs of bootstraps that I ran came out with identical .gch files. And that was running on the same container host---if I tried the build in the same container architecture/environment but a different host, the files would end up different as a matter of course. I think, in the interests of reproducibility, the way .gch files are generated needs to be reworked in a way that does not depend on the runtime environment. The current approach may be fine for PCH purposes, but the security implications of any opaque non-determinism will only get worse with time.
[Bug c++/111033] New: libcody build does not use AR_FLAGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111033 Bug ID: 111033 Summary: libcody build does not use AR_FLAGS Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: skunk at iskunk dot org Target Milestone: --- I am working on getting a reproducible GCC build. This includes passing the "D" option to ar(1) to avoid non-deterministic static library outputs. In bootstrapping 13.2.0, I noticed that libcody.a was not being generated consistently. The libcody makefile has the following: AR := @AR@ ... $(AR) -cr $@ $^ For comparison, in the rest of the GCC tree, you typically see AR = @AR@ AR_FLAGS = rc ... $(AR) $(AR_FLAGS) libfoo.a ... and AR_FLAGS is the natural place to add additional flags. An AR_FLAGS variable should thus likewise be added to the libcody makefile. (ARFLAGS is also used; I am not entirely sure which form is favored.) Beyond addressing this small inconsistency, it would be good to see the GCC build itself check whether ar(1) supports the "D" flag, and add it automatically if so.
[Bug tree-optimization/106247] GCC12 warning in Eigen: array subscript is partly outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106247 Daniel Richard G. changed: What|Removed |Added CC||skunk at iskunk dot org --- Comment #4 from Daniel Richard G. --- I am seeing what may be the same issue in a different context. This is occurring in a proprietary C source codebase newly being compiled with 12.1.0, and unfortunately the problem goes away if I attempt to cut it down to a minimal test case. Nevertheless, the actual issue is quite simple, and IMO clear-cut. (some names edited to protect the guilty) In file included from /usr/include/string.h:375, from foo.c:7: In function 'function3', inlined from 'function2' at foo.c:1206:5, inlined from 'function1' at foo.c:2840:7: foo.c:415:3: error: array subscript 'union [1]' is partly outside array bounds of 'unsigned char[5]' [-Werror=array-bounds] 415 | memset(constraints,0,sizeof(char)*NB_CONSTRAINTS); | ^~ foo.c: In function 'function1': foo.c:380:17: note: at offset 4 into object 'constraints' of size 5 380 | unsigned char constraints[NB_CONSTRAINTS]; | ^~~~ cc1: all warnings being treated as errors Curiously enough, I only see this issue in an i686 build. I don't get it on x86-64. (Dropping -march=i686 does not help.)
[Bug libstdc++/106501] New: libstdc++ is built without -fPIC despite --with-pic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106501 Bug ID: 106501 Summary: libstdc++ is built without -fPIC despite --with-pic Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: skunk at iskunk dot org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Build: x86_64-pc-linux-gnu I bootstrapped GCC 12.1.0 with the following options: --disable-shared --disable-nls --enable-version-specific-runtime-libs --with-pic --disable-multilib --with-arch=opteron --disable-libsanitizer --disable-libcc1 --enable-languages=c,c++,lto Notable is the combination of "--disable-shared --with-pic", with the intention of having all the GCC support libraries be statically linkable when building executables, shared libraries, etc. Once the bootstrap was complete, I used the new GCC to build a current version of GDB. That build failed with CXXLD libinproctrace.so /usr/bin/ld: /opt/sfw/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/libstdc++.a(class_type_info.o): relocation R_X86_64_32S against `_ZTVN10__cxxabiv117__class_type_infoE' can not be used when making a shared object; recompile with -fPIC /opt/sfw/bin/../lib/gcc/x86_64-pc-linux-gnu/12.1.0/libstdc++.a: could not read symbols: Bad value collect2: error: ld returned 1 exit status gmake[2]: *** [Makefile:383: libinproctrace.so] Error 1 gmake[2]: Leaving directory '/tmp/gdb-12.1-build/gdbserver' gmake[1]: *** [Makefile:11743: all-gdbserver] Error 2 gmake[1]: Leaving directory '/tmp/gdb-12.1-build' gmake: *** [Makefile:1001: all] Error 2 I checked the build log for GCC. None of the compile lines for class_type_info.o include the -fPIC option (i.e. "fgrep class_type_info.o gcc12-build-log.txt | grep -c PIC" yields 0). The --with-pic option should cause all libraries to be built with -fPIC, even when they are built as static archives. It is possible that libstdc++ is not the only library that was built incorrectly; it is only the one I noticed. Related: bug #66955, bug #67128
[Bug bootstrap/106482] [12 Regression] bootstrap of 12.1.0 using 4.8.2 fails with C++ errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106482
--- Comment #2 from Daniel Richard G. ---
It would be good to have a specific minimum version of GCC in the documented
prerequisites, as the current text ("an existing GCC binary (version 4.8 or
later)", albeit referring to non-bootstrap builds) misses edge cases like this.
[Bug bootstrap/106482] New: [12 Regression] bootstrap of 12.1.0 using 4.8.2 fails with C++ errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106482 Bug ID: 106482 Summary: [12 Regression] bootstrap of 12.1.0 using 4.8.2 fails with C++ errors Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: skunk at iskunk dot org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Build: x86_64-pc-linux-gnu I attempted to bootstrap 12.1.0 using GCC 4.8.2. The documented prerequisites include an "ISO C++11 compiler," so this appears to be a supported arrangement. GCC 12 was configured with --disable-shared --disable-nls --enable-version-specific-runtime-libs --with-pic --disable-multilib --with-arch=opteron --disable-libcc1 --enable-languages=c,c++,lto The bootstrap failed as shown below. I was able to bootstrap 10.2.0 using the original compiler, and then bootstrapped 12.1.0 with that intermediary. tg-g++ -std=c++11 -fno-PIE -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/home/src/gcc-12.1.0/gcc -I/home/src/gcc-12.1.0/gcc/. -I/home/src/gcc-12.1.0/gcc/../include -I/home/src/gcc-12.1.0/gcc/../libcpp/include -I/home/src/gcc-12.1.0/gcc/../libcody -I/home/sfw/arch/linux64/include -I/home/sfw/arch/linux64/include -I/home/sfw/arch/linux64/include -I/home/src/gcc-12.1.0/gcc/../libdecnumber -I/home/src/gcc-12.1.0/gcc/../libdecnumber/bid -I../libdecnumber -I/home/src/gcc-12.1.0/gcc/../libbacktrace -o fwprop.o -MT fwprop.o -MMD -MP -MF ./.deps/fwprop.TPo /home/src/gcc-12.1.0/gcc/fwprop.cc In file included from /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:491:0, from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45, from /home/src/gcc-12.1.0/gcc/fwprop.cc:29: /home/src/gcc-12.1.0/gcc/splay-tree-utils.tcc:24:1: error: prototype for 'typename base_splay_tree::node_type base_splay_tree::get_child(typename Accessors::node_type, unsigned int)' does not match any in class 'base_splay_tree' base_splay_tree::get_child (node_type node, unsigned int index) ^ In file included from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45:0, from /home/src/gcc-12.1.0/gcc/fwprop.cc:29: /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:125:20: error: candidate is: static typename Accessors::node_type base_splay_tree::get_child(typename Accessors::node_type, unsigned int) static node_type get_child (node_type, unsigned int); ^ In file included from /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:491:0, from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45, from /home/src/gcc-12.1.0/gcc/fwprop.cc:29: /home/src/gcc-12.1.0/gcc/splay-tree-utils.tcc:49:1: error: prototype for 'typename base_splay_tree::node_type base_splay_tree::promote_child(typename Accessors::node_type, unsigned int)' does not match any in class 'base_splay_tree' base_splay_tree::promote_child (node_type node, unsigned int index) ^ In file included from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45:0, from /home/src/gcc-12.1.0/gcc/fwprop.cc:29: /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:128:15: error: candidates are: static void base_splay_tree::promote_child(typename Accessors::node_type, unsigned int, typename Accessors::node_type) static void promote_child (node_type, unsigned int, node_type); ^ /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:127:20: error: static typename Accessors::node_type base_splay_tree::promote_child(typename Accessors::node_type, unsigned int) static node_type promote_child (node_type, unsigned int); ^ In file included from /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:491:0, from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45, from /home/src/gcc-12.1.0/gcc/fwprop.cc:29: /home/src/gcc-12.1.0/gcc/splay-tree-utils.tcc:187:1: error: prototype for 'typename base_splay_tree::node_type base_splay_tree::splay_limit(typename Accessors::node_type)' does not match any in class 'base_splay_tree' base_splay_tree::splay_limit (node_type start) ^ In file included from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45:0, from /home/src/gcc-12.1.0/gcc/fwprop.cc:29: /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:131:20: error: candidate is: template template static typename Accessors::node_type base_splay_tree::splay_limit(typename Accessors::node_type) static node_type splay_limit (node_type); ^ In file included from /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:491:0, f
[Bug other/91139] Attempts, fails to rebuild doc/gcc.info in tarball release build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91139 --- Comment #4 from Daniel Richard G. --- (In reply to Martin Liška from comment #3) > > So is the issue fixed or not? Not fixed as of 9.2.0, I'm afraid: [...] if [ xinfo = xinfo ]; then \ makeinfo --split-size=500 --split-size=500 --split-size=500 --no-split -I . -I ../../gcc--9.2.0/gcc/doc \ -I ../../gcc--9.2.0/gcc/doc/include -o doc/cpp.info ../../gcc--9.2.0/gcc/doc/cpp.texi; \ fi if [ xinfo = xinfo ]; then \ makeinfo --split-size=500 --split-size=500 --split-size=500 --no-split -I . -I ../../gcc--9.2.0/gcc/doc \ -I ../../gcc--9.2.0/gcc/doc/include -o doc/gcc.info ../../gcc--9.2.0/gcc/doc/gcc.texi; \ fi ../../gcc--9.2.0/gcc/doc//invoke.texi:1783: @include `/users/cport/tmp/gcc-build/gcc/../../gcc-9.2.0/gcc/../libiberty/at-file.texi': No such file or directory. ../../gcc--9.2.0/gcc/doc//extend.texi:7097: warning: `.' or `,' must follow @xref, not `f'. ../../gcc--9.2.0/gcc/doc//extend.texi:8181: warning: `.' or `,' must follow @xref, not `f'. makeinfo: Removing output file `doc/gcc.info' due to errors; use --force to preserve. Makefile:3228: recipe for target 'doc/gcc.info' failed gmake[3]: *** [doc/gcc.info] Error 1 gmake[3]: Leaving directory '/home/skunk/tmp/gcc-build/gcc' Makefile:4661: recipe for target 'all-stage1-gcc' failed gmake[2]: *** [all-stage1-gcc] Error 2 gmake[2]: Leaving directory '/home/skunk/tmp/gcc-build' Makefile:22313: recipe for target 'stage1-bubble' failed gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory '/home/skunk/tmp/gcc-build' Makefile:22649: recipe for target 'bootstrap' failed gmake: *** [bootstrap] Error 2 (Note the reference to "gcc-9.2.0" when the actual path is "gcc--9.2.0")
[Bug tree-optimization/91555] [9.2 regression] Optimizer bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555 --- Comment #10 from Daniel Richard G. --- Okay. I'll accept that the code is dodgy. Thanks for looking into this. I'll keep in mind -fsanitize=undefined as a way of tracking down these issues in the future.
[Bug tree-optimization/91555] [9.2 regression] Optimizer bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555 --- Comment #8 from Daniel Richard G. --- The most I could tell via strategic printf() calls is that everything appears to run correctly up until the binary search. I don't think any (unchecked) overflow is at issue, but it seems I don't have a way of instrumenting the program to check for that...
[Bug tree-optimization/91555] [9.2 regression] Optimizer bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555 --- Comment #6 from Daniel Richard G. --- Unfortunately, this GCC build does not have libsanitizer, as it is on an older (Linux) system without the necessary system headers. $ gcc -O2 -fsanitize=undefined gcc9-opt-bug.c -o bug /usr/bin/ld: cannot find -lubsan collect2: error: ld returned 1 exit status (I get a similar error on the Solaris system.) Are you able to reproduce the -O1/-O2 split in behavior?
[Bug tree-optimization/91555] [9.2 regression] Optimizer bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555 --- Comment #4 from Daniel Richard G. --- Yes, that is the case: $ gcc -O2 gcc9-opt-bug.c -o bug $ ./bug WRONG 13 result: t = 18446744073709551615 (wrong) $ gcc -O2 -fwrapv gcc9-opt-bug.c -o bug $ ./bug result: t = 1009489458 (correct)
[Bug tree-optimization/91555] [9.2 regression] Optimizer bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555 Daniel Richard G. changed: What|Removed |Added Attachment #46761|0 |1 is obsolete|| --- Comment #2 from Daniel Richard G. --- Created attachment 46762 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46762&action=edit Revised version of test program Hi Andrew, I revised the test program with the current version of those two functions. The erroneous behavior w.r.t. optimization is unchanged. >From what poking around I could do, the problem appears to occur in the binary search in time2sub(), which is why making the lo/hi variables volatile appears to straighten things out.
[Bug tree-optimization/91555] New: [9.2 regression] Optimizer bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555 Bug ID: 91555 Summary: [9.2 regression] Optimizer bug Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: skunk at iskunk dot org Target Milestone: --- Created attachment 46761 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46761&action=edit Quasi-minimal test program I have encountered what appears to be a bug in the optimizer of GCC 9.2.0. (I am unclear as to whether it is the tree optimizer or RTL optimizer that is at issue; please recategorize as appropriate.) The problem occurs inside some timezone-handling code that is part of a larger project. I have extracted the code into a program that may not be a minimal test case, but nevertheless exhibits the problem. This incorrect optimization has been observed in x86-64 builds on both Linux and Solaris. Correct result: $ gcc -O1 gcc9-opt-bug.c -o bug $ ./bug result: t = 1009489458 (correct) Wrong result: $ gcc -O2 gcc9-opt-bug.c -o bug $ ./bug WRONG 13 result: t = 18446744073709551615 Workaround using "volatile" keyword: $ gcc -O2 -DUSE_VOLATILE gcc9-opt-bug.c -o bug $ ./bug result: t = 1009489458 (correct) This code was correctly optimized by GCC 4.8.1, so this appears to be a regression.
[Bug bootstrap/65725] Bootstrap errors on Solaris 10 x86-64, including object diffs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65725 Daniel Richard G. changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Daniel Richard G. --- I have attempted a bootstrap of 9.2.0 on this same system again, and am happy to report that it now completes successfully, modulo bug #55930. Specifically, * The libgcc-unwind.map error no longer occurs, despite my use of --disable-shared; * The object diffs no longer arise, even though I am continuing to use /usr/ccs/bin/as and /usr/ccs/bin/ld . These issues appear to have been fixed by-the-by since this bug was originally filed, so I am closing accordingly.
[Bug other/91139] Attempts, fails to rebuild doc/gcc.info in tarball release build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91139 --- Comment #2 from Daniel Richard G. --- (In reply to Richard Biener from comment #1) > Maybe your NFS servers time is different from the local build ones so make > gets confused as to what is new? That said, I've never seen Bug-1 but I also > do not build with source on NFS. For confirmation, I attempted a bootstrap with the source tree on local disk. It appears that doc/gcc.info continues to be regenerated in the same manner. (If NFS timestamp shenanigans were at issue, I'd have expected to see much more widespread breakage)
[Bug other/91139] New: Attempts, fails to rebuild doc/gcc.info in tarball release build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91139
Bug ID: 91139
Summary: Attempts, fails to rebuild doc/gcc.info in tarball
release build
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: skunk at iskunk dot org
Target Milestone: ---
There may be one or two bugs in this report.
I am bootstrapping from a release tarball on a Solaris system. The system has
makeinfo 4.7 installed, which the GCC configure script finds.
At a certain point in the build, I get this error:
[...]
(echo "@set version-GCC 9.1.0"; \
if [ "" = "experimental" ]; \
then echo "@set DEVELOPMENT"; \
else echo "@clear DEVELOPMENT"; \
fi) > gcc-vers.texiT
echo @set srcdir /nfs/gnu/src/gcc/gcc--9.1.0/gcc >> gcc-vers.texiT
if [ -n "(GCC) " ]; then \
echo "@set VERSION_PACKAGE (GCC) " >> gcc-vers.texiT; \
fi
echo "@set BUGURL @uref{https://gcc.gnu.org/bugs/}"; >> gcc-vers.texiT; \
mv -f gcc-vers.texiT gcc-vers.texi
if [ xinfo = xinfo ]; then \
/nfs/gnu/src/gcc/gcc--9.1.0/missing makeinfo --split-size=500
--split-size=500 --split-size=500 --no-split -I . -I
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc \
-I /nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc/include -o doc/cpp.info
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc/cpp.texi; \
fi
if [ xinfo = xinfo ]; then \
/nfs/gnu/src/gcc/gcc--9.1.0/missing makeinfo --split-size=500
--split-size=500 --split-size=500 --no-split -I . -I
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc \
-I /nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc/include -o doc/gcc.info
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc/gcc.texi; \
fi
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc//invoke.texi:1783: @include
`/nfs/gnu/src/gcc/gcc-9.1.0/gcc/../libiberty/at-file.texi': No such file or
directory.
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc//extend.texi:7097: warning: `.' or `,' must
follow @xref, not `f'.
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc//extend.texi:8181: warning: `.' or `,' must
follow @xref, not `f'.
makeinfo: Removing output file `doc/gcc.info' due to errors; use --force to
preserve.
Makefile:3228: recipe for target 'doc/gcc.info' failed
gmake[3]: *** [doc/gcc.info] Error 1
gmake[3]: Leaving directory '/tmp/gcc--9.1.0.build/gcc'
Makefile:4661: recipe for target 'all-stage1-gcc' failed
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory '/tmp/gcc--9.1.0.build'
Makefile:22313: recipe for target 'stage1-bubble' failed
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory '/tmp/gcc--9.1.0.build'
Makefile:22660: recipe for target 'bootstrap-lean' failed
gmake: *** [bootstrap-lean] Error 2
Bug-1 is that the build is attempting to rebuild an info file, which should not
even be happening in the first place with an unmodified release tarball.
Bug-2 is the "No such file" error, which appears to be due to Texinfo syntax
processing erroneously being applied to the file path (note how "gcc--9.1.0"
becomes "gcc-9.1.0", despite only the former being valid for this build).
The second bug would be moot if not for the first.
[Bug libstdc++/58638] libstdc++ builds as non-PIC when --with-pic is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638 --- Comment #12 from Daniel Richard G. --- This issue appears to persist in 9.1.0, where it prevents bootstrap from completing: [...] libtool: link: /tmp/gcc-9.1.0.build/./gcc/xg++ -B/tmp/gcc-9.1.0.build/./gcc/ -nostdinc++ -nostdinc++ -I/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/src/gcc/gcc-9.1.0/libstdc++-v3/libsupc++ -I/home/src/gcc/gcc-9.1.0/libstdc++-v3/include/backward -I/home/src/gcc/gcc-9.1.0/libstdc++-v3/testsuite/util -L/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/opt/gnu/x86_64-pc-linux-gnu/bin/ -B/opt/gnu/x86_64-pc-linux-gnu/lib/ -isystem /opt/gnu/x86_64-pc-linux-gnu/include -isystem /opt/gnu/x86_64-pc-linux-gnu/sys-include -fchecking=1 -fPIC -DPIC -shared -nostdlib /usr/lib/../lib64/crti.o /tmp/gcc-9.1.0.build/./gcc/crtbeginS.o .libs/findcomp.o .libs/libcc1.o .libs/libcp1.o .libs/names.o .libs/callbacks.o .libs/connection.o .libs/marshall.o -L/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -L/tmp/gcc-9.1.0.build/./gcc -L/lib/../lib64 -L/usr/lib/../lib64 /tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a -lm -lc -lgcc /tmp/gcc-9.1.0.build/./gcc/crtendS.o /usr/lib/../lib64/crtn.o -static-libstdc++ -static-libgcc ../libiberty/pic/libiberty.a -Wl,-soname -Wl,libcc1.so.0 -Wl,-retain-symbols-file -Wl,/home/src/gcc/gcc-9.1.0/libcc1/libcc1.sym -o .libs/libcc1.so.0.0.0 /usr/bin/ld: /tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(class_type_info.o): relocation R_X86_64_32S against `_ZTVN10__cxxabiv117__class_type_infoE' can not be used when making a shared object; recompile with -fPIC /tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a: could not read symbols: Bad value collect2: error: ld returned 1 exit status gmake[3]: *** [libcc1.la] Error 1 gmake[3]: Leaving directory `/tmp/gcc-9.1.0.build/libcc1' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/tmp/gcc-9.1.0.build/libcc1' gmake[1]: *** [all-libcc1] Error 2 gmake[1]: Leaving directory `/tmp/gcc-9.1.0.build' gmake: *** [bootstrap-lean] Error 2 (This tree was configured with --disable-shared --enable-version-specific-runtime-libs --with-pic) I have confirmed that Alec's workaround (in comment #11) still does the trick.
[Bug other/55930] [7/8/9/10 Regression] libatomic build failure if configured with --disable-dependency-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930 Daniel Richard G. changed: What|Removed |Added CC||skunk at iskunk dot org --- Comment #10 from Daniel Richard G. --- Confirmed that this issue persists in 9.1.0: libtool: compile: /tmp/gcc-9.1.0.build/./gcc/xgcc -B/tmp/gcc-9.1.0.build/./gcc/ -B/opt/gnu/x86_64-pc-linux-gnu/bin/ -B/opt/gnu/x86_64-pc-linux-gnu/lib/ -isystem /opt/gnu/x86_64-pc-linux-gnu/include -isystem /opt/gnu/x86_64-pc-linux-gnu/sys-include -fchecking=1 -DHAVE_CONFIG_H -I/home/src/gcc/gcc-9.1.0/libatomic/config/x86 -I/home/src/gcc/gcc-9.1.0/libatomic/config/posix -I/home/src/gcc/gcc-9.1.0/libatomic -I. -Wall -Werror -pthread -g -O2 -MT load_1_.lo -MD -MP -MF .deps/load_1_.lo.Ppo -DN=1 -c /home/src/gcc/gcc-9.1.0/libatomic/load_n.c -fPIC -DPIC -o load_1_.o /home/src/gcc/gcc-9.1.0/libatomic/load_n.c:115:1: fatal error: opening dependency file .deps/load_1_.lo.Ppo: No such file or directory 115 | EXPORT_ALIAS (SIZE(load)); | ^~~~ compilation terminated. gmake[4]: *** [load_1_.lo] Error 1 gmake[4]: Leaving directory `/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libatomic' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libatomic' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libatomic' gmake[1]: *** [all-target-libatomic] Error 2 gmake[1]: Leaving directory `/tmp/gcc-9.1.0.build' gmake: *** [bootstrap-lean] Error 2 I'd like to echo Mr. Purdie's "We pass this option in globally to anything using automake" as the approach my site uses as well.
[Bug bootstrap/65725] Bootstrap errors on Solaris 10 x86-64, including object diffs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65725 --- Comment #10 from Daniel Richard G. --- (In reply to r...@cebitec.uni-bielefeld.de from comment #9) > > it would be helpful to know a bit more about that system: Solaris 10 > update release (e.g. from /etc/release), versions of as (as -V) and ld > (ld -V), bootstrap compiler used, version of cmp (and do_compare setting > in the toplevel Makefile). Gladly: $ cat /etc/release Oracle Solaris 10 8/11 s10x_u10wos_17b X86 Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved. Assembled 23 August 2011 $ as -V as: SunOS 5.10 119961-13 Patch 08/06/2014 [...] $ ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.1505 I am bootstrapping with an earlier build of GCC 7.3.0 (itself compiled via a non-bootstrapped build, due to this issue). cmp(1) has no version option; it is simply /usr/bin/cmp: $ cmp usage: cmp [-l] [-s] file1 file2 [skip1] [skip2] $ grep 'do-compare.*=' Makefile do-compare = cmp $$f1 $$f2 16 16 do-compare3 = $(do-compare) > To investigate comparison failures, it's usually necessary to have both > a few of the object pairs failing the comparison and the corresponding > .s files from -save-temps. You've to be very careful to rerun the exact > compiler invocations from exactly the same directories which can be > tricky due to all the shuffling around due to the different stages. Is it feasible to re-run the bootstrap with something like CFLAGS(_FOR_(BUILD|TARGET)) = "-save-temps" ? Recreating the compiler invocations manually will be quite tricky.
[Bug bootstrap/65725] Bootstrap errors on Solaris 10 x86-64, including object diffs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65725 --- Comment #8 from Daniel Richard G. --- Hello Rainer, (In reply to r...@cebitec.uni-bielefeld.de from comment #7) > That bootstrap (amd64-pc-solaris2.10 with as/ld, --disable-shared > --with-pic) has now completed as well: in addition to libcc1 (PR > other/66955) and ada (cf. PR ada/88429), I also had to disable go > because it uses sendfile without explicitly linking with -lsendfile (in > the shared case, this works because libgo is linked with libsendfile). > > Anyway, the bootstrap has now finished successfully and make check is > running: no comparison failures at all. So unless there's additional > information how to reproduce this, I'll close the PR as WORKSFORME. I tested this again with GCC 8.2.0 on the same system, using as/ld, and am still seeing the object diffs. Would it help if I provided a copy of the objects at issue?
[Bug bootstrap/66955] New: Bootstrap error: libcc1 compiled as shared library despite --disable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66955 Bug ID: 66955 Summary: Bootstrap error: libcc1 compiled as shared library despite --disable-shared Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: skunk at iskunk dot org Target Milestone: --- Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Build: x86_64-unknown-linux-gnu Bootstrapping 5.2.0 with --disable-shared --enable-languages=c,c++ --disable-multilib results in [...] libtool: compile: /tmp/gcc-build/./gcc/xg++ -B/tmp/gcc-build/./gcc/ -nostdinc++ -nostdinc++ -I/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/src/gcc-5.2.0/libstdc++-v3/libsupc++ -I/home/src/gcc-5.2.0/libstdc++-v3/include/backward -I/home/src/gcc-5.2.0/libstdc++-v3/testsuite/util -L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/home/src/gcc-5.2.0/libcc1 -I /home/src/gcc-5.2.0/libcc1/../include -I /home/src/gcc-5.2.0/libcc1/../libgcc -I ../gcc -I/home/src/gcc-5.2.0/libcc1/../gcc -I /home/src/gcc-5.2.0/libcc1/../gcc/c -I /home/src/gcc-5.2.0/libcc1/../gcc/c-family -I /home/src/gcc-5.2.0/libcc1/../libcpp/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -W -Wall -fvisibility=hidden -g -O2 -D_GNU_SOURCE -MT marshall.lo -MD -MP -MF .deps/marshall.Tpo -c /home/src/gcc-5.2.0/libcc1/marshall.cc -fPIC -DPIC -o .libs/marshall.o mv -f .deps/marshall.Tpo .deps/marshall.Plo /bin/sh ./libtool --tag=CXX --mode=link /tmp/gcc-build/./gcc/xg++ -B/tmp/gcc-build/./gcc/ -nostdinc++ `if test -f /tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags; then /bin/sh /tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags --build-includes; else echo -funconfigured-libstdc++-v3 ; fi` -L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include-W -Wall -fvisibility=hidden -g -O2 -D_GNU_SOURCE -module -export-symbols /home/src/gcc-5.2.0/libcc1/libcc1.sym -Xcompiler '-static-libstdc++' -Xcompiler '-static-libgcc' -o libcc1.la -rpath /usr/local/lib/../lib64 findcomp.lo libcc1.lo names.lo callbacks.lo connection.lo marshall.lo -Wc,../libiberty/pic/libiberty.a libtool: link: /tmp/gcc-build/./gcc/xg++ -B/tmp/gcc-build/./gcc/ -nostdinc++ -nostdinc++ -I/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/src/gcc-5.2.0/libstdc++-v3/libsupc++ -I/home/src/gcc-5.2.0/libstdc++-v3/include/backward -I/home/src/gcc-5.2.0/libstdc++-v3/testsuite/util -L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -fPIC -DPIC -shared -nostdlib /usr/lib/../lib64/crti.o /tmp/gcc-build/./gcc/crtbeginS.o .libs/findcomp.o .libs/libcc1.o .libs/names.o .libs/callbacks.o .libs/connection.o .libs/marshall.o -L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -L/tmp/gcc-build/./gcc -L/lib/../lib64 -L/usr/lib/../lib64 /tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a -lm -lc -lgcc /tmp/gcc-build/./gcc/crtendS.o /usr/lib/../lib64/crtn.o -static-libstdc++ -static-lib
[Bug bootstrap/66947] New: Bootstrap error: Extraneous text after `else' directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66947 Bug ID: 66947 Summary: Bootstrap error: Extraneous text after `else' directive Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: skunk at iskunk dot org Target Milestone: --- Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Build: x86_64-unknown-linux-gnu Bootstrapping 5.2.0 on a 64-bit Linux system: [...] config.status: linking /home/src/gcc-5.2.0/libgcc/config/i386/sfp-machine.h to sfp-machine.h config.status: linking /home/src/gcc-5.2.0/libgcc/gthr-posix.h to gthr-default.h config.status: executing default commands gmake[3]: Entering directory `/tmp/gcc-build/x86_64-unknown-linux-gnu/libgcc' /home/src/gcc-5.2.0/libgcc/config/t-softfp:106: Extraneous text after `else' directive /home/src/gcc-5.2.0/libgcc/config/t-softfp:113: *** only one `else' per conditional. Stop. gmake[3]: Leaving directory `/tmp/gcc-build/x86_64-unknown-linux-gnu/libgcc' gmake[2]: *** [all-stage1-target-libgcc] Error 2 gmake[2]: Leaving directory `/tmp/gcc-build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-build' gmake: *** [bootstrap-lean] Error 2 $ gmake --version GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I think the "else ifneq ..." construct in the t-softfp file requires a newer version of GNU Make. (The GCC "Prerequisites" page indicates that version 3.80 is sufficient.)
[Bug target/65644] Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644 --- Comment #9 from Daniel Richard G. --- (In reply to r...@cebitec.uni-bielefeld.de from comment #8) > > Looking closer, you are *not* using the Solaris assembler (/usr/ccs/bin/as): Good call, Rainer. GCC is in fact using /usr/sfw/bin/gas, which identifies as $ /usr/sfw/bin/gas --version GNU assembler 2.15 Copyright 2002 Free Software Foundation, Inc. I am bootstrapping again with explicit use of the Solaris assembler to confirm that everything works that way, but am running into stage2 != stage3 errors and am currently sorting those out.
[Bug target/65644] Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644 Daniel Richard G. changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #7 from Daniel Richard G. --- Reopening due to lack of resolution. If system patches should resolve the issue, then I am open to trying any that are appropriate; if they work, then they can be noted in the documentation. But it is also possible that this is a limitation of this particular version of Solaris that cannot be patched, and thus will need a workaround in GCC.
[Bug target/65644] Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644 --- Comment #6 from Daniel Richard G. --- My admin installed 119961-13, which is the current version of 119961-11: $ /usr/ccs/bin/as -V as: SunOS 5.10 119961-13 Patch 08/06/2014 Usage: as [-a32] [-m] [-m32] [-m64] [-n] [...] I'm still getting the same assembler error.
[Bug target/65644] New: Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644
Bug ID: 65644
Summary: Assembler errors on Solaris 10 x86-64: `(%eXX)' is not
a valid 64 bit base/index expression
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: skunk at iskunk dot org
Host: x86_64-pc-solaris2.10
Target: x86_64-pc-solaris2.10
Build: x86_64-pc-solaris2.10
Created attachment 35197
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35197&action=edit
test case
I built GCC 4.9.2 on a Solaris 10 system on x86-64, and then compiled a C
codebase that does some 64-bit-unsafe things (notably, assuming that pointers
are 32 bits, by casting unsigned ints to pointers). This resulted in "cast to
pointer from integer of different size" warnings as well as errors of the form
{standard input}: Assembler messages:
{standard input}:233: Error: `(%esi)' is not a valid 64 bit base/index
expression
{standard input}:250: Error: `(%edx)' is not a valid 64 bit base/index
expression
{standard input}:1150: Error: `(%edx)' is not a valid 64 bit base/index
expression
I have prepared a small test case that exhibits this same failure mode:
$ gcc -m64 -O -c gcc-asm-bug.c
gcc-asm-bug.c: In function 'foo1':
gcc-asm-bug.c:14:4: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
((struct foo_struct *)xptr)->one = val;
^
gcc-asm-bug.c: In function 'foo2':
gcc-asm-bug.c:19:4: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
((struct foo_struct *)xptr)->two = val;
^
/var/tmp//ccI3ovqk.s: Assembler messages:
/var/tmp//ccI3ovqk.s:6: Error: `(%edi)' is not a valid 64 bit base/index
expression
No such error occurs when I compile this source on a Linux system, so this may
have to do with the Solaris assembler.
[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348 --- Comment #14 from Daniel Richard G. --- (In reply to David Edelsohn from comment #13) > The GCC build process has requirements, including SVR4/POSIX awk. GCC works > on a wide variety of systems, but needs to have a base set of requirements > and limit accommodation to prevent things from getting out of control. I understand that; my point is, escaping a couple of characters falls under the rubric of "limited accommodation." It would be a different story if I wanted GCC to build with an awk that, say, doesn't support variables. > Building and installing Gawk or Nawk or another implementation is not an > unreasonable burden. It's less reasonable than a two-line patch. (Any info on building a dist tarball? I don't have enough space on my AIX 4.3 system to take the entire SVN tree)
[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348
--- Comment #12 from Daniel Richard G. ---
(In reply to David Edelsohn from comment #8)
> Patches are reviewed on gcc-patches mailinglist, not in Bugzilla
Sorry, I'm not properly set up for mailing lists at the moment...
> > * Escape "{" characters to not annoy older awk programs
>
> Prerequisites for GCC explicitly states that POSIX or SVR4 awk is required,
> so I don't think that this work-around would be accepted. For example, you
> can install GNU Awk.
POSIX/SVR4 is significant if the system awk is missing major features that
would make the script awkward/impossible to maintain. But a small syntax tweak
like this, so long as it doesn't hurt other awk implementations, is no big
deal. Especially for a script that is run by users who are only compiling the
code, as opposed to developers.
> This already has been changed.
>
[...]
>
> The fixincludes changes are the most plausible ones.
As an aside, is there documentation somewhere on how to generate a GCC dist
tarball from SVN? "make dist" doesn't do it, Web searches turn up nothing, and
I'd rather not have to wait a few days for the next snapshot...
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238 --- Comment #22 from Daniel Richard G. --- Still using AIX 4.3 here. The std::ctype error has been particularly nettlesome, as it's beyond my ken and I can't work around it.
[Bug bootstrap/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009 --- Comment #11 from Daniel Richard G. --- Yep, that system's still running. I'll be happy to test any fixes for this issue.
[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #27 from Daniel Richard G. --- Likewise confirmed on the same Woody system from comment #5: 4.9.1 bootstraps fine, 4.8.3 still has the bug. (Oddly enough, the first configure run in the 4.9.1 bootstrap has the message "checking for libsanitizer support... yes") Given the target milestone, I presume there's going to be a 4.8.4?
[Bug libstdc++/58638] libstdc++ builds as non-PIC when --with-pic is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638 --- Comment #8 from Daniel Richard G. --- (In reply to Jonathan Wakely from comment #7) > Seems unlikely, but if -static-libgcc -static-libstdc++ gives you a runtime > dependency on GCC then that should be reported as a bug. I tried a 4.9.0 build without --disable-shared to jog my memory. The problem was twofold: First, GCC can't find its own runtime library when linking programs: /usr/bin/ld: cannot find -lgcc_s I can specify -L$(PREFIX)/lib/gcc/x86_64-unknown-linux-gnu/lib64 manually, and that allows things to link. But then, unless I futz with ld.so.conf/LD_LIBRARY_PATH, the resulting executable uses the wrong instance of libgcc/libstdc++: $ ldd swig linux-vdso.so.1 => (0x7fff76839000) libdl.so.2 => /lib64/libdl.so.2 (0x00302ee0) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x003039a0) libm.so.6 => /lib64/libm.so.6 (0x00302e60) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x003035a0) libc.so.6 => /lib64/libc.so.6 (0x00302ea0) /lib64/ld-linux-x86-64.so.2 (0x00302e20) (Note: It's probably relevant that I also build GCC with --enable-version-specific-runtime-libs, to avoid a different way that the runtimes can get mixed up.) Not having to specify -static-libblah is a bonus, but these were the real reasons that I was using --disable-shared. Should I file a new bug for this?
[Bug libstdc++/58638] libstdc++ builds as non-PIC when --with-pic is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638 --- Comment #6 from Daniel Richard G. --- (In reply to Jonathan Wakely from comment #4) > > Instead of building GCC with --disable-shared, why not just use > -static-libstdc++ when linking? It was a long time ago that I last tried that, so I can't say for sure, but it was probably that executables were being produced that still had some-or-other GCC shared-runtime dependency. (This GCC instance is being used for production builds, so it's release-engineering considerations uber alles)
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #10 from Daniel Richard G. --- (In reply to Richard Biener from comment #9) > What's the status of this bug? Same as I reported in comment #5---I just confirmed with a build of 4.8.2.
[Bug bootstrap/58720] New: FreeBSD 4.8 bootstrap fails due to missing stdint.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58720 Bug ID: 58720 Summary: FreeBSD 4.8 bootstrap fails due to missing stdint.h Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: skunk at iskunk dot org Host: i686-unknown-freebsd4.8 Target: i686-unknown-freebsd4.8 Build: i686-unknown-freebsd4.8 After addressing bugs #58274 and #58719, a bootstrap of GCC 4.8.1 on FreeBSD 4.8 fails with [...] gmake[5]: Entering directory `/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include' mkdir -p ./i686-unknown-freebsd4.8/bits/stdc++.h.gch /tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc -nostdinc++ -L/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/src -L/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/src/.libs -B/usr/local/i686-unknown-freebsd4.8/bin/ -B/usr/local/i686-unknown-freebsd4.8/lib/ -isystem /usr/local/i686-unknown-freebsd4.8/include -isystem /usr/local/i686-unknown-freebsd4.8/sys-include-x c++-header -nostdinc++ -g -O2 -I/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include/i686-unknown-freebsd4.8 -I/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include -I/tmp/gcc-4.8.1/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /tmp/gcc-4.8.1/libstdc++-v3/include/precompiled/stdc++.h \ -o i686-unknown-freebsd4.8/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include/bits/atomic_base.h:37:0, from /tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include/atomic:41, from /tmp/gcc-4.8.1/libstdc++-v3/include/precompiled/stdc++.h:99: /tmp/gcc-build/./gcc/include/stdint.h:9:26: fatal error: stdint.h: No such file or directory # include_next ^ compilation terminated. gmake[5]: *** [i686-unknown-freebsd4.8/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1 gmake[5]: Leaving directory `/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3/include' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/tmp/gcc-build/i686-unknown-freebsd4.8/libstdc++-v3' gmake[2]: *** [all-stage1-target-libstdc++-v3] Error 2 gmake[2]: Leaving directory `/tmp/gcc-build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-build' gmake: *** [bootstrap] Error 2 This system has no /usr/include/stdint.h, so GCC should probably not be looking for one.
[Bug bootstrap/58719] New: libgcc/enable-execute-stack-mprotect.c: bootstrap failure due to missing #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58719 Bug ID: 58719 Summary: libgcc/enable-execute-stack-mprotect.c: bootstrap failure due to missing #include Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: skunk at iskunk dot org Host: i686-unknown-freebsd4.8 Target: i686-unknown-freebsd4.8 Build: i686-unknown-freebsd4.8 After patching bug #58274, a bootstrap of GCC 4.8.1 on FreeBSD 4.8 stops with /tmp/gcc-build/./gcc/xgcc -B/tmp/gcc-build/./gcc/ -B/usr/local/i686-unknown-freebsd4.8/bin/ -B/usr/local/i686-unknown-freebsd4.8/lib/ -isystem /usr/local/i686-unknown-freebsd4.8/include -isystem /usr/local/i686-unknown-freebsd4.8/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -pthread -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -pthread -I. -I. -I../.././gcc -I../../../gcc-4.8.1/libgcc -I../../../gcc-4.8.1/libgcc/. -I../../../gcc-4.8.1/libgcc/../gcc -I../../../gcc-4.8.1/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o enable-execute-stack.o -MT enable-execute-stack.o -MD -MP -MF enable-execute-stack.dep -c enable-execute-stack.c -fvisibility=hidden -DHIDE_EXPORTS In file included from /usr/include/sys/mman.h:135:0, from enable-execute-stack.c:25: /usr/include/sys/mman.h:141:14: error: unknown type name 'mode_t' int shm_open __P((const char *, int, mode_t)); ^ /usr/include/sys/mman.h:144:11: error: unknown type name 'size_t' int mlock __P((const void *, size_t)); ^ /usr/include/sys/mman.h:147:13: error: unknown type name 'size_t' void * mmap __P((void *, size_t, int, int, int, off_t)); ^ /usr/include/sys/mman.h:147:13: error: unknown type name 'off_t' void * mmap __P((void *, size_t, int, int, int, off_t)); ^ /usr/include/sys/mman.h:149:14: error: unknown type name 'size_t' int mprotect __P((const void *, size_t, int)); ^ /usr/include/sys/mman.h:150:11: error: unknown type name 'size_t' int msync __P((void *, size_t, int)); ^ /usr/include/sys/mman.h:151:13: error: unknown type name 'size_t' int munlock __P((const void *, size_t)); ^ /usr/include/sys/mman.h:152:12: error: unknown type name 'size_t' int munmap __P((void *, size_t)); ^ /usr/include/sys/mman.h:154:13: error: unknown type name 'size_t' int madvise __P((void *, size_t, int)); ^ /usr/include/sys/mman.h:155:13: error: unknown type name 'size_t' int mincore __P((const void *, size_t, char *)); ^ /usr/include/sys/mman.h:156:14: error: unknown type name 'size_t' int minherit __P((void *, size_t, int)); ^ enable-execute-stack.c: In function '__enable_execute_stack': enable-execute-stack.c:86:7: warning: implicit declaration of function 'mprotect' [-Wimplicit-function-declaration] if (mprotect (page, end - page, STACK_PROT_RWX) < 0) ^ gmake[3]: *** [enable-execute-stack.o] Error 1 gmake[3]: Leaving directory `/tmp/gcc-build/i686-unknown-freebsd4.8/libgcc' gmake[2]: *** [all-stage1-target-libgcc] Error 2 gmake[2]: Leaving directory `/tmp/gcc-build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-build' gmake: *** [bootstrap] Error 2 $ ls -l /tmp/gcc-build/i686-unknown-freebsd4.8/libgcc/enable-execute-stack.c lrwxr-xr-x 1 cport r&d 57 Oct 14 02:31 /tmp/gcc-build/i686-unknown-freebsd4.8/libgcc/enable-execute-stack.c -> ../../../gcc-4.8.1/libgcc/enable-execute-stack-mprotect.c Adding an '#include ' to libgcc/enable-execute-stack-mprotect.c, right before the sys/mman.h #include, is enough to get the bootstrap going again.
[Bug libstdc++/58638] libstdc++ builds as non-PIC when --with-pic is specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638 --- Comment #1 from Daniel Richard G. --- A workaround for this issue is to build with CFLAGS="-fPIC" CXXFLAGS="-fPIC" (presuming that one is building with GCC), in addition to --with-pic. This results in a compiler build that does not fail as reported above.
[Bug libstdc++/58638] New: libstdc++ builds as non-PIC when --with-pic is specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638 Bug ID: 58638 Summary: libstdc++ builds as non-PIC when --with-pic is specified Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: skunk at iskunk dot org Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Build: x86_64-unknown-linux-gnu I built GCC 4.8.1 with "--disable-shared --with-pic" so that I can statically link libgcc/libstdc++ into executables, including shared-library builds. However, when I attempted to build a C++ shared object on Linux/amd64 using the new compiler, I got this: libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/../lib64/crti.o /opt/tg-opt/gcc--4.8.1--linux64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtbeginS.o .libs/Dqa_wrap.o .libs/dqa_func.o [...] -L/opt/tg-opt/gcc--4.8.1--linux64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/opt/tg-opt/gcc--4.8.1--linux64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../.. /opt/tg/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libstdc++.a -lm -lc -lgcc /opt/tg-opt/gcc--4.8.1--linux64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtendS.o /usr/lib/../lib64/crtn.o -march=opteron -mno-3dnow -O0 -pthread -Wl,-soname -Wl,libdqa_swig_interface.so -o .libs/libdqa_swig_interface.so /usr/bin/ld: /opt/tg/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libstdc++.a(eh_throw.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC /opt/tg/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libstdc++.a: could not read symbols: Bad value collect2: error: ld returned 1 exit status make[6]: *** [libdqa_swig_interface.la] Error 1 This is a regression from 4.7.x, when --with-pic correctly caused all (static) runtime libraries to be built with PIC code.
[Bug bootstrap/58274] New: libiberty/stack-limit.c: bootstrap failure due to missing FreeBSD header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58274 Bug ID: 58274 Summary: libiberty/stack-limit.c: bootstrap failure due to missing FreeBSD header Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: skunk at iskunk dot org Host: i386-unknown-freebsd4.8 Target: i386-unknown-freebsd4.8 Build: i386-unknown-freebsd4.8 Created attachment 30724 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30724&action=edit Patch against 4.8.1/SVN This is basically the same as bug 49817, only this occurs on FreeBSD 4.8, which doesn't have . (This is clearly a bug in the FreeBSD headers, but this version of the OS won't be seeing a fix.) [...] if [ x"-fpic" != x ]; then \ tg-gcc -c -DHAVE_CONFIG_H -g -I. -I/home/src/gcc-4.8.1/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -fpic /home/src/gcc-4.8.1/libiberty/stack-limit.c -o pic/stack-limit.o; \ else true; fi In file included from /home/src/gcc-4.8.1/libiberty/stack-limit.c:43: /usr/include/sys/resource.h:58: error: field 'ru_utime' has incomplete type /usr/include/sys/resource.h:59: error: field 'ru_stime' has incomplete type /usr/include/sys/resource.h:119: error: expected specifier-qualifier-list before 'int32_t' /usr/include/sys/resource.h:124: error: expected specifier-qualifier-list before 'rlim_t' /usr/include/sys/resource.h:130: error: expected specifier-qualifier-list before 'fixpt_t' /home/src/gcc-4.8.1/libiberty/stack-limit.c: In function 'stack_limit_increase': /home/src/gcc-4.8.1/libiberty/stack-limit.c:53: error: 'struct rlimit' has no member named 'rlim_cur' /home/src/gcc-4.8.1/libiberty/stack-limit.c:53: error: 'rlim_t' undeclared (first use in this function) /home/src/gcc-4.8.1/libiberty/stack-limit.c:53: error: (Each undeclared identifier is reported only once /home/src/gcc-4.8.1/libiberty/stack-limit.c:53: error: for each function it appears in.) /home/src/gcc-4.8.1/libiberty/stack-limit.c:53: error: 'u_quad_t' undeclared (first use in this function) /home/src/gcc-4.8.1/libiberty/stack-limit.c:53: error: expected ')' before numeric constant /home/src/gcc-4.8.1/libiberty/stack-limit.c:54: error: 'struct rlimit' has no member named 'rlim_cur' /home/src/gcc-4.8.1/libiberty/stack-limit.c:55: error: 'struct rlimit' has no member named 'rlim_max' /home/src/gcc-4.8.1/libiberty/stack-limit.c:55: error: expected ')' before numeric constant /home/src/gcc-4.8.1/libiberty/stack-limit.c:55: error: 'struct rlimit' has no member named 'rlim_cur' /home/src/gcc-4.8.1/libiberty/stack-limit.c:55: error: 'struct rlimit' has no member named 'rlim_max' /home/src/gcc-4.8.1/libiberty/stack-limit.c:57: error: 'struct rlimit' has no member named 'rlim_cur' /home/src/gcc-4.8.1/libiberty/stack-limit.c:58: error: 'struct rlimit' has no member named 'rlim_max' /home/src/gcc-4.8.1/libiberty/stack-limit.c:58: error: expected ')' before numeric constant /home/src/gcc-4.8.1/libiberty/stack-limit.c:58: error: 'struct rlimit' has no member named 'rlim_cur' /home/src/gcc-4.8.1/libiberty/stack-limit.c:58: error: 'struct rlimit' has no member named 'rlim_max' /home/src/gcc-4.8.1/libiberty/stack-limit.c:59: error: 'struct rlimit' has no member named 'rlim_cur' /home/src/gcc-4.8.1/libiberty/stack-limit.c:59: error: 'struct rlimit' has no member named 'rlim_max' gmake[3]: *** [stack-limit.o] Error 1 #Including fixes the issue. See attached patch.
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #7 from Daniel Richard G. --- Created attachment 30723 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30723&action=edit Trivial configure-time check (In reply to Kostya Serebryany from comment #6) > > That would be non-trivial. We intercept the pthread_ functions so we can't > call them directly. We'll at least need to bypass our own interceptors. > And as I mentioned before, older kernels will likely not work anyway for > a few other reasons. Okay, so I guess there's no alternative but to disable libsanitizer for these systems. I see that libsanitizer support is inferred automatically by the libsanitizer/configure.tgt script, which is sourced from the top-level configure script. This script is not processed by Autoconf, so doing a test-compile in there would be somewhat awkward. However, on this old Debian system, the linux/futex.h header doesn't exist at all, so picking up on that would be enough for me. See attached patch for a first-draft proposal. (There probably needs to be some build/host/target-sysroot awareness of where to look for the header; I'm not familiar enough with building cross-compilers.)
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
Daniel Richard G. changed:
What|Removed |Added
CC||skunk at iskunk dot org
--- Comment #5 from Daniel Richard G. ---
I get this same error building on an old Debian woody system:
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc: In
function 'void __sanitizer::internal__exit(int)':
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc:142:11:
error: '__NR_exit_group' was not declared in this scope
syscall(__NR_exit_group, exitcode);
^
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc: In member
function 'void __sanitizer::BlockingMutex::Lock()':
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc:529:13:
error: '__NR_futex' was not declared in this scope
syscall(__NR_futex, m, FUTEX_WAIT, MtxSleeping, 0, 0, 0);
^
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc: In member
function 'void __sanitizer::BlockingMutex::Unlock()':
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc:537:13:
error: '__NR_futex' was not declared in this scope
syscall(__NR_futex, m, FUTEX_WAKE, 1, 0, 0, 0);
^
gmake[4]: *** [sanitizer_linux.lo] Error 1
Would a fallback implementation of BlockingMutex::{Lock,Unlock}() that uses
pthread_mutex_*() be sensible here?
[Bug bootstrap/53266] Error: Unrecognized opcode: `mulhwu'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53266 --- Comment #10 from Daniel Richard G. 2012-09-27 14:02:03 UTC --- Okay, I grabbed a copy of gcc-4.8-20120923, and started bootstrapping using an older 4.5.2 (since the 4.7.0 C++ compiler isn't working correctly; am I correct in observing that GCC can no longer be bootstrapped using just a C compiler?). Things went well up until this point: tg-g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/src/gcc-4.8-20120923/gcc -I/home/src/gcc-4.8-20120923/gcc/. -I/home/src/gcc-4.8-20120923/gcc/../include -I/home/src/gcc-4.8-20120923/gcc/../libcpp/include -I/tg/freeport/arch/aix32/include -I/tg/freeport/arch/aix32/include -I/tg/freeport/arch/aix32/include -I/home/src/gcc-4.8-20120923/gcc/../libdecnumber -I/home/src/gcc-4.8-20120923/gcc/../libdecnumber/dpd -I../libdecnumber\ /home/src/gcc-4.8-20120923/gcc/config/rs6000/rs6000.c -o rs6000.o /home/src/gcc-4.8-20120923/gcc/config/rs6000/rs6000.c: In function 'void rs6000_code_end()': /home/src/gcc-4.8-20120923/gcc/config/rs6000/rs6000.c:28292:51: error: 'ASM_WEAKEN_DECL' was not declared in this scope gmake[3]: *** [rs6000.o] Error 1 gmake[3]: Leaving directory `/tmp/gcc-4.8-test/gcc' gmake[2]: *** [all-stage1-gcc] Error 2 gmake[2]: Leaving directory `/tmp/gcc-4.8-test' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-4.8-test' gmake: *** [bootstrap-lean] Error 2 This is one of the issues addressed by my aforementioned patch.
[Bug bootstrap/53266] Error: Unrecognized opcode: `mulhwu'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53266 --- Comment #8 from Daniel Richard G. 2012-09-26 06:06:11 UTC --- Sure, can do. Is mainline a synonym for SVN trunk? Is there somewhere I can download a ready-made tarball, just to make sure everything is autogen'ed correctly?
[Bug bootstrap/53266] Error: Unrecognized opcode: `mulhwu'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53266 --- Comment #6 from Daniel Richard G. 2012-09-25 21:38:32 UTC --- Okay, I'm bootstrapping an unmodified 4.7.2, using a previously-built 4.7.0 as CC and the following configuration options: --prefix=/opt/tg --disable-dependency-tracking --disable-maintainer-mode --program-prefix=tg- --disable-shared --disable-nls --enable-languages=c,c++ --enable-version-specific-runtime-libs --with-pic --with-mpc=/tg/freeport/arch/aix32 --with-mpfr=/tg/freeport/arch/aix32 --with-gmp=/tg/freeport/arch/aix32 --disable-powercpu Last time I tried this with 4.7.0/4.7.1, there were numerous problems (none having to do with bad PPC instructions, since I just used --with-cpu= et al. to work around that). I actually have patches for most of the issues, and have previously posted them at http://gcc.gnu.org/PR53348#c7 but David Edelsohn took no notice of them. If you're interested, I'll be happy to update the patch for current SVN. At any rate, I'll let you know how the build goes. This machine isn't exactly a speed demon, so give it a day or three
[Bug bootstrap/53266] Error: Unrecognized opcode: `mulhwu'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53266 --- Comment #4 from Daniel Richard G. 2012-09-25 10:56:41 UTC --- (In reply to comment #3) > Does this still fail? I haven't built GCC on the AIX 4.3 (PowerPC 604) system lately, but my scripts are set up to do so using --with-cpu=powerpc --disable-aix64 --disable-powercpu in order to avoid this issue. Should I be able to drop any of these, at this point?
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887
--- Comment #21 from Daniel Richard G. 2012-07-25
03:18:32 UTC ---
(In reply to comment #18)
> Maybe the code is non-functional, but *something* is referencing the
> symbol under certain circumstances.
I figure this is a question worth answering. Repeating the failed link with
-Wl,-bnoquiet gives some helpful information:
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
--
.std::function::function(std::function const&) [146]
ER PR
/home/src/gcc-4.7.1/libstdc++-v3/src/c++11/regex.cc(/tmp/gcc-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a[regex.o])
2918 .textR_RBR[3582]
.std::__regex::_State::_State(std::__regex::_State const&)
.std::function::function(std::function const&) [276]
ER PR
/home/src/gcc-4.7.1/libstdc++-v3/src/c++11/functexcept.cc(/tmp/gcc-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a[functexcept.o])
3e18 .textR_RBR[4312]
.std::__regex::_State::_State(std::__regex::_State const&)
.std::function::function(std::function
const&) [148] ER PR
/home/src/gcc-4.7.1/libstdc++-v3/src/c++11/regex.cc(/tmp/gcc-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a[regex.o])
2938 .textR_RBR[3582]
.std::__regex::_State::_State(std::__regex::_State const&)
.std::function::function(std::function
const&) [278] ER PR
/home/src/gcc-4.7.1/libstdc++-v3/src/c++11/functexcept.cc(/tmp/gcc-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a[functexcept.o])
3e38 .textR_RBR[4312]
.std::__regex::_State::_State(std::__regex::_State const&)
ER: The return code is 8.
ld: 0711-317 ERROR: Undefined symbol: .std::function::function(std::function const&)
ld: 0711-317 ERROR: Undefined symbol: .std::function::function(std::function const&)
collect2: error: ld returned 8 exit status
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238
--- Comment #21 from Daniel Richard G. 2012-07-23
18:52:06 UTC ---
(In reply to comment #20)
> You could try adding this to ctype.cc around line 54
--- libstdc++-v3/src/c++98/ctype.cc.orig2012-01-23 18:12:01.2 -0500
+++ libstdc++-v3/src/c++98/ctype.cc2012-07-23 13:31:55.2 -0400
@@ -52,6 +52,8 @@
const size_t ctype::table_size;
+ inline template class ctype;// added by skunk
+
ctype::~ctype()
{
_S_destroy_c_locale(_M_c_locale_ctype);
I rebuilt ctype.o and the libraries it goes into. Unfortunately, I still get
the link error. If I compare the output of "nm -A" on the old and new ctype.o
objects, I don't see a difference in the defined symbols.
The mangled form of "vtable for std::ctype" is "_ZTVSt5ctypeIcE". If I
grep for that in "nm -A ctype.o", I see
ctype.o:17c0 d _ZTVSt5ctypeIcE.P8
but no instances without the ".P8" suffix. Looking through all the objects of
libstdc++, grep only turns up these:
ctype_configure_char.o: U _ZTVSt5ctypeIcE
ctype_configure_char.o:08a4 d _ZTVSt5ctypeIcE.P8
For comparison, I grepped for "_ZTVNSt6locale5facetE", the mangled form of
"vtable for std::locale::facet", and got the below:
time_members.o: U _ZTVNSt6locale5facetE
time_members.o:1778 d _ZTVNSt6locale5facetE.P8
codecvt.o: U _ZTVNSt6locale5facetE
codecvt.o:15d0 d _ZTVNSt6locale5facetE.P8
locale-inst.o: U _ZTVNSt6locale5facetE
locale-inst.o:00023974 d _ZTVNSt6locale5facetE.P8
wlocale-inst.o: U _ZTVNSt6locale5facetE
wlocale-inst.o:00023c2c d _ZTVNSt6locale5facetE.P8
numeric_members.o: U _ZTVNSt6locale5facetE
numeric_members.o:0e64 d _ZTVNSt6locale5facetE.P8
ctype.o: U _ZTVNSt6locale5facetE
ctype.o:17bc d _ZTVNSt6locale5facetE.P8
monetary_members.o: U _ZTVNSt6locale5facetE
monetary_members.o:1b80 d _ZTVNSt6locale5facetE.P8
locale_init.o: U _ZTVNSt6locale5facetE
locale_init.o:4a50 d _ZTVNSt6locale5facetE.P8
ctype_configure_char.o: U _ZTVNSt6locale5facetE
ctype_configure_char.o:08a0 d _ZTVNSt6locale5facetE.P8
locale.o:2b08 d _ZTVNSt6locale5facetE
locale.o:2b08 D _ZTVNSt6locale5facetE
locale.o:2b3c d _ZTVNSt6locale5facetE.P8
The fact of the symbol being a vtable for a template class appears to be
relevant. Maybe a different kind of explicit instantiation is needed?
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238 --- Comment #19 from Daniel Richard G. 2012-07-23 04:20:33 UTC --- The good news: The build gets past all of the pthreads-related errors described here, so I think those two changes may be a workable solution. The bad news: I'll still running up against this error: /tmp/gcc-build/./prev-gcc/g++ -B/tmp/gcc-build/./prev-gcc/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -nostdinc++ -B/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs -B/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/libsupc++/.libs -I/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0 -I/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/include -I/tg/freeport/src/gcc/gcc--4.7.1-tera/libstdc++-v3/libsupc++ -L/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs -L/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/libsupc++/.libs -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o cc1 c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.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-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 default-c.o rs6000-c.o \ cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/tg/freeport/arch/aix32/lib -L/tg/freeport/arch/aix32/lib -L/tg/freeport/arch/aix32/lib -lmpc -lmpfr -lgmp -L../zlib -lz ld: 0711-317 ERROR: Undefined symbol: vtable for std::ctype ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: error: ld returned 8 exit status gmake[3]: *** [cc1] Error 1 gmake[3]: Leaving directory `/tmp/gcc-build/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory `/tmp/gcc-build' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-build' gmake: *** [bootstrap-lean] Error 2 I really need help with this error---this seems to be along the lines of the PatternCursor issue we saw the other day, only this one is more confusing. What do you think is going on here? (FWIW, the objects that want the missing symbol are the various instances of ctype_configure_char.o, which appears to be built from libstdc++-v3/config/os/aix/ctype_configure_char.cc. I *think* the std::ctype template/class is defined in libstdc++-v3/include/bits/locale_facets.h.)
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238 --- Comment #18 from Daniel Richard G. 2012-07-20 17:44:12 UTC --- (In reply to comment #17) > Between comment 5 (with missing ;;) and comment 14 it should work, I think. Okay, I'm re-starting the build with those two changes (plus my omnibus patch) applied to 4.7.1. Let's see where that goes over the weekend...
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238 --- Comment #16 from Daniel Richard G. 2012-07-19 21:10:28 UTC --- Okay, spoke too soon; I encountered the same error later in the game, when building the "pthread" variant of libstdc++-v3. I'm going to try the build with a new patch, revisiting the code snippet in comment #2: --- libstdc++-v3/acinclude.m4(revision 189681) +++ libstdc++-v3/acinclude.m4(working copy) @@ -3282,13 +3282,18 @@ AC_MSG_CHECKING([whether it can be safely assumed that mutex_timedlock is available]) - AC_TRY_COMPILE([#include ], + AC_TRY_COMPILE( +[ + #include + #include +], [ // In case of POSIX threads check _POSIX_TIMEOUTS. #if (defined(_PTHREADS) \ && (!defined(_POSIX_TIMEOUTS) || _POSIX_TIMEOUTS <= 0)) #error #endif + return pthread_mutex_timedlock(NULL, NULL) ], [ac_gthread_use_mutex_timedlock=1], [ac_gthread_use_mutex_timedlock=0]) AC_DEFINE_UNQUOTED(_GTHREAD_USE_MUTEX_TIMEDLOCK, $ac_gthread_use_mutex_timedlock, Since the code is being compiled as C++, linking is not necessary to get an error in case the function is missing. Will this work any better as a solution than my suggestion in comment #4? (Might an "#ifndef WIN32" in there be helpful?)
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238 --- Comment #15 from Daniel Richard G. 2012-07-19 19:24:37 UTC --- (In reply to comment #14) > I still don't think it's the right thing to do, but does this help? I'm trying this now, in conjunction with the patch posted at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348#c7 So far, your change seems to address the O2ggnu++0x.gch error in the original report above, as I encountered that before actually making the change. (Bootstrap time on this system is measured in days, and I'll probably need to do a second go-around, so let me get back to you...)
[Bug spam/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009 Daniel Richard G. changed: What|Removed |Added Component|target |spam --- Comment #9 from Daniel Richard G. 2012-07-17 23:32:04 UTC --- I've posted a more elaborated patch for this (and other AIX 4.3 issues) to bug #53348.
[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348
--- Comment #7 from Daniel Richard G. 2012-07-17
23:24:13 UTC ---
Created attachment 27821
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27821
Patch against GCC SVN trunk
Hi David,
The attached patch is everything I've got so far to address issues in building
GCC on AIX 4.3. This covers issues beyond this bug report, but I figured you'd
rather take care of everything in one go. A walk-through of the changes:
++ gcc/opt-functions.awk
* Escape "{" characters to not annoy older awk programs
++ gcc/config/rs6000/rs6000.c
* legitimate_indirect_address_p() was coming up as undefined when declared with
the "inline" keyword
* ASM_WEAKEN_DECL() was coming up undefined, too, even though the call is in a
section of code not actually used on this platform
++ fixincludes/tests/base/*.h
* Updates to the test suite
++ fixincludes/inclhack.def
* Fixinclude for the oddly-sized fast-integer types
* Fixinclude for the broken PRIxNN macros in inttypes.h
* Fixinclude for an incomplete PTHREAD_ONCE_INIT (breaks -Werror builds)
* Tweaked the aix_pthread hack, as pthread.h has a tab character immediately
after the "#define" on my system
* Fixinclude for an strtof() declaration lacking a const keyword (bug #48009)
Please let me know what you think.
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #15 from Daniel Richard G. 2012-06-20 04:10:28 UTC --- David, thank you for commenting; I have a better appreciation now of how AIX is a different animal from most, and indeed may be doing things more correctly than other systems on this one point. I'd also like to bring attention to a seemingly similar issue I've encountered when bootstrapping on AIX 4.3: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238#c11 That one is less straightforward, however, because (as reported a couple comments further down) it only occurs when bootstrapping. If I build GCC with a C-only GCC of the same version and --disable-bootstrap, there's no error.
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #12 from Daniel Richard G. 2012-06-18 16:56:42 UTC --- (In reply to comment #11) > We know the instantiations that are needed, but I don't want to define them > for > all platforms if they're not needed elsewhere. I also have no way of testing > on > AIX, so someone needs to run the teststuite with the changes. I can do the testing, but is this really the solution? Why would AIX (and not even all versions of AIX) need these instantiations, how is it doing things differently from other systems? This is fine as a workaround, but I'm presuming the real fix is to get GCC on AIX working again the same way as it does elsewhere.
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238 --- Comment #13 from Daniel Richard G. 2012-06-10 22:39:36 UTC --- Hi Jonathan, I've checked and double-checked this, and was hoping you could offer some insight: I get the "Undefined symbol: vtable for std::ctype" error only when bootstrapping. If I build 4.7.0 with a previously-built C-only 4.7.0 + --disable-bootstrap, everything else the same, the build completes successfully. Can you make anything of that?
[Bug bootstrap/53607] New: opt-functions.awk --> "awk: There is a regular expression error."
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53607
Bug #: 53607
Summary: opt-functions.awk --> "awk: There is a regular
expression error."
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
Host: hppa2.0w-hp-hpux11.00
Target: hppa2.0w-hp-hpux11.00
Build: hppa2.0w-hp-hpux11.00
Created attachment 27583
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27583
Proposed fix
Bootstrapping 4.7.0 on an HP-UX 11.00 system fails with
[...]
echo timestamp > s-options
awk -f /home/src/gcc-4.7.0/gcc/opt-functions.awk -f /tg/freepor
t/src/gcc/gcc--4.7.0-tera/gcc/opt-read.awk \
-f /home/src/gcc-4.7.0/gcc/opth-gen.awk \
< optionlist > tmp-options.h
awk: There is a regular expression error.
?, *, or + not preceded by valid regular expression
The source line number is 90.
The error context is
if (flags ~ >>> "^{") <<<
gmake[3]: *** [s-options-h] Error 2
gmake[3]: Leaving directory `/tmp/gcc-build/gcc'
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2
The fix for this is fairly trivial; patch against SVN is attached.
[Bug bootstrap/52850] Linker path ends up using wrong zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52850 --- Comment #3 from Daniel Richard G. 2012-06-07 21:59:39 UTC --- Created attachment 27582 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27582 Proposed fix Since the in-tree zlib is always built as a static archive, we can link it in with an explicit path rather than -lz (and still use the latter when using the system zlib). How does this look?
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238
--- Comment #11 from Daniel Richard G. 2012-05-16
02:51:24 UTC ---
Okay, the bootstrap gets further this time. A couple of unrelated issues came
up which I was able to work around, but then I encountered this:
[...]
/tmp/gcc-build/./prev-gcc/g++ -B/tmp/gcc-build/./prev-gcc/
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -nostdinc++
-B/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs
-B/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/libsupc++/.libs
-I/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0
-I/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/include
-I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++
-L/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs
-L/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/libsupc++/.libs -g
-O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H
-static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o cc1
c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o
c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.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-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
default-c.o rs6000-c.o \
cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
-L/tg/freeport/arch/aix32/lib -L/tg/freeport/arch/aix32/lib
-L/tg/freeport/arch/aix32/lib -lmpc -lmpfr -lgmp -L../zlib -lz
ld: 0711-317 ERROR: Undefined symbol: vtable for std::ctype
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status
gmake[3]: *** [cc1] Error 1
gmake[3]: Leaving directory `/tmp/gcc-build/gcc'
gmake[2]: *** [all-stage2-gcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2
If I add -Wl,-bnoquiet to that, I get
[...]
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
--
vtable for std::ctype [16]ER PR
ctype_configure_char.cc(/tmp/gcc-build/prev-powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs/libstdc++.a[ctype_configure_char.o])
08a4 .dataR_POS[775]
<_ZTVSt5ctypeIcE.P8>
ER: The return code is 8.
ld: 0711-317 ERROR: Undefined symbol: vtable for std::ctype
collect2: error: ld returned 8 exit status
Seems like another issue in the vein of bug 52887. I can't make heads or tails
of C++ at this level; would another instantiation do the trick here?
[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348 --- Comment #6 from Daniel Richard G. 2012-05-15 19:01:45 UTC --- My first thought had been to put in AIX-version-dependent cpp conditionals in aix-stdint.h, but admittedly, that would have been an ugly way to go. I have an AIX 5.3 system here as well. There is no sys/inttypes.h, but [u]int_fastNN_t is defined in sys/stdint.h, and all the types are the same size as [u]intNN_t. This is presumably the case for newer AIXes as well. Fixincluding sys/inttypes.h should be safe IMO, and any bad fallout from that should be limited to AIX releases that still have this header, and use the unequal-sized-types, and somehow depend on those types. I'll double-check that this isn't the case for 4.3.
[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348 --- Comment #4 from Daniel Richard G. 2012-05-15 17:35:20 UTC --- (In reply to comment #3) > AIX 4.3.2 was announced in 1998 and end of service in 2003. The AIX header is > wrong and was fixed in later versions. You have a work-around. I am not aware > of anyone else trying to use recent versions of GCC on ancient versions of > AIX. > Customers who continue to use an old version generally freeze all software on > the system. Patches are welcome. So if I understand correctly: GCC may still nominally support AIX 4.3, but no one here really wants to spend time dealing with it. If that's the case, could you set these PRs to WAITING/IN_PROGRESS, and assign them to me? I'll gladly try my hand at some patches, as long as someone here is willing to review them and get them in if they're good. I was under the impression that fast-integer types could be N bits or more in size, so e.g. "typedef int32_t int_fast16_t" would be valid (and may make sense for the architecture). So you're saying that's not it, and sys/inttypes.h needs fixincluding?
[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348 --- Comment #2 from Daniel Richard G. 2012-05-14 22:54:02 UTC --- *** Bug 47902 has been marked as a duplicate of this bug. ***
[Bug bootstrap/47902] Bootstrap failure: libiberty/regex.c: error: two or more data types in declaration specifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47902 Daniel Richard G. changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE --- Comment #5 from Daniel Richard G. 2012-05-14 22:54:02 UTC --- This bug appears to be a duplicate of bug 53348. (The linked bug report is newer, but represents a clearer diagnosis of the problem, and is filed against version 4.7.0.) *** This bug has been marked as a duplicate of bug 53348 ***
[Bug bootstrap/47907] Bootstrap failure: libiberty/hashtab.c: error: conflicting types for 'int_fast16_t'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47907 Daniel Richard G. changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Daniel Richard G. 2012-05-14 22:51:36 UTC --- This bug is a duplicate of bug 53348. The failure mode in comment 1 is a duplicate of bug 53351. (The linked bug reports are newer, but represent a clearer diagnosis of the problem, and are filed against version 4.7.0.) *** This bug has been marked as a duplicate of bug 53348 ***
[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348 --- Comment #1 from Daniel Richard G. 2012-05-14 22:51:36 UTC --- *** Bug 47907 has been marked as a duplicate of this bug. ***
[Bug bootstrap/53351] New: Missing integer types when bootstrapping on AIX 4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53351 Bug #: 53351 Summary: Missing integer types when bootstrapping on AIX 4.3 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: sk...@iskunk.org Host: powerpc-ibm-aix4.3.2.0 Target: powerpc-ibm-aix4.3.2.0 Build: powerpc-ibm-aix4.3.2.0 Bootstrapping 4.7.0 on AIX 4.3 fails with [...] Making all in c++11 gmake[6]: Entering directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/c++11' /opt/freeware/bin/bash ../../libtool --tag CXX --tag disable-shared --mode=compile /tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc -nostdinc++ -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/ -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/sys-include -I/home/src/gcc-4.7.0/libstdc++-v3/../libgcc -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0 -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include -I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=chrono.lo -std=gnu++11 -g -c -o chrono.lo /home/src/gcc-4.7.0/libstdc++-v3/src/c++11/chrono.cc libtool: compile: /tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc -nostdinc++ -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/ -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/sys-include -I/home/src/gcc-4.7.0/libstdc++-v3/../libgcc -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0 -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include -I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=chrono.lo -std=gnu++11 -g -c /home/src/gcc-4.7.0/libstdc++-v3/src/c++11/chrono.cc -DPIC -o chrono.o In file included from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/ratio:39:0, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/chrono:38, from /home/src/gcc-4.7.0/libstdc++-v3/src/c++11/chrono.cc:25: /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:65:11: error: '::int8_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:66:11: error: '::int16_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:67:11: error: '::int32_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:68:11: error: '::int64_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:70:11: error: '::int_fast8_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:71:11: error: '::int_fast16_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:72:11: error: '::int_fast32_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:73:11: error: '::int_fast64_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:75:11: error: '::int_least8_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:76:11: error: '::int_least16_t' has not been declared /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:77:11: error: '::int_least32_t' has not been declared [numerous cascaded errors elided] gmake[6]: *** [chrono.lo] Error 1 gmake[6]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/c++11' gmake[6]: Entering directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src' gmake[6]: *** No rule to make target `../src/c++98/libc++98convenience.la', needed by `libstdc++.la'. Stop. gmake[6]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src' gmake[5]: *** [all-recursive] Error 1 gmake[5]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3' gmake[2]: *** [all-stage1-target-libstdc++-v3] Error 2 gmake[2]: Leaving directory `/tmp/gcc-bui
[Bug bootstrap/53348] New: Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348 Bug #: 53348 Summary: Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: sk...@iskunk.org Host: powerpc-ibm-aix4.3.2.0 Target: powerpc-ibm-aix4.3.2.0 Build: powerpc-ibm-aix4.3.2.0 Bootstrapping 4.7.0 on AIX 4.3 fails with [...] Making all in include gmake[5]: Entering directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include' mkdir -p ./powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch /tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc -nostdinc++ -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/ -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/sys-include-x c++-header -nostdinc++ -g -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0 -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include -I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h \ -o powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/bits/atomic_base.h:37:0, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/atomic:41, from /home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:100: /tmp/gcc-build/./gcc/include/stdint.h:72:29: error: conflicting declaration 'typedef short int int_fast16_t' In file included from /tmp/gcc-build/./gcc/include-fixed/sys/types.h:64:0, from /usr/include/sys/lc_core.h:36, from /usr/include/sys/localedef.h:43, from /tmp/gcc-build/./gcc/include-fixed/ctype.h:131, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cctype:44, from /home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:36: /usr/include/sys/inttypes.h:143:18: error: 'int_fast16_t' has a previous declaration as 'typedef int32_t int_fast16_t' In file included from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/bits/atomic_base.h:37:0, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/atomic:41, from /home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:100: /tmp/gcc-build/./gcc/include/stdint.h:75:29: error: conflicting declaration 'typedef unsigned char uint_fast8_t' In file included from /tmp/gcc-build/./gcc/include-fixed/sys/types.h:64:0, from /usr/include/sys/lc_core.h:36, from /usr/include/sys/localedef.h:43, from /tmp/gcc-build/./gcc/include-fixed/ctype.h:131, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cctype:44, from /home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:36: /usr/include/sys/inttypes.h:145:18: error: 'uint_fast8_t' has a previous declaration as 'typedef uint32_t uint_fast8_t' In file included from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/bits/atomic_base.h:37:0, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/atomic:41, from /home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:100: /tmp/gcc-build/./gcc/include/stdint.h:76:30: error: conflicting declaration 'typedef short unsigned int uint_fast16_t' In file included from /tmp/gcc-build/./gcc/include-fixed/sys/types.h:64:0, from /usr/include/sys/lc_core.h:36, from /usr/include/sys/localedef.h:43, from /tmp/gcc-build/./gcc/include-fixed/ctype.h:131, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cctype:44, from /home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:36: /usr/include/sys/inttypes.h:146:18: error: 'uint_fast16_t' has a previous declaration as 'typedef uint32_t uint_fast16_t' gmake[5]: *** [powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1 gmake[5]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3' gmake[2]: *** [all-stage1-target-libstdc++-v3] Error 2 gmake[2]: Leaving directory `/tmp/gcc-build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-build' gmake: *
[Bug target/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009
--- Comment #8 from Daniel Richard G. 2012-05-14
03:19:36 UTC ---
Marc, thank you for the pointer. The single-line-edit case, at least, seems
straightforward enough.
Here's my stab at it:
/*
* stdlib.h on AIX 4.3 declares strtof() with a non-const first argument.
*/
fix = {
hackname = aix_strtof_const;
files = stdlib.h;
select= "(extern float +strtof)\(char \*, char \*\*\)";
c_fix = format;
c_fix_arg = "%1(const char *, char **)";
test_text = "strtof(char *, char **);";
};
[Bug target/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009 --- Comment #6 from Daniel Richard G. 2012-05-13 05:11:32 UTC --- (In reply to comment #5) > AIX 4.3 is extremely old and support was withdrawn a while ago. I am surprised > that anyone is trying to build recent versions of GCC for it. If someone wants > to develop a fixincludes patch, I can review it. The problem undoubtedly > exists, but can be worked around manually. My employer favors the use of older systems for software builds, as Unix is generally solid on forward compatibility and this prevents awkward scenarios where a customer is running an older OS than we are. Continuing GCC support is one of the downsides of this approach, of course. I wouldn't be surprised if support for AIX 4.3 is obsoleted soon, but I'd like to ensure that everything is working before that point. (I didn't follow up Solaris 8 as aggressively, and now I'm trying to get some fixes in even as the support is being ripped out of 4.8.) I can provide a unified-diff patch for the header in question; I don't know how to hack fixincludes. (If anyone can point me to a fixinclude that does the same kind of one-line change elsewhere, I could work with that...)
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238 --- Comment #10 from Daniel Richard G. 2012-05-12 05:36:16 UTC --- (In reply to comment #9) > I won't be able to work on that until I'm back from holiday in two weeks, in > the meanwhile --disable-libstdcxx-threads should allow you to bootstrap, or > maybe just --disable-libstdcxx-pch --disable-libstdcxx-pch isn't enough, alas: [...] libtool: compile: /tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc -nostdinc++ -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/src -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/src/.libs -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/ -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/sys-include -pthread -I/home/src/gcc-4.7.0/libstdc++-v3/../libgcc -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0 -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include -I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=eh_alloc.lo -g -pthread -c /home/src/gcc-4.7.0/libstdc++-v3/libsupc++/eh_alloc.cc -DPIC -o eh_alloc.o In file included from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0/bits/gthr-default.h:30:0, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0/bits/gthr.h:150, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/ext/concurrence.h:36, from /home/src/gcc-4.7.0/libstdc++-v3/libsupc++/eh_alloc.cc:37: /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0/bits/gthr-posix.h: In function 'int __gthread_mutex_timedlock(__gthread_mutex_t*, const __gthread_time_t*)': /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0/bits/gthr-posix.h:789:69: error: 'pthread_mutex_timedlock' was not declared in this scope gmake[9]: *** [eh_alloc.lo] Error 1 gmake[9]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/libsupc++' gmake[8]: *** [all-recursive] Error 1 gmake[8]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3' gmake[7]: *** [all] Error 2 gmake[7]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3' gmake[6]: *** [multi-do] Error 1 gmake[6]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3' gmake[5]: *** [all-multi] Error 2 gmake[5]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3' gmake[2]: *** [all-stage1-target-libstdc++-v3] Error 2 gmake[2]: Leaving directory `/tmp/gcc-build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-build' gmake: *** [bootstrap-lean] Error 2 Will try with --disable-libstdcxx-threads ...
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #8 from Daniel Richard G. 2012-05-12 05:09:15 UTC --- (In reply to comment #7) > Looks as though it also needs > template class function; I added that, and with the two instantiations, bootstrap completes successfully. (I don't suppose that's the fix, however, given that other systems don't need this...)
[Bug target/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009 --- Comment #3 from Daniel Richard G. 2012-05-12 04:33:41 UTC --- Created attachment 27384 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27384 /usr/include/stdlib.h from AIX 4.3 Attaching the relevant header file, to aid in development of a fixinclude rule.
[Bug target/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009 Daniel Richard G. changed: What|Removed |Added Version|4.5.2 |4.7.0 --- Comment #2 from Daniel Richard G. 2012-05-12 04:30:17 UTC --- Still an issue in 4.7.0. user@host:/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/c++98> gmake libc++98convenience.la /opt/freeware/bin/bash ../../libtool --tag CXX --tag disable-shared --mode=compile /tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc -nostdinc++ -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/ -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/sys-include -I/home/src/gcc-4.7.0/libstdc++-v3/../libgcc -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0 -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include -I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=c++locale.lo -g -c -o c++locale.lo c++locale.cc libtool: compile: /tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc -nostdinc++ -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src -L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/ -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/sys-include -I/home/src/gcc-4.7.0/libstdc++-v3/../libgcc -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0 -I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include -I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=c++locale.lo -g -c c++locale.cc -DPIC -o c++locale.o c++locale.cc: In function 'void std::__convert_to_v(const char*, _Tp&, std::ios_base::iostate&, int* const&) [with _Tp = float; std::ios_base::iostate = std::_Ios_Iostate; std::__c_locale = int*]': c++locale.cc:67:34: error: invalid conversion from 'const char*' to 'char*' [-fpermissive] In file included from /tmp/gcc-build/./gcc/include-fixed/math.h:388:0, from /tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cmath:46, from c++locale.cc:33: /tmp/gcc-build/./gcc/include-fixed/stdlib.h:479:18: error: initializing argument 1 of 'float strtof(char*, char**)' [-fpermissive] gmake: *** [c++locale.lo] Error 1
[Bug bootstrap/37122] fixed-value.c and tree-ssa-loop-ivopts.c won't compile with Sun Studio 11 on Solaris 9 due to incompatible operand types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37122
--- Comment #6 from Daniel Richard G. 2012-05-11
19:16:50 UTC ---
Created attachment 27383
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27383
updated patch for 4.7.0
I got bitten by this recently. Bootstrapping GCC 4.7.0 on Solaris 8:
[...]
cc -xarch=v9 -xildoff -c -g -DIN_GCC-DHAVE_CONFIG_H -I. -I.
-I/home/src/gcc-4.7.0/gcc -I/home/src/gcc-4.7.0/gcc/.
-I/home/src/gcc-4.7.0/gcc/../include
-I/home/src/gcc-4.7.0/gcc/../libcpp/include -I/tg/freeport/arch/sunos64/include
-I/tg/freeport/arch/sunos64/include -I/tg/freeport/arch/sunos64/include
-I/home/src/gcc-4.7.0/gcc/../libdecnumber
-I/home/src/gcc-4.7.0/gcc/../libdecnumber/dpd -I../libdecnumber
/home/src/gcc-4.7.0/gcc/tree-ssa-loop-ivopts.c -o tree-ssa-loop-ivopts.o
"/home/src/gcc-4.7.0/gcc/tree-ssa-loop-ivopts.c", line 6047: operands have
incompatible types:
struct {int cost, unsigned int complexity} ":" const struct {int cost,
unsigned int complexity}
"/home/src/gcc-4.7.0/gcc/tree-ssa-loop-ivopts.c", line 6048: operands have
incompatible types:
struct {int cost, unsigned int complexity} ":" const struct {int cost,
unsigned int complexity}
cc: acomp failed for /home/src/gcc-4.7.0/gcc/tree-ssa-loop-ivopts.c
gmake[3]: *** [tree-ssa-loop-ivopts.o] Error 2
gmake[3]: Leaving directory `/tmp/gcc-build/gcc'
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2
I'd love to patch the compiler, but Oracle won't let me do that unless I give
them a fat wad of money. David's patch to the source is no longer applicable to
4.7.0, so I'm attaching an update.
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #6 from Daniel Richard G. 2012-05-11 17:05:57 UTC --- With the new build, I now see one missing symbol instead of two. (Not sure why the earlier hacked build went through): gmake[3]: Entering directory `/tmp/gcc-4.7.0/_build/gcc' /tmp/gcc-4.7.0/_build/./prev-gcc/g++ -B/tmp/gcc-4.7.0/_build/./prev-gcc/ -B/opt/tg/powerpc-ibm-aix5.3.0.0/bin/ -nostdinc++ -B/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs -B/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/libsupc++/.libs -I/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/powerpc-ibm-aix5.3.0.0 -I/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/include -I/tmp/gcc-4.7.0/libstdc++-v3/libsupc++ -L/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs -L/tmp/gcc-4.7.0/_build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/libsupc++/.libs -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o cc1 c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.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-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 default-c.o rs6000-c.o \ cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/tg/freeport/arch/aix64/lib -L/tg/freeport/arch/aix64/lib -L/tg/freeport/arch/aix64/lib -lmpc -lmpfr -lgmp -L../zlib -lz ld: 0711-317 ERROR: Undefined symbol: .std::function::function(std::function const&) ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: error: ld returned 8 exit status gmake[3]: *** [cc1] Error 1 gmake[3]: Leaving directory `/tmp/gcc-4.7.0/_build/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory `/tmp/gcc-4.7.0/_build' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-4.7.0/_build' gmake: *** [bootstrap] Error 2 Perhaps one more instantiation is needed?
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #5 from Daniel Richard G. 2012-05-10 22:04:26 UTC --- (In reply to comment #3) > does adding this instantiation to libstdc++-v3/src/c++11/regex.cc help? Apologies Jonathan, I didn't see your comment before submitting my attachment. Preliminary results are that the instantiation allows the link to proceed. This was in a tree where the error had already occurred, however, so not the best test. I've started a new build, with the change in from the beginning, that should hopefully answer the question definitively by tomorrow.
[Bug other/53299] libiberty usage of GCC_PICFLAG causes -fPIC to be passed to non-GNU compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53299 --- Comment #3 from Daniel Richard G. 2012-05-10 20:11:15 UTC --- (In reply to comment #2) > What is the correct option to pass to the vendor compiler in order to get code > suitable for inclusion in a shared library? In this case, it's -KPIC. I don't see that this macro should be necessary, however, given that Libtool already knows the magic PIC incantation for many systems. Another excerpt from the bootstrap log (this one with --disable-lto and no -errwarn): [...] Configuring stage 1 in ./gcc configure: creating cache ./config.cache checking build system type... sparc64-sun-solaris2.8 checking host system type... sparc64-sun-solaris2.8 [...] checking for objdir... .libs checking for cc -xarch=v9 -xildoff option to produce PIC... -KPIC -DPIC checking if cc -xarch=v9 -xildoff PIC flag -KPIC -DPIC works... yes checking if cc -xarch=v9 -xildoff static flag -Bstatic works... no checking if cc -xarch=v9 -xildoff supports -c -o file.o... yes checking if cc -xarch=v9 -xildoff supports -c -o file.o... (cached) yes checking whether the cc -xarch=v9 -xildoff linker (ld -64) supports shared libraries... yes checking dynamic linker characteristics... solaris2.8 ld.so [...]
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #4 from Daniel Richard G. 2012-05-10 15:04:22 UTC --- Created attachment 27364 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27364 Workaround to provide the two missing symbols I needed a working 4.7.0, and don't use the STL, so I put together a small workaround for this bug. Compile this source file, and add the object to the appropriate libstdc++.a library. More details in the file. (Note that I build GCC with --disable-shared; "fixing" a shared libstdc++ would be a bit more involved)
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #2 from Daniel Richard G. 2012-05-10 13:54:12 UTC --- I can avoid this error during bootstrap by configuring with --disable-build-poststage1-with-cxx, but then I get the same link error when building regular C++ programs with the newly-built compiler.
[Bug other/53299] New: libiberty usage of GCC_PICFLAG causes -fPIC to be passed to non-GNU compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53299 Bug #: 53299 Summary: libiberty usage of GCC_PICFLAG causes -fPIC to be passed to non-GNU compiler Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: sk...@iskunk.org Host: sparc64-sun-solaris2.8 Target: sparc64-sun-solaris2.8 Build: sparc64-sun-solaris2.8 In the course of bootstrapping 4.7.0 on Solaris using the vendor compiler, I saw this: [...] config.status: creating testsuite/Makefile config.status: creating config.h config.status: executing default commands gmake[3]: Entering directory `/tmp/gcc-build/libiberty' if [ x"-fPIC" != x ] && [ ! -d pic ]; then \ mkdir pic; \ else true; fi touch stamp-picdir if [ x"-fPIC" != x ]; then \ cc -xarch=v9 -xildoff -errwarn=%all -c -DHAVE_CONFIG_H -g -I. -I/home/src/gcc-4.7.0/libiberty/../include -fPIC /home/src/gcc-4.7.0/libiberty/regex.c -o pic/regex.o; \ else true; fi cc: Warning: illegal option -fPIC cc -xarch=v9 -xildoff -errwarn=%all -c -DHAVE_CONFIG_H -g -I. -I/home/src/gcc-4.7.0/libiberty/../include /home/src/gcc-4.7.0/libiberty/regex.c -o regex.o if [ x"-fPIC" != x ]; then \ cc -xarch=v9 -xildoff -errwarn=%all -c -DHAVE_CONFIG_H -g -I. -I/home/src/gcc-4.7.0/libiberty/../include -fPIC /home/src/gcc-4.7.0/libiberty/cplus-dem.c -o pic/cplus-dem.o; \ else true; fi cc: Warning: illegal option -fPIC [...] I traced the -fPIC flag to the GCC_PICFLAG macro in the libiberty configure script. There needs to be a check for whether $CC is GNU or not, because passing in a bogus flag won't necessarily raise an error (even with -errwarn).
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238 --- Comment #8 from Daniel Richard G. 2012-05-08 18:18:04 UTC --- I did a non-bootstrap build to speed things up a bit. (The system already has GCC 4.5.2.) First: Your patch needs a couple of ";;" sprinkled in there :-) Second: With the patch, after working around some unrelated integer-type issues, I get the following error: [...] Making all in include gmake[4]: Entering directory `/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include' mkdir -p ./powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch /tmp/gcc-4.7.0/_build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-4.7.0/_build/./gcc -nostdinc++ -L/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src -L/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/ -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/sys-include-x c++-header -nostdinc++ -g -O2 -I/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0 -I/tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include -I/tmp/gcc-4.7.0/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /tmp/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h \ -o powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /tmp/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:102:0: /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:62:13: error: '__gthread_cond_t' does not name a type /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:67:5: error: '__native_type' does not name a type /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:71:13: error: '__native_type' does not name a type /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:141:5: error: 'native_handle_type' does not name a type /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable: In member function 'std::cv_status std::condition_variable::__wait_until_impl(std::unique_lock&, const std::chrono::time_point<_Clock, _Duration>&)': /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:157:2: error: '__gthread_time_t' was not declared in this scope /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:157:19: error: expected ';' before '__ts' /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:163:28: error: '_M_cond' was not declared in this scope /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:164:7: error: '__ts' was not declared in this scope /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:164:11: error: there are no arguments to '__gthread_cond_timedwait' that depend on a template parameter, so a declaration of '__gthread_cond_timedwait' must be available [-fpermissive] /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/condition_variable:164:11: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) In file included from /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/future:41:0, from /tmp/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:104: /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread: At global scope: /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:63:13: error: '__gthread_t' does not name a type /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:70:7: error: 'native_handle_type' does not name a type /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:76:29: error: expected ')' before '__id' /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:174:5: error: 'native_handle_type' does not name a type /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread: In constructor 'std::thread::id::id()': /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:73:23: error: class 'std::thread::id' does not have any field named '_M_thread' /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread: In function 'bool std::operator==(std::thread::id, std::thread::id)': /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:84:36: error: 'class std::thread::id' has no member named '_M_thread' /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:84:51: error: 'class std::thread::id' has no member named '_M_thread' /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread:84:60: error: '__gthread_equal' was not declared in this scope /tmp/gcc-4.7.0/_build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/thread: In function 'bool std::operator<(std::thread::id, std::thread::id)': /tmp/gcc-4.
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238 --- Comment #7 from Daniel Richard G. 2012-05-07 21:09:43 UTC --- (In reply to comment #6) > Created attachment 27320 [details] > diff of regenerated configure Jonathan, thank you for the patch, and the regen. I'm starting a new build to test the patch. This AIX machine runs rather slow, so I'll need a few days to get back to you; please hold tight!
[Bug bootstrap/53266] Error: Unrecognized opcode: `mulhwu'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53266 --- Comment #2 from Daniel Richard G. 2012-05-07 17:42:43 UTC --- (In reply to comment #1) > mulhwu is a powerpc but not rs6000 instruction. When a file failed to compile, I noticed that specifying -mcpu=powerpc got things going again. I'm not clear on how GCC distinguishes powerpc versus rs6000, but as far as -mcpu is concerned, the former value seems to exclude mulhwu.
[Bug bootstrap/53266] New: Error: Unrecognized opcode: `mulhwu'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53266 Bug #: 53266 Summary: Error: Unrecognized opcode: `mulhwu' Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: sk...@iskunk.org Host: powerpc-ibm-aix4.3.2.0 Target: powerpc-ibm-aix4.3.2.0 Build: powerpc-ibm-aix4.3.2.0 Bootstrapping GCC 4.7.0 on AIX 4.3 fails with [...] gmake[3]: Entering directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libgcc' # If this is the top-level multilib, build all the other # multilibs. DEFINES='' HEADERS='' \ /home/src/gcc-4.7.0/libgcc/mkheader.sh > tmp-libgcc_tm.h /opt/freeware/bin/bash /home/src/gcc-4.7.0/libgcc/../move-if-change tmp-libgcc_tm.h libgcc_tm.h echo timestamp > libgcc_tm.stamp /tmp/gcc-build/./gcc/xgcc -B/tmp/gcc-build/./gcc/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/ -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -mlong-double-128 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -mlong-double-128 -I. -I. -I../.././gcc -I/home/src/gcc-4.7.0/libgcc -I/home/src/gcc-4.7.0/libgcc/. -I/home/src/gcc-4.7.0/libgcc/../gcc -I/home/src/gcc-4.7.0/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /home/src/gcc-4.7.0/libgcc/libgcc2.c /tmp//cczJLmgC.s: Assembler messages: /tmp//cczJLmgC.s:379: Error: Unrecognized opcode: `mulhwu' gmake[3]: *** [_muldi3.o] Error 1 gmake[3]: Leaving directory `/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libgcc' gmake[2]: *** [all-stage1-target-libgcc] Error 2 gmake[2]: Leaving directory `/tmp/gcc-build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-build' gmake: *** [bootstrap-lean] Error 2 It appears to be the same issue as reported in a comment long ago: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12691#c2 My error was obtained using --with-gnu-as and --disable-multilib. After some experimentation, I got rid of --disable-multilib, and configured the tree with --with-cpu=powerpc --disable-aix64 --disable-powercpu, which allowed the bootstrap to proceed without the above error. However, given that build=host=target, and that the system triplet explicitly denotes a 32-bit PowerPC processor, the configuration phase should have detected the need to avoid unsupported instructions on its own.
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238 --- Comment #4 from Daniel Richard G. 2012-05-05 16:05:30 UTC --- (In reply to comment #3) > If you're using --enable-thread=posix then it should be defined. I haven't used --enable-thread=posix, and if I invoke ".../xgcc -v", I see "Thread model: aix". So it seems the test passes because _PTHREADS is not defined. Shouldn't the cpp conditional in the test be written as #if !defined(_PTHREADS) || !defined(_POSIX_TIMEOUTS) || _POSIX_TIMEOUTS <= 0 ?
[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238 --- Comment #2 from Daniel Richard G. 2012-05-04 20:33:46 UTC --- (In reply to comment #1) > You'll need to figure out why the configure test passes, most of us who work > on > that bit of code don't have access to AIX Below is the relevant excerpt from gcc-4.7.0/libstdc++-v3/acinclude.m4: 8< AC_MSG_CHECKING([whether it can be safely assumed that mutex_timedlock is available]) AC_TRY_COMPILE([#include ], [ // In case of POSIX threads check _POSIX_TIMEOUTS. #if (defined(_PTHREADS) \ && (!defined(_POSIX_TIMEOUTS) || _POSIX_TIMEOUTS <= 0)) #error #endif ], [ac_gthread_use_mutex_timedlock=1], [ac_gthread_use_mutex_timedlock=0]) AC_DEFINE_UNQUOTED(_GTHREAD_USE_MUTEX_TIMEDLOCK, $ac_gthread_use_mutex_timedlock, [Define to 1 if mutex_timedlock is available.]) if test $ac_gthread_use_mutex_timedlock = 1 ; then res_mutex_timedlock=yes ; else res_mutex_timedlock=no ; fi AC_MSG_RESULT([$res_mutex_timedlock]) >8 Neither _PTHREADS nor _POSIX_TIMEOUTS appear anywhere in /usr/include/. I'm a little mystified as to why this test is relying entirely on feature test macros, instead of checking for the existence of pthread_mutex_timedlock directly...
[Bug bootstrap/53238] New: Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238
Bug #: 53238
Summary: Bootstrap failure: error: 'pthread_mutex_timedlock'
was not declared in this scope
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
Host: powerpc-ibm-aix4.3.2.0
Target: powerpc-ibm-aix4.3.2.0
Build: powerpc-ibm-aix4.3.2.0
Bootstrapping 4.7.0 on AIX 4.3...
[...]
gmake[9]: Entering directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include'
mkdir -p ./powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch
/tmp/gcc-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-build/./gcc -nostdinc++
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/src
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/src/.libs
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/
-isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem
/opt/tg/powerpc-ibm-aix4.3.2.0/sys-include -pthread -x c++-header -nostdinc++
-g -pthread
-I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0
-I/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include
-I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x
/home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h \
-o powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0/bits/gthr-default.h:30:0,
from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0/bits/gthr.h:150,
from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/ext/atomicity.h:34,
from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/bits/ios_base.h:41,
from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/ios:43,
from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/istream:40,
from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/sstream:39,
from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/complex:47,
from
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/ccomplex:42,
from
/home/src/gcc-4.7.0/libstdc++-v3/include/precompiled/stdc++.h:53:
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0/bits/gthr-posix.h:
In function 'int __gthread_mutex_timedlock(__gthread_mutex_t*, const
__gthread_time_t*)':
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0/bits/gthr-posix.h:789:69:
error: 'pthread_mutex_timedlock' was not declared in this scope
gmake[9]: *** [powerpc-ibm-aix4.3.2.0/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1
gmake[9]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3/include'
gmake[8]: *** [all-recursive] Error 1
gmake[8]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3'
gmake[7]: *** [all] Error 2
gmake[7]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/pthread/libstdc++-v3'
gmake[6]: *** [multi-do] Error 1
gmake[6]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3'
gmake[5]: *** [all-multi] Error 2
gmake[5]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3'
gmake[4]: *** [all-recursive] Error 1
gmake[4]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3'
gmake[3]: *** [all] Error 2
gmake[3]: Leaving directory
`/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3'
gmake[2]: *** [all-stage1-target-libstdc++-v3] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2
This system does not know about pthread_mutex_timedlock:
$ find /usr/include -type f -exec grep -l pthread_mutex_timedlock {} \;
$
However, a configure check appears to have determined otherwise. In
/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/config.log
, I see the following:
configure:65564: checking whether it can be safely assumed that mutex_timedlock
is available
configure:65583: /tmp/gcc-build/./gcc/xgcc -shared-libgcc
-B/tmp/gcc-build/./gcc -nostdinc++
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src
-L/tmp/gcc-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs
-B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/
-isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem
/opt/tg/powerpc-ibm-aix4.3.2.0/sys-include-c -g -fno-exceptions
-I/home/src/gcc-4.7.0/libstdc++-v3/../l
[Bug bootstrap/53237] New: Bootstrap fails due to mixed declarations and code (c-lex.c)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53237
Bug #: 53237
Summary: Bootstrap fails due to mixed declarations and code
(c-lex.c)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
Building 4.7.0 on Solaris using the Sun compiler...
[...]
cc -xarch=v9 -xildoff -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -DIN_GCC
-DHAVE_CONFIG_H -I. -Ic-family -I/home/src/gcc-4.7.0/gcc
-I/home/src/gcc-4.7.0/gcc/c-family -I/home/src/gcc-4.7.0/gcc/../include
-I/home/src/gcc-4.7.0/gcc/../libcpp/include -I/tg/freeport/arch/sunos64/include
-I/tg/freeport/arch/sunos64/include -I/tg/freeport/arch/sunos64/include
-I/home/src/gcc-4.7.0/gcc/../libdecnumber
-I/home/src/gcc-4.7.0/gcc/../libdecnumber/dpd -I../libdecnumber
/home/src/gcc-4.7.0/gcc/c-family/c-lex.c -o c-family/c-lex.o
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 353: syntax error before or
at: char
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 354: undefined symbol: str
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 354: cannot dereference
non-pointer type
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 355: syntax error before or
at: literal
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 357: undefined symbol: literal
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 357: warning: improper
pointer/integer combination: op "="
cc: acomp failed for /home/src/gcc-4.7.0/gcc/c-family/c-lex.c
gmake[3]: *** [c-family/c-lex.o] Error 2
gmake[3]: Leaving directory `/tmp/gcc-build/gcc'
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2
The relevant portion of c-lex.c is declaring "char *str" in the middle of an
if{} block.
[Bug other/53178] fixinclude needed for iso/ctype_iso.h on Solaris 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53178 --- Comment #2 from Daniel Richard G. 2012-05-02 15:57:24 UTC --- (In reply to comment #1) > Is this problem also present in more recent Solaris releases? It's gone as of Solaris 10 (the macros have the necessary casts), but I don't have a 9 system to check. Can a fixinclude go in, just so that 4.7 can have reasonably complete -Werror support for Solaris 8? No previous version of GCC is going to have that.
[Bug bootstrap/52847] "case" shell quoting problem in top-level makefile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52847 --- Comment #3 from Daniel Richard G. 2012-05-01 23:01:28 UTC --- (In reply to comment #1) > You should not need -mminimal-toc because of this toplevel makefile part. Ah, good to know. If I don't set -mminimal-toc in CC, I see this when larger executables are being linked... ld: 0711-783 WARNING: TOC overflow. TOC size: 474420Maximum size: 65536 Extra instructions are being generated for each reference to a TOC symbol if the symbol is in the TOC overflow area. ...but the warning is non-fatal, and bootstrapping is otherwise unaffected.
[Bug other/53179] fixinclude needed for pthread.h on AIX 5.3 (PTHREAD_ONCE_INIT)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53179 --- Comment #1 from Daniel Richard G. 2012-05-01 20:17:24 UTC --- Created attachment 27275 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27275 Fixed version of pthread.h
[Bug other/53179] New: fixinclude needed for pthread.h on AIX 5.3 (PTHREAD_ONCE_INIT)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53179
Bug #: 53179
Summary: fixinclude needed for pthread.h on AIX 5.3
(PTHREAD_ONCE_INIT)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
Host: powerpc-ibm-aix5.3.0.0
Target: powerpc-ibm-aix5.3.0.0
Build: powerpc-ibm-aix5.3.0.0
Created attachment 27274
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27274
/usr/include/pthread.h from AIX 5.3
$ cat pth.c
#include
pthread_once_t once = PTHREAD_ONCE_INIT;
int main(void) { return 0; }
$ OBJECT_MODE=32 gcc -W -Wall -c pth.c
pth.c:3:1: warning: missing braces around initializer
pth.c:3:1: warning: (near initialization for 'once.__on_word')
$ gcc -maix64 -W -Wall -c pth.c
pth.c:3:1: warning: missing braces around initializer
pth.c:3:1: warning: (near initialization for 'once.__on_word')
This is bad if you're building with -Werror.
Inexplicably, both the 32- and 64-bit forms of the PTHREAD_ONCE_INIT
initializer lack a pair of curly-braces. This despite other initializers in the
same file having the same form, and the correct double-brace syntax.
I am attaching a copy of both the original, unmodified pthread.h header, and my
manually-fixed version.
[Bug other/53178] New: fixinclude needed for iso/ctype_iso.h on Solaris 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53178
Bug #: 53178
Summary: fixinclude needed for iso/ctype_iso.h on Solaris 8
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
Host: i386-pc-solaris2.8
Target: i386-pc-solaris2.8
Build: i386-pc-solaris2.8
Created attachment 27273
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27273
/usr/include/iso/ctype_iso.h from Solaris 8
$ cat ctype.c
#include
int main(void)
{
char c = 'A';
return isgraph(c);
}
$ gcc -W -Wall -c ctype.c
ctype.c: In function 'main':
ctype.c:7:2: warning: array subscript has type 'char' [-Wchar-subscripts]
This is bad if you're building with -Werror.
The problem:
$ grep isgraph /usr/include/iso/ctype_iso.h
extern int isgraph(int);
inline int isgraph(int c) { return (__ctype_mask[c] & _ISGRAPH); }
inline int isgraph(int c) { return ((__ctype + 1)[c] & (_P | _U | _L | _N)); }
#defineisgraph(c)(__ctype_mask[c] & _ISGRAPH)
#defineisgraph(c)((__ctype + 1)[c] & (_P | _U | _L | _N))
#defineisgraph(c)((_ctype + 1)[c] & (_P | _U | _L | _N))
The solution:
$ grep isgraph
/opt/gcc/lib/gcc/i386-pc-solaris2.8/4.7.0/include-fixed/iso/ctype_iso.h
extern int isgraph(int);
inline int isgraph(int c) { return (__ctype_mask[c] & _ISGRAPH); }
inline int isgraph(int c) { return ((__ctype + 1)[c] & (_P | _U | _L | _N)); }
#defineisgraph(c)(__ctype_mask[(int)(c)] & _ISGRAPH)
#defineisgraph(c)((__ctype + 1)[(int)(c)] & (_P | _U | _L | _N))
#defineisgraph(c)((_ctype + 1)[(int)(c)] & (_P | _U | _L | _N))
Same deal with the other isx() routines. I'm attaching the unmodified
system header file for reference.
[Bug bootstrap/52850] Linker path ends up using wrong zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52850 --- Comment #2 from Daniel Richard G. 2012-04-24 15:18:33 UTC --- (In reply to comment #1) > That sounds like an user problem rather than a GCC issue. >From the "Installing GCC: Configuration" doc: --with-system-zlib Use installed `zlib' rather than that included with GCC. If this option was not given (and it wasn't), then GCC should be using its own zlib, regardless of the presence of other instances of zlib outside of the build tree.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 Daniel Richard G. changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #36 from Daniel Richard G. 2012-04-12 16:28:36 UTC --- My sysadmin recently upgraded the troublesome AIX 5.3 machine in question, and this has made the linker issues go away. The minimal test case now passes, and I can compile and link programs again without any workarounds. This is true both for GCC 4.5.1 (same build as in the original report), and the older GCC 2.9 bundled with the system. I'll provide the same patch-level information as Paul Pryor did earlier: $ oslevel -s 5300-12-05-1140 $ ls -l /usr/bin/ld lrwxrwxrwx1 bin bin 15 Dec 02 2004 /usr/bin/ld -> /usr/ccs/bin/ld $ ls -l /usr/ccs/bin/ld -r-xr-xr-x1 bin bin 38942 Aug 09 2011 /usr/ccs/bin/ld $ lslpp -h bos.rte.bind_cmds Fileset Level Action Status Date Time Path: /usr/lib/objrepos bos.rte.bind_cmds 5.3.0.0 COMMIT COMPLETE 12/02/04 17:04:24 5.3.0.1 COMMIT COMPLETE 12/06/04 11:52:51 5.3.0.30 COMMIT COMPLETE 09/30/10 10:04:35 5.3.0.40 COMMIT COMPLETE 10/01/10 11:02:18 5.3.0.53 COMMIT COMPLETE 10/01/10 14:15:17 5.3.0.65 COMMIT COMPLETE 10/05/10 09:48:48 5.3.7.5 COMMIT COMPLETE 10/06/10 10:04:03 5.3.8.6 COMMIT COMPLETE 10/07/10 08:13:13 5.3.9.7 COMMIT COMPLETE 10/08/10 08:33:35 5.3.10.4 COMMIT COMPLETE 10/14/10 10:35:13 5.3.11.4 COMMIT COMPLETE 10/15/10 23:31:34 5.3.12.1 COMMIT COMPLETE 10/16/10 00:05:56 5.3.12.4 COMMIT COMPLETE 04/03/12 12:34:21 $ lslpp -i bos.rte.bind_cmds Vendor Fileset CodeProduct Id Feature Id Package Name Path: /usr/lib/objrepos bos.rte.bind_cmds 5.3.0.0 5765-E6200 bos I will be happy to provide additional details about the configuration of this system if anyone needs it. There does not appear to be anything left to do here as far as GCC is concerned, so I'm marking this bug as invalid. If anyone feels differently, feel free to change it back.
[Bug bootstrap/52887] New: Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 Bug #: 52887 Summary: Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function const&) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: sk...@iskunk.org Host: powerpc-ibm-aix5.3.0.0 Target: powerpc-ibm-aix5.3.0.0 Build: powerpc-ibm-aix5.3.0.0 Bootstrapping GCC 4.7.0 on an AIX 5.3 system fails with /tmp/gcc-4.7.0-build/./prev-gcc/g++ -B/tmp/gcc-4.7.0-build/./prev-gcc/ -B/opt/tg/powerpc-ibm-aix5.3.0.0/bin/ -nostdinc++ -B/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs -B/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/libsupc++/.libs -I/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/powerpc-ibm-aix5.3.0.0 -I/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/include -I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -L/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs -L/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/libsupc++/.libs -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o cc1 c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.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-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 default-c.o rs6000-c.o \ cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -lmpc -lmpfr -lgmp -L../zlib -lz ld: 0711-317 ERROR: Undefined symbol: .std::function::function(std::function const&) ld: 0711-317 ERROR: Undefined symbol: .std::function::function(std::function const&) ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: error: ld returned 8 exit status gmake[3]: *** [cc1] Error 1 gmake[3]: Leaving directory `/tmp/gcc-4.7.0-build/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory `/tmp/gcc-4.7.0-build' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-4.7.0-build' gmake: *** [bootstrap-lean] Error 2 The build tree was configured with '--prefix=/opt/tg' '--disable-dependency-tracking' '--disable-maintainer-mode' '--program-prefix=tg-' '--disable-shared' '--disable-nls' '--enable-version-specific-runtime-libs' '--with-pic' '--with-mpc=/usr/local' '--with-mpfr=/usr/local' '--with-gmp=/usr/local' 'CC=tg-gcc -mminimal-toc' 'CXX=false' '--enable-languages=c,c++'
[Bug bootstrap/52850] New: Linker path ends up using wrong zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52850 Bug #: 52850 Summary: Linker path ends up using wrong zlib Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: sk...@iskunk.org Bootstrapping GCC on AIX fails with tg-gcc -mminimal-toc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -Wl,-bmaxdata:0x4000 -o cc1 c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.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-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 default-c.o rs6000-c.o \ cc1-checksum.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a-L/tg/freeport/arch/aix64/lib -L/tg/freeport/arch/aix64/lib -L/tg/freeport/arch/aix64/lib -lmpc -lmpfr -lgmp -L../zlib -lz ld: 0711-317 ERROR: Undefined symbol: .deflateInit_ ld: 0711-317 ERROR: Undefined symbol: .zError ld: 0711-317 ERROR: Undefined symbol: .deflate ld: 0711-317 ERROR: Undefined symbol: .deflateEnd ld: 0711-317 ERROR: Undefined symbol: .inflateInit_ ld: 0711-317 ERROR: Undefined symbol: .inflate ld: 0711-317 ERROR: Undefined symbol: .inflateEnd ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status gmake[3]: *** [cc1] Error 1 gmake[3]: Leaving directory `/tmp/gcc-4.7.0-build/gcc' gmake[2]: *** [all-stage1-gcc] Error 2 gmake[2]: Leaving directory `/tmp/gcc-4.7.0-build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-4.7.0-build' gmake: *** [bootstrap-lean] Error 2 The problem is that there is an unsuitable copy of libz installed under /tg/freeport/arch/aix64/lib (where suitable copies of gmp/mpfr/mpc are located), but since "-L../zlib -lz" is specified after "-L/tg/freeport/arch/aix64/lib", zlib is obtain from the latter location. Either "-L../zlib" should be specified prior to any user-supplied library paths, or the link invocation should specify the libz library file explicitly rather than use "-lz".
[Bug other/52847] New: "case" shell quoting problem in top-level makefile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52847 Bug #: 52847 Summary: "case" shell quoting problem in top-level makefile Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: sk...@iskunk.org [Configured on AIX with CC="gcc -mminimal-toc"] $ gmake bootstrap-lean echo stage3 > stage_final /opt/freeware/bin/bash: command substitution: line 1: syntax error near unexpected token `-mminimal-toc' /opt/freeware/bin/bash: command substitution: line 1: `case gcc -mminimal-toc in *gcc*) echo -Wl,-bbigtoc ;; esac;' gmake[1]: Entering directory `/tmp/gcc-4.7.0-build' gmake[2]: Entering directory `/tmp/gcc-4.7.0-build' gmake[2]: Leaving directory `/tmp/gcc-4.7.0-build' gmake[2]: Entering directory `/tmp/gcc-4.7.0-build' Configuring stage 1 in ./intl configure: creating cache ./config.cache checking whether gmake sets $(MAKE)... yes [...] The above warning comes from the below line in the top-level makefile, under the "host and target specific makefile fragments come in here" header: LDFLAGS = `case $(CC) in *gcc*) echo -Wl,-bbigtoc ;; esac;` I believe this needs to be written as LDFLAGS = `case "$(CC)" in *gcc*) echo -Wl,-bbigtoc ;; esac;` in order to accommodate values of $(CC) which contain spaces.
[Bug c/37187] please provide a way to treat -pedantic as warning when using -Werror
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37187 Daniel Richard G. changed: What|Removed |Added CC||skunk at iskunk dot org --- Comment #5 from Daniel Richard G. 2011-11-18 20:06:13 UTC --- There is still no way to defang -pedantic warnings with -Werror as of GCC 4.6.1.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
--- Comment #34 from Daniel Richard G. 2011-09-15
14:01:36 UTC ---
(In reply to comment #33)
Vladimir, this [GCC] bug report has nothing to do with the assembler
segfaulting. The problem is that the linker can't link what the assembler is
producing ("ld: 0711-593 SEVERE ERROR").
