[Bug bootstrap/35211] Dist tarball is missing (Bison-generated) java/parse-scan.c
--- Comment #2 from skunk at iskunk dot org 2009-01-06 07:09 --- The 4.2.4 tarball is still missing the file. While this shouldn't be an issue in 4.3, the last of 4.2 ought to have a solid tarball. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35211
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- Comment #18 from skunk at iskunk dot org 2009-08-07 21:13 --- Confirmed correct fixincluding of if.h in the GCC 4.4.1 build. Ding, dong, this bug is dead! -- skunk at iskunk dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
[Bug bootstrap/28497] New: /usr/ccs/bin/ld: Unrecognized argument: +init
It appears that GCC is assuming that the system linker can accept the +init
option. In the ld(1) man page, +init appears under the heading "64 Bit (ELF)
Link Editor options", and the system is 32-bit-only---might that have something
to do with it?
(begin build log excerpt)
ranlib libbackend.a
stage1/xgcc -Bstage1/ -B/opt/tg/hppa2.0w-hp-hpux11.00/bin/ -g -O2 -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wold-style-definition
-Wmissing-format-attribute -DHAVE_CONFIG_H -o cc1-dummy c-lang.o
stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o
c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o
c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o
c-dump.o c-pch.o c-parser.o c-gimplify.o tree-mudflap.o c-pretty-print.o
dummy-checksum.o \
main.o libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a
../libiberty/libiberty.a
/usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (c-lang.o) was
detected. The linked output may not run on a PA 1.x system.
/usr/ccs/bin/ld: Unrecognized argument: +init
/usr/ccs/bin/ld: Usage: /usr/ccs/bin/ld flags... files...
collect2: ld returned 1 exit status
gmake[2]: *** [cc1-dummy] Error 1
gmake[2]: Leaving directory `/home/cport/tmp/gcc--4.1.1.build/gcc'
gmake[1]: *** [stage2_build] Error 2
gmake[1]: Leaving directory `/home/cport/tmp/gcc--4.1.1.build/gcc'
gmake: *** [bootstrap-lean] Error 2
(end build log excerpt)
Output of "/usr/ccs/bin/ld -V":
92453-07 linker command s800.sgs ld B.11.13 REL 990903
/usr/ccs/bin/ld: 92453-07 linker linker ld B.11.13 990903
/usr/ccs/bin/ld: Usage: /usr/ccs/bin/ld flags... files...
Output of "uname -a":
HP-UX hrdygrdy B.11.00 A 9000/785 2003934647 two-user license
--
Summary: /usr/ccs/bin/ld: Unrecognized argument: +init
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk dot org
GCC build triplet: hppa2.0w-hp-hpux11.00
GCC host triplet: hppa2.0w-hp-hpux11.00
GCC target triplet: hppa2.0w-hp-hpux11.00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28497
[Bug bootstrap/28497] /usr/ccs/bin/ld: Unrecognized argument: +init
--- Comment #2 from skunk at iskunk dot org 2006-07-26 17:55 --- (In reply to comment #1) > I think GCC needs the GNU binutils linker now. It certainly needs the GNU assembler (explicit configure-time error to that effect), and I built binutils 2.17. That one said that (GNU) ld is "not supported in this configuration"... moreover, the documentation for GCC's HPPA-specific options list a few relevant to the HP linker. > Also how did you configure GCC? .../configure --disable-dependency-tracking --disable-maintainer-mode --disable-shared --disable-nls --enable-version-specific-runtime-libs --with-arch=2.0 --with-gnu-as --with-as=/usr/local/bin/gnu-as --enable-languages=c,c++ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28497
[Bug bootstrap/28499] New: Bogus whitespace in preprocessor directives breaks bootstrap
The file in question here is gcc-4.1.1/gcc/tree-vectorizer.h, though I notice
there are many more instances of this issue in the GCC tree:
find gcc-4.1.1 -name '*.[ch]' -exec pcregrep
'^\s+#\s*(define|undef|if|endif)' {} \; | wc -l
326
(same command, but with "pcregrep -l")
62
I know that the topic of whitespace before the "#" has been discussed here
before, that the applicable standards allow it and compilers that don't are
broken, etc. ... but I do believe the bootstrapping process, by its nature, has
to accomodate quirks such as these.
(begin build log excerpt)
make[2]: Entering directory `/usr/home/cport/tmp/gcc--4.1.1.build/gcc'
cc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC
-DHAVE_CONFIG_H -I. -I. -I/tg/freeport/src/gcc/gcc--4.1.1/gcc
-I/tg/freeport/src/gcc/gcc--4.1.1/gcc/.
-I/tg/freeport/src/gcc/gcc--4.1.1/gcc/../include
-I/tg/freeport/src/gcc/gcc--4.1.1/gcc/../libcpp/include
/tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c -o tree-vectorizer.o
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.h, line 33: #
not in column 1 is ignored, skipping to end of line. (ignoretokens)
#define UNKNOWN_LOC NULL
--^
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.h, line 34: #
not in column 1 is ignored, skipping to end of line. (ignoretokens)
#define EXPR_LOC(e) EXPR_LOCUS(e)
--^
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.h, line 35: #
not in column 1 is ignored, skipping to end of line. (ignoretokens)
#define LOC_FILE(l) (l)->file
--^
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.h, line 36: #
not in column 1 is ignored, skipping to end of line. (ignoretokens)
#define LOC_LINE(l) (l)->line
--^
cc: Error: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 813: In
this statement, "UNKNOWN_LOC" is not declared. (undeclared)
if (loop_loc != UNKNOWN_LOC)
--^
cc: Error: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 1112: In
this statement, "UNKNOWN_LOC" is not declared. (undeclared)
if (loop_loc != UNKNOWN_LOC)
--^
cc: Error: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 1236: In
this statement, "UNKNOWN_LOC" is not declared. (undeclared)
return UNKNOWN_LOC;
---^
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 1242:
In this statement, "EXPR_LOC(...)" of type "int", is being converted to
"pointer to struct location_s". (cvtdiftypes)
return EXPR_LOC (node);
---^
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 1256:
In this statement, "EXPR_LOC(...)" of type "int", is being converted to
"pointer to struct location_s". (cvtdiftypes)
return EXPR_LOC (node);
---^
cc: Error: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 1330: In
this statement, "UNKNOWN_LOC" is not declared. (undeclared)
if (vect_loop_location == UNKNOWN_LOC)
^
make[2]: *** [tree-vectorizer.o] Error 1
make[2]: Leaving directory `/usr/home/cport/tmp/gcc--4.1.1.build/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory `/usr/home/cport/tmp/gcc--4.1.1.build/gcc'
make: *** [bootstrap-lean] Error 2
(end build log excerpt)
--
Summary: Bogus whitespace in preprocessor directives breaks
bootstrap
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk dot org
GCC build triplet: alphaev56-dec-osf4.0g
GCC host triplet: alphaev56-dec-osf4.0g
GCC target triplet: alphaev56-dec-osf4.0g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #2 from skunk at iskunk dot org 2006-07-26 18:36 --- I was under the impression that the bootstrapping process would first build an intermediate compiler, itself written in a "safe" subset of C, that would then build the full GCC, which could use modern features as needed. Was it decided to no longer support bootstrapping on systems with "dumb" C compilers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #3 from skunk at iskunk dot org 2006-07-26 19:00 --- I'm sorry; I meant to write "Why was it decided to...?" What strikes me as odd about this, moreover, is that the incompatibility appears gratuitous; the extra whitespace doesn't help anything. Is this a case of wanting to (eventually) use modern C features in the intermediate compiler? More importantly, what is the support status for systems like the one in question? Is it to build 3.4.x first, and then use that to build 4.x? Or is 4.x not intended to support it at all, hacks notwithstanding? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #5 from skunk at iskunk dot org 2006-07-26 19:53 --- (In reply to comment #4) > Modern C as in 15 years is a joke. 15 years is enough for vendors to provide > a > new C compiler. Sometimes, you can't get a newer version (e.g. licensing issues). Sometimes, you don't want to (e.g. backward compatibility problems). I can't imagine why plain ANSI C89 wasn't good enough for the intermediate compiler. Whatever newer features were desired, they can't have been worth breaking the bootstrap process for older systems. (I'd have been more inclined to agree if the change was to drop K&R compatibility, though even then there would have been a good argument against. And there's always ansi2knr and other workarounds.) > Build 3.4.x first. A six-stage bootstrap, then... I'll do that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #7 from skunk at iskunk dot org 2006-07-26 20:57 --- (In reply to comment #6) > This _is_ plain ANSI C89. ISO C90 was specified. Yes, my bad, ANSI does allow whitespace before the "#"---but what of it? It's good practice anyhow to place the mark first, and the Tru64 compiler isn't exactly alone in enforcing this convention. (Is there _any_ good reason for having the whitespace? I don't mean a defense of "but the standard allows it, your compiler sucks"---I mean, a hard, technical reason for doing it that way instead of placing the "#" first?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug bootstrap/28515] New: CFLAGS not propagated, resulting in object mismatch
Configured gcc with CFLAGS=-xarch=v9 (among other flags) to produce 64-bit code
from the system compiler, instead of the default of 32-bit.
(begin build log excerpt)
cc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
-I/tg/freeport/src/gcc/gcc--4.1.1/gcc
-I/tg/freeport/src/gcc/gcc--4.1.1/gcc/build
-I/tg/freeport/src/gcc/gcc--4.1.1/gcc/../include
-I/tg/freeport/src/gcc/gcc--4.1.1/gcc/../libcpp/include -D__EXTENSIONS__
-D_REENTRANT -Dsparc-o build/errors.o
/tg/freeport/src/gcc/gcc--4.1.1/gcc/errors.c
cc -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -DHAVE_CONFIG_H
-DGENERATOR_FILE -o build/genmodes \
build/genmodes.o build/errors.o
../build-sparc-sun-solaris2.8/libiberty/libiberty.a
ild: (bad file) Input file ../build-sparc-sun-solaris2.8/libiberty/libiberty.a
contains 64-bit relocatable, but producing a 32-bit file.
gmake[2]: *** [build/genmodes] Error 1
gmake[2]: Leaving directory `/export/home/cport/tmp/gcc--4.1.1.build/gcc'
gmake[1]: *** [stage1_build] Error 2
gmake[1]: Leaving directory `/export/home/cport/tmp/gcc--4.1.1.build/gcc'
gmake: *** [bootstrap-lean] Error 2
(end build log excerpt)
build/errors.o and build/genmodes are compiled and linked without the original
CFLAGS, while libiberty.a was. From the looks of it, gcc/Makefile doesn't pick
up CFLAGS at all.
--
Summary: CFLAGS not propagated, resulting in object mismatch
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk dot org
GCC build triplet: sparc-sun-solaris2.8
GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #2 from skunk at iskunk dot org 2006-07-27 19:09 --- (In reply to comment #1) > You need to also set STAGE1_CFLAGS. Wait... how does that work? gcc/Makefile.in has these lines: # STAGE1_CFLAGS is set by configure on some targets or passed from toplevel # and sets the CFLAGS passed to stage1 of a bootstrap compilation. [...] CFLAGS = -g STAGE1_CFLAGS = -g @stage1_cflags@ @stage1_cflags@ is set in the configure script (both the top-level one and the one in gcc/), but the value incorporates no user-set variable; it's predicated on just the build triplet. So there's no way to set STAGE1_CFLAGS without manually overriding it in the makefile. That aside, why does this variable have to be set separately? If you set CC and CFLAGS, the assumption is that the two will always be used together. (What gets passed to xgcc and later stages is a different matter, of course.) In theory you could have a system compiler that behaves in a completely broken manner without some special flag. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug bootstrap/28497] /usr/ccs/bin/ld: Unrecognized argument: +init
--- Comment #4 from skunk at iskunk dot org 2006-07-28 02:04 --- (In reply to comment #3) > Your HP system linker is too old. Please update to PHSS_33034 or > later. Thanks for the note; I'll do that. It would be good to have a configure-time check for this. This did seem to be a system portability bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28497
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #4 from skunk at iskunk dot org 2006-07-28 02:20 ---
(In reply to comment #3)
>
> make STAGE1_CFLAGS=whatever
Yes. Editing the makefile works pretty well too :-)
But the point is, it's a bug for cc(1) to have been invoked without the
original CFLAGS. I admit that I don't fully understand how the
host/system/build/stageN settings are partitioned, but it seems like a pretty
clear problem for a straight-up CC+CFLAGS environment to give the build error I
quoted. Methinks something like
STAGE1_CFLAGS=${STAGE1_CFLAGS-${CFLAGS}}
should be happening at configure time, that STAGE1_CFLAGS can be set if you
want GCC's stage 1 to be built with different flags than libiberty, but
otherwise that you can just set CC+CFLAGS as usual and have it all work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #5 from skunk at iskunk dot org 2006-08-02 16:18 --- Created an attachment (id=11998) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11998&action=view) test-cc.pl: Fussy compiler simulator script This is a Perl script I put together to investigate the CFLAGS behavior, instead of repeated bootstraps on my 64-bit Slowaris box. You set the following environment variables... CC=/path/to/test-cc.pl REAL_CC=gcc CFLAGS="(your usual compiler flags) --foobaz" ...and the script will bork if it does not see exactly one instance of --foobaz. Otherwise, it'll remove that option, and invoke $REAL_CC with what remains. The system/stage[23] compiler will, of course, similarly choke if it sees --foobaz. So here, you have a way of verifying that $CC and $CFLAGS are always and only used together. Currently, this is not the case; I'm seeing GCC's stage1 build passing nothing more than "-g" to the compiler, despite CFLAGS. (Even setting STAGE1_CFLAGS in the environment before configure time has no effect.) There is also a point in the stage2 build where $CFLAGS is passed to xgcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #6 from skunk at iskunk dot org 2006-08-02 16:30 ---
Interestingly enough, the test-cc script teased out an apparent bug in
config/depstand.m4 (routines to check the compiler's mode of dependency
generation). When the compiler is invoked, at the $SHELL line in the below
excerpt...
(begin config/depstand.m4 excerpt)
depcmd="depmode=$depmode \
source=sub/conftest.c object=sub/conftest.${OBJEXT-o} \
depfile=sub/conftest.Po tmpdepfile=sub/conftest.TPo \
$SHELL ./depcomp $depcc -c -o sub/conftest.${OBJEXT-o} sub/conftest.c"
echo "| $depcmd" | sed -e 's/ */ /g' >&AS_MESSAGE_LOG_FD
if env $depcmd > conftest.err 2>&1 &&
(end config/depstand.m4 excerpt)
...no compiler flags are passed to it.
You'll have to work around this in order to make use of the wrapper script, but
would this be worth a new bug report? You could imagine a case where the
compiler does something stupid here (strict K&R mode?) if it doesn't get a
certain flag.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #8 from skunk at iskunk dot org 2006-08-06 07:26 --- (In reply to comment #7) > You cannot expect that to work. You're trying to bootstrap a 32-bit compiler > (sparc-sun-solaris2.8) with a 64-bit compiler (cc -xarch=v9). Unsupported. No, I'm trying to build a 64-bit GCC using cc in 64-bit mode (as per CFLAGS) on a 64-bit system. Nothing fancy here. You don't pass compiler flags in CC. That's what CFLAGS is for. Let me refocus the issue: It is a bug for genmodes et al. in GCC's stage 1 to have been built without CFLAGS. Is there any reason for this not to be the case? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #11 from skunk at iskunk dot org 2006-08-06 08:09 ---
(In reply to comment #9)
> You do for GCC. Tweaking CFLAGS for a bootstrap is a recipe for disaster.
How is it any worse than having those flags in CC? CC and CFLAGS are always
supposed to be used together anyway---the only difference with what you're
describing is that this follows the standard variable convention. (And surely
you're not implying that CFLAGS is supposed to be passed to xgcc or some other
stage, instead of BOOT_CFLAGS or similar?)
To say nothing of the issue of consistency: If CFLAGS is so bad, why is
libiberty built using it?
I understand that things are necessarily complicated in GCC's build system,
that you can have up to three (four?) different compilers and associated
options, etc. etc. No problem with that. What I don't understand is why, in the
simplest ("degenerate") case of bootstrapping a compiler on the target system,
I can't just blithely set CC+CFLAGS and have it work in the expected way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #12 from skunk at iskunk dot org 2006-08-06 08:32 --- (In reply to comment #10) > Passing -xarch=v9 to the compiler makes it a different compiler in essence, > one > that creates object files that are incompatible with the output of the default > compiler. It also changes the operation of the linker. That makes the flag > quite different from other compiler flags. That's a fairly slippery slope. Does -KPIC/-fPIC/etc. make cc a different compiler? -g/-O? -g/-pg? (Yes, the linker might be able to handle those combinations, but you may end up with a Frankenbinary that fails unpredictably at run-time.) Where do you draw the line? That's beside the point, even. "$CC $CFLAGS" may produce something incompatible with "$CC" alone---and yes, it is as if the two are completely different compilers---but ***why*** are you using CC alone, without CFLAGS, in the first place? Can someone please explain this to me? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #15 from skunk at iskunk dot org 2006-08-06 09:44 --- (In reply to comment #13) > It's worse because tweaking CFLAGS makes you think you can do whatever you > want with it. You cannot, as explained by Andreas. Per Andreas, the "cannot" part stems directly from using CC alone (a.k.a. "the default compiler"), which is the bug at issue. If tweaking CFLAGS makes me think bad thoughts, then the caveats should be noted in the build docs, instead of the variable behavior being purposely broken. (**None** of what you're saying is currently in the docs, so far as I can see.) If users ignoring docs is a problem, then do as the MPlayer folks do and have the configure script print a big fat warning if it detects anything unwholesome. > You're precisely *not* bootstrapping a compiler on the target system, you're > building a 32-bit compiler (sparc-sun-solaris2.8) by starting with a 64-bit > one. This is a cross-compilation. You cannot use a bootstrap in that case. > > I guess it's not what you intended, that's why tweaking CFLAGS is dangerous. So you're saying that CC and the target triplet have to agree, ABI-wise? Because that would be an issue, in my case---but it's still orthogonal to the problem of using CC sans CFLAGS. (Here, the resolution would be that I have to specify the sparc64 triplet explictly, presumably because config.guess returns the 32-bit triplet irrespective of the system being 64-bit.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #18 from skunk at iskunk dot org 2006-08-07 04:32 --- (In reply to comment #16) > > (**None** of what you're saying is currently in the docs, so far as I can > > see.) > > Take a look at http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2 Okay, so the sparc64 and CC="cc -xarch=v9" bits are there. What about the non-system-specific caveats w.r.t. CFLAGS and ABI compatibility? > > If users ignoring docs is a problem, then do as the MPlayer folks do and > > have the configure script print a big fat warning if it detects anything > > unwholesome. > > This would be a lot of work for GCC! "Detects anything unwholesome" can be as simple as checking whether CFLAGS is set at all (which is all MPlayer's build does). Over time, it could be expanded into a case statement keying off a triplet, so you could have e.g. a present/absent check for -xarch=v9 in CFLAGS for sparc*-sun-solaris*. > > So you're saying that CC and the target triplet have to agree, ABI-wise? > > If you want to do a bootstrap, yes. Otherwise this is a cross-compilation and > a bootstrap will miserably fail like in your case. The reason why it failed in my case is because it linked code built with "$CC" (genmodes) against code built with "$CC $CFLAGS" (libiberty). It was a flat-out violation of flag-variable convention to build stage 1 genmodes without CFLAGS. Now, if the failure was in linking code built with xgcc against the original [cc-built] libiberty, then that's a more meaningful issue---because CFLAGS doesn't apply there. It is the target (right?) triplet that controls what kind of code xgcc generates, and this must be compatible with the output of "$CC $CFLAGS". (I obtained this result by attempting to build with CC="cc -xarch=v9", but without the sparc64 triplet.) > CC+CFLAGS and the --host parameter of configure must always be in keeping. > For a native compilation (hence a bootstrap), --target must additionally be. > So the safe procedure is to modify CC and not CFLAGS. Wait a second---you said that CFLAGS was being ignored because you didn't trust the user to tweak it appropriately. So the "safe procedure" is what it is because of that, not because of any technical requirement of the bootstrap process. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #20 from skunk at iskunk dot org 2006-08-07 05:51 ---
(In reply to comment #19)
> Everything is always doable if resources permit. Tweaking CFLAGS is simply
> not generically supported and I don't think we have plan to that effect.
Okay. No generic flag-tweaking support is perfectly fine. Can we either...
(1) Straighten things out so that if you do have to pass a flag(s) to the
compiler, it is passed in through CFLAGS---thus respecting standard
flag-variable convention, or
(2) Ignore CFLAGS altogether, so that libiberty isn't built with it, and CC
becomes the only place where flags can be put in? (The thinking being, if the
behavior's going to be broken, at least make it _consistently_ broken)
> Simply use the documented procedure.
This isn't just about sparc64, you know. The whole reason why this came up in
the first place is because I'm building GCC in a custom autobuild framework,
across a number of architectures. For every other autotoolized package, I set
CC, CXX, {CC,CXX,CPP}FLAGS, and everything works. It's really annoying to have
GCC, a pretty important package, so thoroughly flout the convention that all
the other GNU toolsets adhere to.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #23 from skunk at iskunk dot org 2006-08-07 06:43 --- (In reply to comment #21) > I'd only add that the upcoming GCC 4.2 release will feature a new bootstrap > procedure (aka toplevel bootstrap) that could solve the issue. Very interesting. I'll have a look at it. If this refactors the rat's nest of Make variable overrides in the top-level makefile, then it could be a very good thing indeed. > On the one hand, and without any inflated ego :-), you cannot consider that > bootstrapping a compiler is like building any other piece of software. Very true, but in the simplest, degenerate case (bootstrapping with host == build == target), you could reasonably expect stage 1 (and anything before it) to be built with CC+CFLAGS. Principle of least surprise, and all that. (This is saying nothing about matching the triplets to CFLAGS, which does remain an issue. Yes, you can't be *completely* naive in building GCC.) > On > the other hand, the aforementioned toplevel bootstrap is aimed at eliminating > the peculiarities you noticed; for example, a bare "make" will automatically > perform a complete 3-stage bootstrap for a native compiler in the sense that > the end result should not depend on the bootstrap compiler anymore at all. I think you meant to say, "not depend on the native compiler" :-) But this is good---doing a bootstrap unconditionally is reasonable nowadays, and it should simplify the build system a bit (one less case to handle). (In reply to comment #22) > I'd also challenge this assertion: I don't think you can generically tweak > CFLAGS, in particular change the ABI, once a package has been configured. Right, but... of course, whenever I say that I set such-and-such flags, I mean before configure time. After that point, it usually doesn't matter what you have set in the environment, because the standard variables are explicitly assigned in the makefiles. (You didn't think I was asking for the build system to track variables in the environment _after_ configure time... did you?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #25 from skunk at iskunk dot org 2006-08-07 07:42 --- (In reply to comment #24) > Of course you can override them on the line of the "make" command. Right, but that's getting into mucking-with-the-build territory. (Hence my tongue-in-cheek reply to Andreas in comment #4... it's the moral equivalent of editing the makefiles. You wear the developer's hat once you do that.) All I'm concerned with is building via top-level make(1) invocations---single target, no overrides---like a good little end user. > I thought you were setting CFLAGS on the "make" line. But then your build > wouldn't have failed this early, you would probably have waited until stage2. It was Andreas who suggested doing that. I balked Recap: The build fails in stage 1 because libiberty was built with CFLAGS in the usual way, but stage 1 genmodes was built without, and it wants to link against libiberty, and the linker chokes on the ABI incompatibility. This inconsistency is the real bug, and it has two solutions (listed in comemnt #20), and I'd advocate resolving it in the way that brings about convention-compliant behavior (build genmodes and the rest of stage 1 with CFLAGS). Any caveats w.r.t. CFLAGS should be noted in the docs, and possibly checked in the configure script, rather than avoided by way of a gratuitously broken variable convention unique to GCC. Does all that sound good? Can we at least agree that the aforementioned inconsistency is a bug, even if the build system is too hopelessly complex to fix it, and 4.2 might not even have this issue anymore? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- Comment #15 from skunk at iskunk dot org 2007-02-01 17:18 --- This bug is still present in 3.4.6 Bruce or Giovanni, could one of you please apply this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
[Bug java/16858] Linking of jv-convert fails with redundant pthreads symbols
--- Comment #2 from skunk at iskunk dot org 2007-02-02 19:00 --- ... /tmp/gcc-3.4.6-build/gcc/gcj -B/tmp/gcc-3.4.6-build/alphaev56-dec-osf4.0g/libjava/ -B/tmp/gcc-3.4.6-build/gcc/ -mieee -g -O2 -o jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc -L/tmp/gcc-3.4.6-build/alphaev56-dec-osf4.0g/libjava -L/tmp/gcc-3.4.6-build/alphaev56-dec-osf4.0g/libjava/.libs ./.libs/libgcj.a -L/tmp/gcc-3.4.6-build/alphaev56-dec-osf4.0g/libstdc++-v3/src -L/tmp/gcc-3.4.6-build/alphaev56-dec-osf4.0g/libstdc++-v3/src/.libs -lpthread -lrt -L/tmp/gcc-3.4.6-build/gcc -L/usr/lib/cmplrs/cc -lgcc -lc -lgcc -Wl,-rpath -Wl,/usr/local/lib /usr/bin/ld: /tmp/gcc-3.4.6-build/gcc/libgcc.a(gthr-posix.o): pthread_key_create: multiply defined /tmp/gcc-3.4.6-build/gcc/libgcc.a(gthr-posix.o): __pthread_getspecific: multiply defined /tmp/gcc-3.4.6-build/gcc/libgcc.a(gthr-posix.o): __pthread_setspecific: multiply defined /tmp/gcc-3.4.6-build/gcc/libgcc.a(gthr-posix.o): __pthread_mutex_lock: multiply defined /tmp/gcc-3.4.6-build/gcc/libgcc.a(gthr-posix.o): __pthread_mutex_unlock: multiply defined /tmp/gcc-3.4.6-build/gcc/libgcc.a(gthr-posix.o): __pthread_create: multiply defined /tmp/gcc-3.4.6-build/gcc/libgcc.a(gthr-posix.o): __pthread_cond_destroy: multiply defined /tmp/gcc-3.4.6-build/gcc/libgcc.a(gthr-posix.o): __pthread_cond_init: multiply defined /tmp/gcc-3.4.6-build/gcc/libgcc.a(gthr-posix.o): __pthread_cond_signal: multiply defined /tmp/gcc-3.4.6-build/gcc/libgcc.a(gthr-posix.o): __pthread_cond_wait: multiply defined /tmp/gcc-3.4.6-build/gcc/libgcc.a(gthr-posix.o): __pthread_mutex_init: multiply defined /tmp/gcc-3.4.6-build/gcc/libgcc.a(gthr-posix.o): __pthread_mutex_destroy: multiply defined /tmp/gcc-3.4.6-build/gcc/libgcc.a(gthr-posix.o): __pthread_self: multiply defined /tmp/gcc-3.4.6-build/gcc/libgcc.a(gthr-posix.o): pthread_attr_destroy: multiply defined /tmp/gcc-3.4.6-build/gcc/libgcc.a(gthr-posix.o): pthread_attr_init: multiply defined /tmp/gcc-3.4.6-build/gcc/libgcc.a(gthr-posix.o): pthread_attr_setdetachstate: multiply defined /tmp/gcc-3.4.6-build/gcc/libgcc.a(gthr-posix.o): pthread_setschedparam: multiply defined collect2: ld returned 1 exit status gmake[3]: *** [jv-convert] Error 1 gmake[3]: Leaving directory `/tmp/gcc-3.4.6-build/alphaev56-dec-osf4.0g/libjava' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/tmp/gcc-3.4.6-build/alphaev56-dec-osf4.0g/libjava' gmake[1]: *** [all-target-libjava] Error 2 gmake[1]: Leaving directory `/tmp/gcc-3.4.6-build' gmake: *** [bootstrap] Error 2 Yes :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16858
[Bug middle-end/19430] Missing uninitialized warning
--- Comment #12 from skunk at iskunk dot org 2007-03-02 23:36 ---
Here's my minimal test case. Compile with "-O3 -Wall -c":
#include
void frob(int *pi);
int main(void)
{
int i;
printf("i = %d\n", i);
frob(&i);
return 0;
}
No warning from 4.0.3 nor 4.1.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
[Bug libgomp/33131] New: [4.2 regression] libgomp/env.c:60: warning: implicit declaration of function 'strncasecmp'
Build was successful after stripping out all the -Werror flags from the makefiles. /tmp/gcc--4.2.1.build/./gcc/xgcc -B/tmp/gcc--4.2.1.build/./gcc/ -B/opt/tg/powerpc-ibm-aix4.3.3.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.3.0/lib/ -isystem /opt/tg/powerpc-ibm-aix4.3.3.0/include -isystem /opt/tg/powerpc-ibm-aix4.3.3.0/sys-include -DHAVE_CONFIG_H -I. -I/tg/freeport/src/gcc/gcc--4.2.1/libgomp -I. -I/tg/freeport/src/gcc/gcc--4.2.1/libgomp/config/posix -I/tg/freeport/src/gcc/gcc--4.2.1/libgomp -Wall -pthread -Werror -O2 -g -O2 -c /tg/freeport/src/gcc/gcc--4.2.1/libgomp/env.c -DPIC -o env.o cc1: warnings being treated as errors /tg/freeport/src/gcc/gcc--4.2.1/libgomp/env.c: In function 'parse_schedule': /tg/freeport/src/gcc/gcc--4.2.1/libgomp/env.c:60: warning: implicit declaration of function 'strncasecmp' gmake[4]: *** [env.lo] Error 1 gmake[4]: Leaving directory `/tmp/gcc--4.2.1.build/powerpc-ibm-aix4.3.3.0/libgomp' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/tmp/gcc--4.2.1.build/powerpc-ibm-aix4.3.3.0/libgomp' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/tmp/gcc--4.2.1.build/powerpc-ibm-aix4.3.3.0/libgomp' gmake[1]: *** [all-target-libgomp] Error 2 gmake[1]: Leaving directory `/tmp/gcc--4.2.1.build' gmake: *** [bootstrap-lean] Error 2 -- Summary: [4.2 regression] libgomp/env.c:60: warning: implicit declaration of function 'strncasecmp' Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: skunk at iskunk dot org GCC build triplet: powerpc-ibm-aix4.3.3.0 GCC host triplet: powerpc-ibm-aix4.3.3.0 GCC target triplet: powerpc-ibm-aix4.3.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33131
[Bug other/33549] New: makeinfo drops hyphens from srcdir path
The source tree in the below build is under /tmp/gcc-4.2.1--x---xx/. Note
how the path contains 1, then 2, then 3, then 4 hyphens.
BEGIN BUILD LOG EXCERPT
if [ xinfo = xinfo ]; then \
makeinfo --split-size=500 --split-size=500 --split-size=500
--no-split -I . -I ../../gcc-4.2.1--x---xx/gcc/doc \
-I ../../gcc-4.2.1--x---xx/gcc/doc/include -o doc/gcc.info
../../gcc-4.2.1--x---xx/gcc/doc/gcc.texi; \
fi
../../gcc-4.2.1--x---xx/gcc/doc//invoke.texi:1080: @include
`../../gcc-4.2.1-x--x---x/gcc/../libiberty/at-file.texi': No such file or
directory.
makeinfo: Removing output file `doc/gcc.info' due to errors; use --force to
preserve.
make[3]: *** [doc/gcc.info] Error 1
make[3]: Leaving directory `/home/cport/tmp/gcc-build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/cport/tmp/gcc-build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/cport/tmp/gcc-build'
make: *** [bootstrap-lean] Error 2
END BUILD LOG EXCERPT
Makeinfo is looking for at-file.texi under an incorrect source path: each run
of two or more hyphens in the path is shortened by one. I believe this is due
to Texinfo's typographic syntax conventions being incorrectly applied to the
@value{srcdir} substitution in invoke.texi.
--
Summary: makeinfo drops hyphens from srcdir path
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33549
[Bug other/33549] makeinfo drops hyphens from srcdir path
--- Comment #3 from skunk at iskunk dot org 2008-02-12 20:46 --- (In reply to comment #2) > > I think it's a bug in makeinfo that it does this, and should be fixed > there. That was my first thought as well, but consider that the conversion from "--" to "-" (and "---" to "--") makes sense from a typographic standpoint. A "--" is used to indicate an en-dash, which in Info is rendered as a plain hyphen, whereas a "---" is an em-dash, rendered as "--". Changing the Makeinfo behavior would affect the appearance of the final text. Consider other cases, too: what if the srcdir path contains a "@"? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33549
[Bug other/33549] makeinfo drops hyphens from srcdir path
--- Comment #1 from skunk at iskunk dot org 2008-02-12 19:57 ---
Created an attachment (id=15133)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15133&action=view)
Patch against 4.2.3
Proposed fix. Set the srcdir variable using @verb{}, to prevent interpretation
of special character sequences (i.e. "--") in the path.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33549
[Bug libstdc++/35197] New: Native linker can't locate file for -lstdc++ with --enable-version-specific-runtime-libs
I have a build of GCC 4.2.3 compiled with
--enable-version-specific-runtime-libs. It fails to link a trivial C++ program,
because the (non-GNU) linker does not know about libstdc++, and the GCC
frontend is not passing an appropriate -L... flag to the linker so that it can
find the library.
$ g++ -o hello hello.cxx
/usr/bin/ld:
Can't locate file for: -lstdc++
collect2: ld returned 1 exit status
$ g++ -v -o hello hello.cxx
[superfluous verbiage elided]
mips-tfile (GCC) 4.2.3
/opt/tg/bin/../libexec/gcc/alphaev56-dec-osf4.0g/4.2.3/collect2 -G 8 -O1 -S
-call_shared -o hello /usr/lib/cmplrs/cc/crt0.o
-L/opt/tg/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.2.3 -L/opt/tg/bin/../lib/gcc
-L/opt/tg/lib/gcc/alphaev56-dec-osf4.0g/4.2.3 -L/usr/lib/cmplrs/cc
-L/opt/tg/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.2.3/../../..
-L/opt/tg/lib/gcc/alphaev56-dec-osf4.0g/4.2.3/../../.. /tmp//ccu9eHi9.o
-lstdc++ -lm -lgcc -lc -lgcc
/usr/bin/ld:
Can't locate file for: -lstdc++
collect2: ld returned 1 exit status
(I notice that libstdc++ is present immediately under
/opt/tg/lib/gcc/alphaev56-dec-osf4.0g/, which the -L... flags narrowly miss.)
--
Summary: Native linker can't locate file for -lstdc++ with --
enable-version-specific-runtime-libs
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk dot org
GCC build triplet: alphaev56-dec-osf4.0g
GCC host triplet: alphaev56-dec-osf4.0g
GCC target triplet: alphaev56-dec-osf4.0g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35197
[Bug other/35199] New: [PATCH] Check for valid value of BASEVER
I was recently bootstrapping GCC4 on Tru64. One thing that tripped me up a
couple times was an ICE resulting from an invalid version_string (""). I traced
this back to the following fragment in gcc/Makefile, where BASEVER_c is
assigned:
BASEVER := $(srcdir)/BASE-VER # 4.x.y
[...]
BASEVER_c := $(shell cat $(BASEVER))
For some reason, the value of BASEVER_c was empty. I had the source tree on
NFS, and figured that some transient error caused $(BASEVER) to either
disappear momentarily, or briefly appear as an empty file. (It's difficult to
say, because the rest of the build proceeded with no errors of this sort
whatsoever.)
Whatever the cause, the makefile as currently written does not check for an
empty value of BASEVER_c, and the ICE that later results from this is
magnitudes of order more difficult to diagnose for most users. I would like to
submit a patch to the makefile, then, that immediately throws an error if
BASEVER_c is empty.
--
Summary: [PATCH] Check for valid value of BASEVER
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35199
[Bug other/35199] [PATCH] Check for valid value of BASEVER
--- Comment #1 from skunk at iskunk dot org 2008-02-14 19:01 --- Created an attachment (id=15151) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15151&action=view) Patch against gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35199
[Bug libstdc++/35197] Native linker can't locate file for -lstdc++ with --enable-version-specific-runtime-libs
--- Comment #2 from skunk at iskunk dot org 2008-02-15 07:53 --- Not-so-superfluous verbiage restored: $ g++ -v -o hello hello.cxx Using built-in specs. Target: alphaev56-dec-osf4.0g Configured with: /tg/freeport/src/gcc/gcc--4.2.3/configure --prefix=/opt/tg --disable-dependency-tracking --disable-maintainer-mode --disable-shared --disable-nls --enable-languages=c,c++ --enable-version-specific-runtime-libs --with-pic Thread model: posix gcc version 4.2.3 /opt/tg/bin/../libexec/gcc/alphaev56-dec-osf4.0g/4.2.3/cc1plus -quiet -v -iprefix /opt/tg/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.2.3/ hello.cxx -quiet -dumpbase hello.cxx -mcpu=ev56 -auxbase hello -version -o /tmp//ccd6P9Gc.s ignoring nonexistent directory "/opt/tg/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.2.3/../../../../alphaev56-dec-osf4.0g/include" ignoring duplicate directory "/opt/tg/lib/gcc/alphaev56-dec-osf4.0g/4.2.3/include/c++" ignoring duplicate directory "/opt/tg/lib/gcc/alphaev56-dec-osf4.0g/4.2.3/include/c++/alphaev56-dec-osf4.0g" ignoring duplicate directory "/opt/tg/lib/gcc/alphaev56-dec-osf4.0g/4.2.3/include/c++/backward" ignoring nonexistent directory "/opt/tg/lib/gcc/alphaev56-dec-osf4.0g/4.2.3/../../../../alphaev56-dec-osf4.0g/include" #include "..." search starts here: #include <...> search starts here: /opt/tg/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.2.3/include/c++ /opt/tg/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.2.3/include/c++/alphaev56-dec-osf4.0g /opt/tg/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.2.3/include/c++/backward /opt/tg/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.2.3/include /usr/local/include /opt/tg/include /opt/tg/lib/gcc/alphaev56-dec-osf4.0g/4.2.3/include /usr/include End of search list. GNU C++ version 4.2.3 (alphaev56-dec-osf4.0g) compiled by GNU C version 4.2.3. GGC heuristics: --param ggc-min-expand=65 --param ggc-min-heapsize=65536 Compiler executable checksum: 19341a267fc991710d8c03ed2d8f4731 as -g -nocpp -O0 -o /tmp//cc9AP5DF.o /tmp//ccd6P9Gc.s /opt/tg/bin/../libexec/gcc/alphaev56-dec-osf4.0g/4.2.3/mips-tfile -v -o /tmp//cc9AP5DF.o /tmp//ccd6P9Gc.s mips-tfile (GCC) 4.2.3 /opt/tg/bin/../libexec/gcc/alphaev56-dec-osf4.0g/4.2.3/collect2 -G 8 -O1 -S -call_shared -o hello /usr/lib/cmplrs/cc/crt0.o -L/opt/tg/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.2.3 -L/opt/tg/bin/../lib/gcc -L/opt/tg/lib/gcc/alphaev56-dec-osf4.0g/4.2.3 -L/usr/lib/cmplrs/cc -L/opt/tg/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.2.3/../../.. -L/opt/tg/lib/gcc/alphaev56-dec-osf4.0g/4.2.3/../../.. /tmp//cc9AP5DF.o -lstdc++ -lm -lgcc -lc -lgcc /usr/bin/ld: Can't locate file for: -lstdc++ collect2: ld returned 1 exit status -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35197
[Bug bootstrap/35211] New: Dist tarball is missing (Bison-generated) java/parse-scan.c
Build failed with:
begin
/tg/freeport/src/gcc/gcc--4.2.3/missing bison -t -o java/parse-scan.c
/tg/freeport/src/gcc/gcc--4.2.3/gcc/java/parse-scan.y
WARNING: `bison' missing on your system. You should only need it if
you modified a `.y' file. You may need the `Bison' package
in order for those modifications to take effect. You can get
`Bison' from any GNU archive site.
/mnt/scratch/build/gcc--4.2.3.build/./prev-gcc/xgcc
-B/mnt/scratch/build/gcc--4.2.3.build/./prev-gcc/
-B/opt/tg/alphaev56-dec-osf4.0g/bin/ -c -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wmissing-format-attribute -Wno-error -DHAVE_CONFIG_H
-I. -Ijava -I/tg/freeport/src/gcc/gcc--4.2.3/gcc
-I/tg/freeport/src/gcc/gcc--4.2.3/gcc/java
-I/tg/freeport/src/gcc/gcc--4.2.3/gcc/../include
-I/tg/freeport/src/gcc/gcc--4.2.3/gcc/../libcpp/include
-I/tg/freeport/src/gcc/gcc--4.2.3/gcc/../libdecnumber -I../libdecnumber
java/parse-scan.c -o java/parse-scan.o
xgcc: java/parse-scan.c: No such file or directory
xgcc: no input files
gmake[3]: *** [java/parse-scan.o] Error 1
gmake[3]: Leaving directory `/mnt/scratch/build/gcc--4.2.3.build/gcc'
gmake[2]: *** [all-stage2-gcc] Error 2
gmake[2]: Leaving directory `/mnt/scratch/build/gcc--4.2.3.build'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/mnt/scratch/build/gcc--4.2.3.build'
gmake: *** [bootstrap-lean] Error 2
end
$ tar tvjf gcc-4.2.3.tar.bz2 | grep parse-scan
-rw-rw-r-- joseph/joseph 31171 2007-08-31 04:27:50
gcc-4.2.3/gcc/java/parse-scan.y
$ omgwtf
--
Summary: Dist tarball is missing (Bison-generated) java/parse-
scan.c
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk dot org
GCC build triplet: alphaev56-dec-osf4.0g
GCC host triplet: alphaev56-dec-osf4.0g
GCC target triplet: alphaev56-dec-osf4.0g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35211
[Bug bootstrap/35199] [PATCH] Check for valid value of BASEVER
--- Comment #3 from skunk at iskunk dot org 2008-02-15 18:41 --- Created an attachment (id=15157) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15157&action=view) Updated patch against gcc/Makefile.in Mail sent to [EMAIL PROTECTED] Today I'm building GCC again, and lo and behold, the BASEVER_c check tripped: begin rm -f libdecnumber.a ar cru libdecnumber.a decNumber.o decContext.o decUtility.o decimal32.o decimal64.o decimal128.o ranlib libdecnumber.a gmake[3]: Leaving directory `/mnt/scratch/build/35197/gcc--4.2.3.build/libdecnumber' gmake[3]: Entering directory `/mnt/scratch/build/35197/gcc--4.2.3.build/gcc' Makefile:739: *** /tg/freeport/src/gcc/gcc--4.2.3/gcc/BASE-VER : missing version file. Stop. gmake[3]: Leaving directory `/mnt/scratch/build/35197/gcc--4.2.3.build/gcc' gmake[2]: *** [all-stage1-gcc] Error 2 gmake[2]: Leaving directory `/mnt/scratch/build/35197/gcc--4.2.3.build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/mnt/scratch/build/35197/gcc--4.2.3.build' gmake: *** [bootstrap-lean] Error 2 end Sure beats an ICE! Anyway, I don't see any error from cat(1), so it looks like BASE-VER is being read as an empty file. (If I cat the file manually, it comes up non-empty; the problem is very transient.) Patch tweaked slightly to remove spurious whitespace from the error message. -- skunk at iskunk dot org changed: What|Removed |Added Attachment #15151|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35199
[Bug libstdc++/35197] Native linker can't locate file for -lstdc++ with --enable-version-specific-runtime-libs
--- Comment #4 from skunk at iskunk dot org 2008-02-16 18:42 ---
Argh... now I see what's going on here.
$ grep glibcxx_toolexeclibdir.= alphaev56-dec-osf4.0g/libstdc++-v3/src/Makefile
glibcxx_toolexeclibdir = ${toolexecdir}/${gcc_version}$(MULTISUBDIR)
$ grep gcc_version.:= alphaev56-dec-osf4.0g/libstdc++-v3/src/Makefile
gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER)
This is another manifestation of bug #35199. I'll update my patch to cover this
instance of $(shell cat /path/to/BASE-VER), and any others in the tree.
Sorry for the trouble, gentlemen.
*** This bug has been marked as a duplicate of 35199 ***
--
skunk at iskunk dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35197
[Bug bootstrap/35199] [PATCH] Check for valid value of BASEVER
--- Comment #4 from skunk at iskunk dot org 2008-02-16 18:42 --- *** Bug 35197 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35199
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- Comment #16 from skunk at iskunk dot org 2009-02-28 00:41 --- Building 4.3.3 fails with /usr/home/cport/tmp/bash ./libtool --tag=CXX --mode=compile /usr/home/cport/build/gcc-4.3.3-build-test/./gcc/xgcc -shared-libgcc -B/usr/home/cport/build/gcc-4.3.3-build-test/./gcc -nostdinc++ -L/usr/home/cport/build/gcc-4.3.3-build-test/alphaev56-dec-osf4.0g/libstdc++-v3/src -L/usr/home/cport/build/gcc-4.3.3-build-test/alphaev56-dec-osf4.0g/libstdc++-v3/src/.libs -B/usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/bin/ -B/usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/lib/ -isystem /usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/include -isystem /usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/sys-include -DHAVE_CONFIG_H -I. -I/tg/freeport/src/gcc/gcc--4.3.3/libjava -I./include -I./gcj -I/tg/freeport/src/gcc/gcc--4.3.3/libjava -Iinclude -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/include -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/classpath/include -Iclasspath/include -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/classpath/native/fdlibm -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../boehm-gc/include -I../boehm-gc/include -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/libltdl -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/libltdl -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/.././libjava/../gcc -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../zlib -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -pthread -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -mieee -Wextra -Wall -D_GNU_SOURCE -DPREFIX="\"/usr/home/cport/tmp/GCC\"" -DTOOLEXECLIBDIR="\"/usr/home/cport/tmp/GCC/lib/gcc/alphaev56-dec-osf4.0g/4.3.3\"" -DJAVA_HOME="\"/usr/home/cport/tmp/GCC\"" -DBOOT_CLASS_PATH="\"/usr/home/cport/tmp/GCC/share/java/libgcj-4.3.3.jar\"" -DJAVA_EXT_DIRS="\"/usr/home/cport/tmp/GCC/share/java/ext\"" -DGCJ_ENDORSED_DIRS="\"/usr/home/cport/tmp/GCC/share/java/gcj-endorsed\"" -DGCJ_VERSIONED_LIBDIR="\"/usr/home/cport/tmp/GCC/lib/gcj-4.3.3-9\"" -DPATH_SEPARATOR="\":\"" -DECJ_JAR_FILE="\"\"" -DLIBGCJ_DEFAULT_DATABASE="\"/usr/home/cport/tmp/GCC/lib/gcj-4.3.3-9/classmap.db\"" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL="\"gcj-4.3.3-9/classmap.db\"" -O2 -g -mieee -c -o java/net/natVMNetworkInterface.lo java/net/natVMNetworkInterface.cc libtool: compile: /usr/home/cport/build/gcc-4.3.3-build-test/./gcc/xgcc -shared-libgcc -B/usr/home/cport/build/gcc-4.3.3-build-test/./gcc -nostdinc++ -L/usr/home/cport/build/gcc-4.3.3-build-test/alphaev56-dec-osf4.0g/libstdc++-v3/src -L/usr/home/cport/build/gcc-4.3.3-build-test/alphaev56-dec-osf4.0g/libstdc++-v3/src/.libs -B/usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/bin/ -B/usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/lib/ -isystem /usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/include -isystem /usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/sys-include -DHAVE_CONFIG_H -I. -I/tg/freeport/src/gcc/gcc--4.3.3/libjava -I./include -I./gcj -I/tg/freeport/src/gcc/gcc--4.3.3/libjava -Iinclude -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/include -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/classpath/include -Iclasspath/include -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/classpath/native/fdlibm -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../boehm-gc/include -I../boehm-gc/include -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/libltdl -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/libltdl -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/.././libjava/../gcc -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../zlib -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -pthread -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -mieee -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/usr/home/cport/tmp/GCC\" -DTOOLEXECLIBDIR=\"/usr/home/cport/tmp/GCC/lib/gcc/alphaev56-dec-osf4.0g/4.3.3\" -DJAVA_HOME=\"/usr/home/cport/tmp/GCC\" -DBOOT_CLASS_PATH=\"/usr/home/cport/tmp/GCC/share/java/libgcj-4.3.3.jar\" -DJAVA_EXT_DIRS=\"/usr/home/cport/tmp/GCC/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/usr/home/cport/tmp/GCC/share/java/gcj-endorsed\" -DGCJ_VERSIONED_LIBDIR=\"/usr/home/cport/tmp/GCC/lib/gcj-4.3.3-9\" -DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\" -DLIBGCJ_DEFAULT_DATABASE=\"/usr/home/cport/tmp/GCC/lib/gcj-4.3.3-9/classmap.db\" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.3.3-9/classmap.db\" -O2 -g -mieee -c java/net/natVMNetworkInterface.cc -DPIC -o java/net/natVMNetworkInterface.o In file included from java/net/natVMNetworkInterface.cc:35: /usr/include/net/if.h:144: error: expected ';' before '}' token /usr/include/net/if.h:144: error: expected `;' before '}' token gmake[3]: *** [java/net/natVMNetworkInterf
[Bug other/39400] New: Dist tarball missing file gengtype-lex.c
Bootstrapping gcc-4.4-20090306(.tar.bz2) on Tru64 fails with flex -ogengtype-lex.c /tmp/gcc-4.4-20090306/gcc/gengtype-lex.l flex: unknown flag 'o' gmake[3]: [gengtype-lex.c] Error 1 (ignored) cc -std1 -c -g -DIN_GCC-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/build -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../include -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libcpp/include -I/tg/freeport/arch/tru64/include -I/tg/freeport/arch/tru64/include -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libdecnumber -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libdecnumber/dpd -I../libdecnumber-o build/gengtype-lex.o gengtype-lex.c cc: Severe: No such file or directory ... file is 'gengtype-lex.c' gmake[3]: *** [build/gengtype-lex.o] Error 1 gmake[3]: Leaving directory `/mnt/scratch/build/gcc-build/gcc' gmake[2]: *** [all-stage1-gcc] Error 2 gmake[2]: Leaving directory `/mnt/scratch/build/gcc-build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/mnt/scratch/build/gcc-build' gmake: *** [bootstrap] Error 2 gengtype-lex.c should not have to be generated, obviously. P.S.: Here we also see an issue where the system's ancient version of flex (I don't even know the version number, as it doesn't have an option to print it) doesn't work the way that the makefile expects. Should I file a separate bug, for the configure script to check beforehand whether flex supports the -o option? -- Summary: Dist tarball missing file gengtype-lex.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: skunk at iskunk dot org GCC build triplet: alphaev56-dec-osf4.0g GCC host triplet: alphaev56-dec-osf4.0g GCC target triplet: alphaev56-dec-osf4.0g http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39400
[Bug c++/39788] New: Fixincluded header defines __regex_t, other header needs regex_t
First, the problem. Sample program:
#include
int main(void) { return 0; }
% g++ -c bug.cxx
In file included from
/opt/gcc--4.3.3--tru64/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.3.3/include-fixed/sys/localedef.h:76,
from /usr/include/ctype.h:108,
from bug.cxx:1:
/opt/gcc--4.3.3--tru64/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.3.3/include-fixed/sys/lc_core.h:201:
error: 'regex_t' has not been declared
/opt/gcc--4.3.3--tru64/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.3.3/include-fixed/sys/lc_core.h:202:
error: expected ',' or '...' before '*' token
/opt/gcc--4.3.3--tru64/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.3.3/include-fixed/sys/lc_core.h:203:
error: expected ',' or '...' before '*' token
/opt/gcc--4.3.3--tru64/bin/../lib/gcc/alphaev56-dec-osf4.0g/4.3.3/include-fixed/sys/lc_core.h:204:
error: 'regex_t' has not been declared
Normally, lc_core.h #includes reg_types.h, which has the regex_t typedef, and
all is well. Here, however, it pulls in the fixincluded version of reg_types.h,
which typedefs __regex_t, not regex_t.
This is not a problem for [the fixincluded] regex.h, since right after it
#includes reg_types.h, it typedefs __regex_t to regex_t. Anything else that
uses reg_types.h expecting to get regex_t, however, is left in the lurch.
--
Summary: Fixincluded header defines __regex_t, other header needs
regex_t
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk dot org
GCC build triplet: alphaev56-dec-osf4.0g
GCC host triplet: alphaev56-dec-osf4.0g
GCC target triplet: alphaev56-dec-osf4.0g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39788
[Bug bootstrap/39925] New: classpath build fails with "find: bad option -path"
The system find(1) command on this Tru64 box does not support the -path option.
As far as I can tell, -path is not POSIX. I think it may be preferable to prune
the output using grep(1).
gmake[4]: Entering directory
`/tmp/gcc-build/alphaev56-dec-osf4.0g/libjava/classpath/tools'
Makefile:839: warning: overriding commands for target `gjdoc'
Makefile:774: warning: ignoring old commands for target `gjdoc'
find /tmp/gcc-4.4.0/libjava/classpath/tools/external/asm -name '*.java' -print
> asm.lst
find /tmp/gcc-4.4.0/libjava/classpath/tools/gnu/classpath/tools \
/tmp/gcc-4.4.0/libjava/classpath/tools/com/sun/javadoc \
/tmp/gcc-4.4.0/libjava/classpath/tools/com/sun/tools/doclets \
/tmp/gcc-4.4.0/libjava/classpath/tools/com/sun/tools/javadoc \
/tmp/gcc-4.4.0/libjava/classpath/tools/com/sun/tools/javac \
/tmp/gcc-4.4.0/libjava/classpath/tools/com/sun/tools/javah \
/tmp/gcc-4.4.0/libjava/classpath/tools/sun/rmi/rmic \
-path '*gnu/classpath/tools/gjdoc' -prune -o -path
'*gnu/classpath/tools/doclets' -prune -o -path '*gnu/classpath/tools/taglets'
-prune -o -path '*com/sun/javadoc' -prune -o -path '*com/sun/tools/doclets'
-prune -o -path '*com/sun/tools/javadoc' -prune -o \
-name '*.java' -print > classes.lst
find: bad option -path
gmake[4]: *** [tools.zip] Error 1
gmake[4]: Leaving directory
`/tmp/gcc-build/alphaev56-dec-osf4.0g/libjava/classpath/tools'
gmake[4]: Entering directory
`/tmp/gcc-build/alphaev56-dec-osf4.0g/libjava/classpath'
true DO=all multi-do # gmake
gmake[4]: Leaving directory
`/tmp/gcc-build/alphaev56-dec-osf4.0g/libjava/classpath'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory
`/tmp/gcc-build/alphaev56-dec-osf4.0g/libjava/classpath'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/tmp/gcc-build/alphaev56-dec-osf4.0g/libjava'
gmake[1]: *** [all-target-libjava] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [all] Error 2
--
Summary: classpath build fails with "find: bad option -path"
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk dot org
GCC build triplet: alphaev56-dec-osf4.0g
GCC host triplet: alphaev56-dec-osf4.0g
GCC target triplet: alphaev56-dec-osf4.0g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39925
[Bug other/39951] New: Dangling symlink ".../include-fixed/mach" created on install
After installing GCC:
$ ls -l $PREFIX/lib/gcc/alphaev56-dec-osf4.0g/4.4.0/include-fixed/mach
lrwxr-xr-x 1 locallocal 25 Apr 28 14:22
$PREFIX/lib/gcc/alphaev56-dec-osf4.0g/4.4.0/include-fixed/mach ->
root/usr/sys/include/mach
$ ls -l
$PREFIX/lib/gcc/alphaev56-dec-osf4.0g/4.4.0/include-fixed/root/usr/sys/include/
total 3
drwxr-xr-x 2 locallocal512 Apr 24 23:33 net
drwxr-xr-x 2 locallocal512 Apr 24 23:33 netinet
drwxr-xr-x 2 locallocal512 Apr 24 23:33 sys
--
Summary: Dangling symlink ".../include-fixed/mach" created on
install
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk dot org
GCC build triplet: alphaev56-dec-osf4.0g
GCC host triplet: alphaev56-dec-osf4.0g
GCC target triplet: alphaev56-dec-osf4.0g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39951
[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 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/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 #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 #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/47902] New: Bootstrap failure: libiberty/regex.c: error: two or more data types in declaration specifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47902 Summary: Bootstrap failure: libiberty/regex.c: error: two or more data types in declaration specifiers Product: gcc Version: 4.5.2 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 on this AIX system bombs out with /tmp/gcc-4.5.2-build/./prev-gcc/xgcc -B/tmp/gcc-4.5.2-build/./prev-gcc/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -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 -DHAVE_CONFIG_H -g -O2 -I. -I/home/src/gcc-4.5.2/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic /home/src/gcc-4.5.2/libiberty/regex.c -o regex.o In file included from /tmp/gcc-4.5.2-build/./prev-gcc/include-fixed/sys/wait.h:49:0, from /tmp/gcc-4.5.2-build/./prev-gcc/include-fixed/stdlib.h:233, from /home/src/gcc-4.5.2/libiberty/regex.c:128: /tmp/gcc-4.5.2-build/./prev-gcc/include-fixed/sys/types.h:212:23: error: two or more data types in declaration specifiers make[3]: *** [regex.o] Error 1 make[3]: Leaving directory `/tmp/gcc-4.5.2-build/libiberty' make[2]: *** [all-stage2-libiberty] Error 2 make[2]: Leaving directory `/tmp/gcc-4.5.2-build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/tmp/gcc-4.5.2-build' make: *** [bootstrap-lean] Error 2 The cited portion of include-fixed/sys/types.h looks like this: 8< typedef uint_t uid_t; /* user ID */ typedef uint_t gid_t; /* group ID */ typedef __ptr32 mid_t; /* module ID*/ typedef int32long64_t pid_t; /* process ID */ <--- LINE 212 typedef int32long64_t tid_t; /* thread ID */ typedef charslab_t[12]; /* security label */ typedef longmtyp_t; /* ipc message type */ >8 If I change up the compiler invocation from -c to -E, that same portion looks like this: 8< typedef uint_t uid_t; typedef uint_t gid_t; typedef __ptr32 mid_t; typedef int32long64_t int; <--- HMMM typedef int32long64_t tid_t; typedef char slab_t[12]; typedef long mtyp_t; >8 Interestingly enough... > grep pid_t /tmp/gcc-4.5.2-build/libiberty/config.h #define pid_t int If I stick in an "#undef pid_t" right before the offending line, regex.c compiles successfully.
[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
--- Comment #2 from Daniel Richard G. 2011-02-26
09:18:13 UTC ---
>From config.log:
configure:5203: checking for pid_t
configure:5203: gcc -c -g conftest.c >&5
configure:5203: $? = 0
configure:5203: gcc -c -g conftest.c >&5
conftest.c: In function `main':
conftest.c:79: parse error before `)'
configure:5203: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define _LARGE_FILES 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_UNISTD_H 1
| #define WORDS_BIGENDIAN 1
| #define HAVE_SYS_FILE_H 1
| #define HAVE_SYS_PARAM_H 1
| #define HAVE_LIMITS_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_MALLOC_H 1
| #define HAVE_STRING_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_TIME_H 1
| #define HAVE_SYS_RESOURCE_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_SYS_MMAN_H 1
| #define HAVE_FCNTL_H 1
| #define HAVE_SYS_SYSINFO_H 1
| #define HAVE_SYS_SYSTEMCFG_H 1
| #define HAVE_SYS_WAIT_H 1
| #define TIME_WITH_SYS_TIME 1
| #define SIZEOF_INT 4
| #define UNSIGNED_64BIT_TYPE unsigned long long
| #define HAVE_INTPTR_T 1
| #define HAVE_UINTPTR_T 1
| #define HAVE_UINTPTR_T 1
| /* end confdefs.h. */
| #include
| #ifdef HAVE_SYS_TYPES_H
| # include
| #endif
| #ifdef HAVE_SYS_STAT_H
| # include
| #endif
| #ifdef STDC_HEADERS
| # include
| # include
| #else
| # ifdef HAVE_STDLIB_H
| # include
| # endif
| #endif
| #ifdef HAVE_STRING_H
| # if !defined STDC_HEADERS && defined HAVE_MEMORY_H
| # include
| # endif
| # include
| #endif
| #ifdef HAVE_STRINGS_H
| # include
| #endif
| #ifdef HAVE_INTTYPES_H
| # include
| #endif
| #ifdef HAVE_STDINT_H
| # include
| #endif
| #ifdef HAVE_UNISTD_H
| # include
| #endif
| int
| main ()
| {
| if (sizeof ((pid_t)))
| return 0;
| ;
| return 0;
| }
configure:5203: result: yes
Should I attach a copy of the system's sys/types.h header?
[Bug bootstrap/47907] New: Bootstrap failure: libiberty/hashtab.c: error: conflicting types for 'int_fast16_t'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47907 Summary: Bootstrap failure: libiberty/hashtab.c: error: conflicting types for 'int_fast16_t' Product: gcc Version: 4.5.2 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 After working around bug #47902, bootstrapping GCC 4.5.2 on this AIX system bombs out with /tmp/gcc-4.5.2-build/./prev-gcc/xgcc -B/tmp/gcc-4.5.2-build/./prev-gcc/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -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 -DHAVE_CONFIG_H -g -O2 -I. -I/home/src/gcc-4.5.2/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic /home/src/gcc-4.5.2/libiberty/hashtab.c -o hashtab.o In file included from /home/src/gcc-4.5.2/libiberty/hashtab.c:57:0: /tmp/gcc-4.5.2-build/./prev-gcc/include/stdint.h:72:29: error: conflicting types for 'int_fast16_t' /usr/include/sys/inttypes.h:143:18: note: previous declaration of 'int_fast16_t' was here /tmp/gcc-4.5.2-build/./prev-gcc/include/stdint.h:75:29: error: conflicting types for 'uint_fast8_t' /usr/include/sys/inttypes.h:145:18: note: previous declaration of 'uint_fast8_t' was here /tmp/gcc-4.5.2-build/./prev-gcc/include/stdint.h:76:30: error: conflicting types for 'uint_fast16_t' /usr/include/sys/inttypes.h:146:18: note: previous declaration of 'uint_fast16_t' was here make[3]: *** [hashtab.o] Error 1 make[3]: Leaving directory `/tmp/gcc-4.5.2-build/libiberty' make[2]: *** [all-stage2-libiberty] Error 2 make[2]: Leaving directory `/tmp/gcc-4.5.2-build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/tmp/gcc-4.5.2-build' make: *** [bootstrap-lean] Error 2 Commenting out the offending typedefs in prev-gcc/include/stdint.h gets things going again.
[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 --- Comment #1 from Daniel Richard G. 2011-02-28 09:45:09 UTC --- Much later in the bootstrap process, I get this, which may be related: libtool: compile: /tmp/gcc-4.5.2-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-4.5.2-build/./gcc -nostdinc++ -L/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src -L/tmp/gcc-4.5.2-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/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0 -I/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include -I/home/src/gcc-4.5.2/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -std=gnu++0x -c /home/src/gcc-4.5.2/libstdc++-v3/src/mutex.cc -DPIC -o mutex.o In file included from /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/cstdint:72:0, from /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/ratio:39, from /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/chrono:42, from /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/mutex:41, from /home/src/gcc-4.5.2/libstdc++-v3/src/mutex.cc:25: /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:36:11: error: '::int8_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:37:11: error: '::int16_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:38:11: error: '::int32_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:39:11: error: '::int64_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:41:11: error: '::int_fast8_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:42:11: error: '::int_fast16_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:43:11: error: '::int_fast32_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:44:11: error: '::int_fast64_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:46:11: error: '::int_least8_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:47:11: error: '::int_least16_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:48:11: error: '::int_least32_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:49:11: error: '::int_least64_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:51:11: error: '::intmax_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:52:11: error: '::intptr_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:54:11: error: '::uint8_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:55:11: error: '::uint16_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:56:11: error: '::uint32_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:57:11: error: '::uint64_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:59:11: error: '::uint_fast8_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:60:11: error: '::uint_fast16_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:61:11: error: '::uint_fast32_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:62:11: error: '::uint_fast64_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:64:11: error: '::uint_least8_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:65:11: error: '::uint_least16_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:66:11: error: '::uint_least32_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/tr1_impl/cstdint:67:11: error: '::uint_least64_t' has not been declared /tmp/gcc-4.5.2-build/powerpc-ibm
[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 --- Comment #3 from Daniel Richard G. 2011-02-28 20:01:51 UTC --- I played around with this a bit, and found something rather amusing: sizeof(pid_t) . compiles just fine sizeof((pid_t)) ... parse error before `)' The extra parens do it in. And this is with (an older version of) GCC: % gcc -v Reading specs from /usr/bin/../lib/gcc-lib/powerpc-ibm-aix4.3.3.0/2.9-aix51-020209/specs gcc version 2.9-aix51-020209 This quirk might also be the cause of bug #47907.
[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 --- Comment #4 from Daniel Richard G. 2011-02-28 21:59:28 UTC --- Okay, did some more digging. So I see that the ac_fn_c_check_type function actually tries a test compilation first with sizeof(foo_t), and then sizeof((foo_t)), and the test succeeds only if the first succeeds and the latter fails. So this is actually working as it should---I'd missed that the test log I pasted in shows pid_t being found successfully. The real test failure in config.log is as follows: configure:5203: checking for pid_t configure:5203: /tmp/gcc-4.5.2-build/./prev-gcc/xgcc -B/tmp/gcc-4.5.2-build/./prev-gcc/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -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 -O2 conftest.c >&5 In file included from conftest.c:71:0: /tmp/gcc-4.5.2-build/./prev-gcc/include/stdint.h:72:29: error: conflicting types for 'int_fast16_t' /usr/include/sys/inttypes.h:143:18: note: previous declaration of 'int_fast16_t' was here /tmp/gcc-4.5.2-build/./prev-gcc/include/stdint.h:75:29: error: conflicting types for 'uint_fast8_t' /usr/include/sys/inttypes.h:145:18: note: previous declaration of 'uint_fast8_t' was here /tmp/gcc-4.5.2-build/./prev-gcc/include/stdint.h:76:30: error: conflicting types for 'uint_fast16_t' /usr/include/sys/inttypes.h:146:18: note: previous declaration of 'uint_fast16_t' was here configure:5203: $? = 1 Which is basically bug #47907. I notice that the test for pid_t fails if HAVE_STDINT_H is #defined, and succeeds otherwise.
[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 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 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 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").
[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 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/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 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/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/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 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/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] 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/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/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/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/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 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/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 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 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 #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 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/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 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 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 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 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 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 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 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 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] 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/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/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/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/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 #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/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/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/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/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/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/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/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 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.
