--- 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
--- 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
ap
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
--- 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 &
duct: 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
--- 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
--- 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
--- 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,
--- 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 fi
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 tri
--- 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 s
--- 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 s
--- 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 t
--- 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 b
--- 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
--- 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 bu
--- 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---
--- 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
--- 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 d
--- 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
O
--- 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
--- 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 loo
--- 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 And
--- 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
--- 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
--- 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
: 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: powe
MED
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
--- 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 "
--- 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
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
omponent: 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
--- 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
--- 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
a/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 t
--- 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 l
--- 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.:= alph
--- 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
--- 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
r
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
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
rectory `/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: bootstra
t; 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
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
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-cp
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-t
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?
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
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
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 func
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
Prior
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++
-
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
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 succe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
Daniel Richard G. changed:
What|Removed |Added
CC||skunk at iskunk dot org
--- Comment
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.
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
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
produc
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
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
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
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
e
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 sys
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
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
Stat
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 exc
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 mode
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
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 c
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 t
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,
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: UN
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 newl
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, s
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.
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.
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'
/tm
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:
[.
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 Rich
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
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 supp
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,
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
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-c
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: UNCO
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
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. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47907
Daniel Richard G. changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47902
Daniel Richard G. changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
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. ***
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 a
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 a
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++
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
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
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
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
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 t
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 addre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009
Daniel Richard G. changed:
What|Removed |Added
Component|target |spam
--- Comment #9 from Daniel Richa
1 - 100 of 166 matches
Mail list logo
