http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51999
Bug #: 51999
Summary: gcc-4.7-20120114 v. AIX 6.1
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@antinode.info
While chasing an optimization-sensitive bug in some Info-ZIP UnZip
code, I've been bumbling around for a while, trying to build a recent
GCC on my AIX system ("make bootstrap-lean"), in the hope of resolving
that apparent optimization problem. The latest released GCC version,
4.6.2, has been nothing but trouble, beginning with "as" problems like
this:
[...]
/tmp//ccnWeopd.s: line 31735: 1252-040 The specified expression is not valid.
Make sure that all symbols are defined.
Check the rules on symbols used in an arithmetic expression
concerning relocation.
[...]
My first attempt to work around this was to build and install GNU
Binutils 2.22, but I later realized that my pre-built GCC would use the
IBM "as", no matter what.
blue# gcc -v
Using built-in specs.
Target: powerpc-ibm-aix6.1.0.0
Configured with: ../configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--enab
le-languages=c,c++,java --prefix=/opt/freeware --enable-threads
--enable-version
-specific-runtime-libs --host=powerpc-ibm-aix6.1.0.0
--target=powerpc-ibm-aix6.1
.0.0 --build=powerpc-ibm-aix6.1.0.0 --disable-libjava-multilib
Thread model: aix
gcc version 4.2.0
A visit to IBM Fix Central seems to have provided an improved "as",
which solves that problem. With that fix, I could get so far as an
"internal compiler error" in stage 2:
[...]
/usr/local/gnu/gcc/gcc-4.6.2_obj/./gcc/xgcc
-B/usr/local/gnu/gcc/gcc-4.6.2_obj/.
/gcc/ -B/usr/local/powerpc-ibm-aix6.1.0.0/bin/
-B/usr/local/powerpc-ibm-aix6.1.0
.0/lib/ -isystem /usr/local/powerpc-ibm-aix6.1.0.0/include -isystem
/usr/local/p
owerpc-ibm-aix6.1.0.0/sys-include -g -O2 -pthread -O2 -g -O2 -DIN_GCC -W
-
Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-
style-definition -isystem ./include -mlong-double-128 -g -DHAVE_GTHR_DEFAULT
-
DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -I. -I.
-I../../../.
/gcc -I../../../../gcc-4.6.2/libgcc -I../../../../gcc-4.6.2/libgcc/.
-I../../../
../gcc-4.6.2/libgcc/../gcc -I../../../../gcc-4.6.2/libgcc/../include
-DHAVE_CC_
TLS -DUSE_EMUTLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep
-fe
xceptions -c ../../../../gcc-4.6.2/libgcc/../gcc/unwind-dw2.c
../../../../gcc-4.6.2/libgcc/../gcc/unwind-dw2.c: In function
'uw_init_context_1
':
../../../../gcc-4.6.2/libgcc/../gcc/unwind-dw2.c:1461:5: warning: missing
braces
around initializer [-Wmissing-braces]
../../../../gcc-4.6.2/libgcc/../gcc/unwind-dw2.c:1461:5: warning: (near
initiali
zation for 'once_regsizes.__on_word') [-Wmissing-braces]
In file included from ../../../../gcc-4.6.2/libgcc/../gcc/unwind-dw2.c:1582:0:
../../../../gcc-4.6.2/libgcc/../gcc/unwind.inc: In function
'_Unwind_ForcedUnwin
d_Phase2':
../../../../gcc-4.6.2/libgcc/../gcc/unwind.inc:189:1: error: unrecognizable
insn
:
(insn 34 33 35 8 (set (mem/v:DI (plus:DI (reg/f:SI 1 1)
(const_int 20 [0x14])) [0 S8 A8])
(reg:SI 2 2)) ../../../../gcc-4.6.2/libgcc/../gcc/unwind.inc:163 -1
(nil))
../../../../gcc-4.6.2/libgcc/../gcc/unwind.inc:189:1: internal compiler error:
i
n extract_insn, at recog.c:2109
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
gmake[5]: *** [unwind-dw2.o] Error 1
gmake[5]: Leaving directory
`/usr/local/gnu/gcc/gcc-4.6.2_obj/powerpc-ibm-aix6.1
.0.0/pthread/libgcc'
gmake[4]: *** [multi-do] Error 1
gmake[4]: Leaving directory
`/usr/local/gnu/gcc/gcc-4.6.2_obj/powerpc-ibm-aix6.1
.0.0/libgcc'
gmake[3]: *** [all-multi] Error 2
gmake[3]: Leaving directory
`/usr/local/gnu/gcc/gcc-4.6.2_obj/powerpc-ibm-aix6.1
.0.0/libgcc'
gmake[2]: *** [all-stage1-target-libgcc] Error 2
gmake[2]: Leaving directory `/usr/local/gnu/gcc/gcc-4.6.2_obj'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]
Throwing up my hands at that outcome, I moved along to a recent
snapshot, gcc-4.7-20120114, which did rather better, but was not
problem-free. Some potentially interesting problems are described
below.
In stage2, compiling "gcc/incpath.c" failed with a bunch of
complaints like:
[...]
../../gcc-4.7-20120114/gcc/incpath.c: In function 'void
add_standard_paths(const char*, const char*, const char*, int)':
../../gcc-4.7-20120114/gcc/incpath.c:152:54: error: missing sentinel in
function call [-Werror=format]
[...]
Around here, the system header files define "NULL" as (plain) "0", not
as a pointer, which apparently triggers this complaint from the new gcc
version. Seeing no real consensus in other code, I added some "void *"
type casts:
diff gcc-4.7-20120114/gcc/incpath.c_orig gcc-4.7-20120114/gcc/incpath.c
152c152
< char *str = concat (iprefix, p->fname + len, NULL);
---
> char *str = concat (iprefix, p->fname + len, (void *)NULL);
154c154
< str = concat (str, dir_separator_str, imultilib, NULL);
---
> str = concat (str, dir_separator_str, imultilib, (void
> *)NULL);
169c169
< str = concat (sysroot, p->fname, NULL);
---
> str = concat (sysroot, p->fname, (void *)NULL);
184c184
< dummy = concat (gcc_exec_prefix, "dummy", NULL);
---
> dummy = concat (gcc_exec_prefix, "dummy", (void *)NULL);
192c192
< NULL);
---
> (void *)NULL);
199c199
< str = concat (str, dir_separator_str, imultilib, NULL);
---
> str = concat (str, dir_separator_str, imultilib, (void *)NULL);
297c297
< p->name = concat (sysroot, p->name + 1, NULL);
---
> p->name = concat (sysroot, p->name + 1, (void *)NULL);
That change got me to the next problem. Somewhere in the GCC
builders, there's an "ar" command which makes an object library from a
big-long list of object files, which apparently ran me out of
paging/swap space (or address space?):
[...]
rm -rf libbackend.a
ar rc libbackend.a insn-attrtab.o [...]
[...] xcoffout.o rs6000.o host-default.o
gmake[3]: *** [libbackend.a] Segmentation fault (core dumped)
gmake[3]: *** Deleting file `libbackend.a'
gmake[3]: Leaving directory `/usr/local/gnu/gcc/gcc-4.7-20120114_obj/gcc'
gmake[2]: *** [all-stage2-gcc] Error 2
gmake[2]: Leaving directory `/usr/local/gnu/gcc/gcc-4.7-20120114_obj'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/usr/local/gnu/gcc/gcc-4.7-20120114_obj'
gmake: *** [bootstrap-lean] Error 2
blue#
Or, on another try, perhaps more helpfully:
[...] xcoffout.o rs6000.o host-default.o
ar: libbackend.a: Memory exhausted
[...]
I'll admit that my paging space was pretty small (only 512MB), but
4GB of physical memory had covered my usual requirements, so I wasn't
expecting this kind of problem. Interestingly, adding another 7.5GB of
paging space (so, 4GB physical plus 8GB paging) helped not at all.
Eventually, it dawned on me that the "ar" which was failing was my
recently installed GNU Binutils 2.22 "ar". I had placed
"/usr/local/bin" at the front of my PATH, because I had had trouble
previously with GCC requiring GNU editions of "sed" and, I believe,
other programs, too (possibly on some non-AIX system). Sadly, that
causes the GNU Binutils "ar" program to be used in preference to the IBM
"ar", and it fails as as shown above. Rearranging PATH to prefer the
IBM "ar" got me to the next GNU Binutils problem:
[...]
ranlib libbackend.a
gmake[3]: *** [libbackend.a] Segmentation fault (core dumped)
[...]
Concluding that GNU Binutils on AIX is a cruel hoax, I rearranged
PATH to prefer the IBM "ar", "as", "ld", "nm", "ranlib", and "strip".
(Did I miss anything important?) Then, configuring with the explicit
options "--with-as=/usr/bin/as" and "--with-ld=/usr/bin/ld" got me to
more "error: missing sentinel" complaints from "gcc/prefix.c", so I
added "void *" type casts to more modules (perhaps not all necessary,
but the shotgun approach looked more efficient than detecting one such
file per build, where one build corresponds to approximately one day):
blue# find gcc-4.7-20120114 -name '*.c_orig'
gcc-4.7-20120114/gcc/collect2.c_orig
gcc-4.7-20120114/gcc/config/rs6000/driver-rs6000.c_orig <
gcc-4.7-20120114/gcc/dbxout.c_orig
gcc-4.7-20120114/gcc/diagnostic.c_orig <
gcc-4.7-20120114/gcc/dwarf2out.c_orig
gcc-4.7-20120114/gcc/gcc-ar.c_orig
gcc-4.7-20120114/gcc/gcc.c_orig
gcc-4.7-20120114/gcc/incpath.c_orig <
gcc-4.7-20120114/gcc/lto-wrapper.c_orig <
gcc-4.7-20120114/gcc/opts-common.c_orig
gcc-4.7-20120114/gcc/opts.c_orig
gcc-4.7-20120114/gcc/prefix.c_orig <
("<" marks an observed compile failure. Others are speculative.)
I tried to skip files which are built using g++, as that compiler
seems not to care about this, but I didn't try very hard, and may have
over-corrected. A better course may be to adjust a header file
somewhere, to get a more acceptable definition of NULL, but I have no
idea where/how that might be done for GCC. (Nor what damage that might
do to code which is not expecting NULL to be a pointer.)
I should be able to supply "diff -u" results for those changes, if
anyone's interested. There was also a similar but non-fatal complaint
which I did not fix:
../../gcc-4.7-20120114/gcc/java/jvspec.c: In function 'int
lang_specific_pre_link()':
../../gcc-4.7-20120114/gcc/java/jvspec.c:629:53: warning: missing
sentinel in function call [-Wformat]
(Another use of concat(), nothing novel.)
The build log includes many complaints like the following, too, but
they don't stop the build:
ld: 0711-768 WARNING: Object
../libsupc++/.libs/libsupc++convenience.a[eh_terminate.o], section 1,
function .__cxxabiv1::__terminate(void (*)()):
The branch at address 0xbc is not followed by a recognized no-op
or TOC-reload instruction. The unrecognized instruction is 0x0.
ld: 0711-768 WARNING: Object
../libsupc++/.libs/libsupc++convenience.a[si_class_type_info.o], section 1,
function .__cxxabiv1::__si_class_type_info::~__si_class_type_info():
The branch at address 0x290 is not followed by a recognized no-op
or TOC-reload instruction. The unrecognized instruction is 0x7FE3FB78.
ld: 0711-768 WARNING: Object
../libsupc++/.libs/libsupc++convenience.a[class_type_info.o], section 1,
function .__cxxabiv1::__class_type_info::~__class_type_info():
The branch at address 0x2b8 is not followed by a recognized no-op
or TOC-reload instruction. The unrecognized instruction is 0x7FE3FB78.
ld: 0711-768 WARNING: Object
../libsupc++/.libs/libsupc++convenience.a[eh_terminate.o], section 1,
function .std::terminate():
The branch at address 0x10c is not followed by a recognized no-op
or TOC-reload instruction. The unrecognized instruction is 0x0.
[...]
There are also some minor mysteries, like, for example:
[...]
checking whether we are cross compiling... no
[...]
checking for strip... strip
configure: WARNING: In the future, Autoconf will not detect cross-tools
whose name does not start with the host triplet. If you think this
configuration is useful to you, please write to autoc...@gnu.org.
[...]
checking whether we are cross compiling... yes
[...]
checking whether we are cross compiling... no
[...]
checking whether vsnprintf works... probably
configure: WARNING: cannot check for properly working vsnprintf when
cross compiling, will assume it's ok
[...]
I was unaware that I was "cross" anything. No one seems to be too sure.
Bunches of (less critical, I assume) warnings like these, too:
[...]
warning: comparison is always true due to limited range of data type
[-Wtype-limits]
[...]
warning: comparison of unsigned expression >= 0 is always true
[-Wtype-limits]
[...]
warning: dereferencing type-punned pointer will break strict-aliasing
rules [-Wstrict-aliasing]
[...]
warning: comparison between signed and unsigned integer expressions
[-Wsign-compare]
[...]
Also:
[...]
build/genrecog ../../gcc-4.7-20120114/gcc/config/rs6000/rs6000.md \
insn-conditions.md > tmp-recog.c
../../gcc-4.7-20120114/gcc/config/rs6000/rs6000.md:13012: warning:
operand 0 missing mode?
../../gcc-4.7-20120114/gcc/config/rs6000/rs6000.md:13436: warning:
operand 1 missing mode?
../../gcc-4.7-20120114/gcc/config/rs6000/sync.md:104: warning: operand 0
missing mode?
../../gcc-4.7-20120114/gcc/config/rs6000/altivec.md:1613: warning:
operand 1 missing mode?
../../gcc-4.7-20120114/gcc/config/rs6000/altivec.md:1620: warning:
operand 1 missing mode?
../../gcc-4.7-20120114/gcc/config/rs6000/altivec.md:1772: warning:
destination missing a mode?
../../gcc-4.7-20120114/gcc/config/rs6000/altivec.md:1772: warning:
operand 0 missing mode?
../../gcc-4.7-20120114/gcc/config/rs6000/altivec.md:2287: warning:
operand 1 missing mode?
../../gcc-4.7-20120114/gcc/config/rs6000/altivec.md:2295: warning:
operand 1 missing mode?
../../gcc-4.7-20120114/gcc/config/rs6000/altivec.md:2303: warning:
operand 1 missing mode?
../../gcc-4.7-20120114/gcc/config/rs6000/altivec.md:2311: warning:
operand 1 missing mode?
[...]
Should I care?
For the record:
blue# oslevel
6.1.0.0
blue# oslevel -r
6100-07
blue# oslevel -s
6100-07-01-1141
If more information would be helpful, just let me know.
