Re: GCC 3.3 build on AIX 5.2, ICE

Re: GCC 3.3 build on AIX 5.2, ICE

[Dara Hazeghi]

The ICE you're seeing looks a lot like bug 9382, which
is currently in waiting. The hypothesis was that the
stage1 compiler was being miscompiled...

This discussion would probably be more proper on
gcc-bugs, but what problems did you see building with
xlc?

Dara

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: GCC 3.3 build on AIX 5.2, ICE

[David Edelsohn]

>>>>> Dara Hazeghi writes:

Dara> The ICE you're seeing looks a lot like bug 9382, which
Dara> is currently in waiting. The hypothesis was that the
Dara> stage1 compiler was being miscompiled...

	This new report is not a bug in GCC and neither is bug 9382, which
I have closed.  The problem is that AIX 5.2 supports atoll(), but the
cached stdlib.h header file in the version of GCC used to bootstrap does
not include a prototype.  The stage1 compiler does not interpret the
return argument from atoll() correctly and ICEs.  The fix is to remove the
"fixed" header file from the version of GCC used to bootstrap on AIX 5.2.

David

Re: GCC 3.3 build on AIX 5.2, ICE

[Dara Hazeghi]

--- David Edelsohn <dje@watson.ibm.com> wrote:
> 	This new report is not a bug in GCC and neither is
> bug 9382, which
> I have closed.  The problem is that AIX 5.2 supports
> atoll(), but the
> cached stdlib.h header file in the version of GCC
> used to bootstrap does
> not include a prototype.

Thanks for setting me straight on this one. I don't
suppose there's a similarly straightforward
explanation for PR 9996?

Dara

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: GCC 3.3 build on AIX 5.2, ICE

[Alexy Khrabrov]

On Fri, Jun 27, 2003 at 10:42:59PM -0400, David Edelsohn wrote:
> >>>>> Dara Hazeghi writes:
> 
> Dara> The ICE you're seeing looks a lot like bug 9382, which
> Dara> is currently in waiting. The hypothesis was that the
> Dara> stage1 compiler was being miscompiled...
> 
> 	This new report is not a bug in GCC and neither is bug 9382, which
> I have closed.  The problem is that AIX 5.2 supports atoll(), but the
> cached stdlib.h header file in the version of GCC used to bootstrap does
> not include a prototype.  The stage1 compiler does not interpret the
> return argument from atoll() correctly and ICEs.  The fix is to remove the
> "fixed" header file from the version of GCC used to bootstrap on AIX 5.2.
> 
> David

I see.  I'm not root on that big AIX box, is there a simple way
to tweak the bootstrap in some way to achieve the same effect without
touching the old gcc?  And, is there a way to use xlc for bootstrapping,
or it is not supported?

Cheers,
Alexy

Re: GCC 3.3 build on AIX 5.2, ICE

[David Edelsohn]

>>>>> Alexy Khrabrov writes:

Alexy> I'm not root on that big AIX box, is there a simple way
Alexy> to tweak the bootstrap in some way to achieve the same effect without
Alexy> touching the old gcc?

	No.

Alxy> And, is there a way to use xlc for bootstrapping,
Alexy> or it is not supported?

	I have not had trouble bootstrapping with xlc but others have.

David

Re: GCC 3.3 build on AIX 5.2, ICE

[Alexy Khrabrov]

On Mon, Jun 30, 2003 at 12:37:50PM -0400, David Edelsohn wrote:
> >>>>> Alexy Khrabrov writes:
> 
> Alexy> I'm not root on that big AIX box, is there a simple way
> Alexy> to tweak the bootstrap in some way to achieve the same effect without
> Alexy> touching the old gcc?
> 
> 	No.

Hmmm, I was thinking of putting a correct stdlib.h on an include path
earlier than the broken one, then messing with configure to look at
that fixed include path...  Doable?
 
> Alexy> And, is there a way to use xlc for bootstrapping,
> Alexy> or it is not supported?
> 
> 	I have not had trouble bootstrapping with xlc but others have.
> 
> David

Yes, I'm getting

xlc_r -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-3.3/libiberty/../include   ../../gcc-3.3/libiberty/objalloc.c -o objalloc.o
"./config.h", line 17.9: 1506-213 (S) Macro name inline cannot be redefined.
"./config.h", line 17.9: 1506-358 (I) "inline" is defined on line 177 of ../../gcc-3.3/libiberty/../include/ansidecl.h.

So those with a virginal AIX, do they get a gcc?  This thing I see there
is called powerpc-ibm-aix5.1.0.0/2.9-aix51-020209, I wonder if that's
IBM-made...  But if they don't, 3.3 better compile with xlc...

Cheers,
Alexy

Re: GCC 3.3 build on AIX 5.2, ICE

[David Edelsohn]

>>>>> Alexy Khrabrov writes:

Alexy> Hmmm, I was thinking of putting a correct stdlib.h on an include path
Alexy> earlier than the broken one, then messing with configure to look at
Alexy> that fixed include path...  Doable?
 
	Maybe.

Alexy> xlc_r -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-3.3/libiberty/../include   ../../gcc-3.3/libiberty/objalloc.c -o objalloc.o

	Please read the installation instructions: you need to bootstrap
with "cc", not "xlc" or "xlc_r".

David

Re: GCC 3.3 build on AIX 5.2, ICE

[Alexy Khrabrov]

I've tried all possible combinations on AIX, and now
I've got quite far with the native cc for bootstrap.
I had to make the following edits:

in gcc/intl/plural.c, cc complains that the body
if yylex doesn't match its prototype w.r.t. the 2nd
parameter, where the prototype declares unsigned char**
and the body has a unsigned char**.  What is mind-boggling 
is that they are identical, except the body is K&R, but
even replacing the body's head by the prototype _literally_
still emits the error with AIX cc!  So I oblige and remove 
the const from the prorotype, then cc runs through, but
xgcc of course complains -- so I put the const back and
that part is over.

Another complaint is about build's math.h, where the
... \
#ifndef __cplusplus 
...
#endif
conditional are embedded in the midst of a macro definition,
and cc considers them macro parameters -- I just remove them
and now I'm at the stage where the library contents is checked
for declaration and linkage, and it's extremely slow and
seemingly repetitive -- after a few hours, same declaration,
linkage checks.  Is there an endless loop in the make somewhere?
I put the original plural.c back with its time intact, but the
math.h is edited.  Is it supposed to take forever on AIX?

Cheers,
Alexy

Re: GCC 3.3 build on AIX 5.2, ICE

[David Edelsohn]

>>>>> Alexy Khrabrov writes:

Alexy> now I'm at the stage where the library contents is checked
Alexy> for declaration and linkage, and it's extremely slow and
Alexy> seemingly repetitive -- after a few hours, same declaration,
Alexy> linkage checks.  Is there an endless loop in the make somewhere?
Alexy> I put the original plural.c back with its time intact, but the
Alexy> math.h is edited.  Is it supposed to take forever on AIX?

	It is somewhat faster if you use CONFIG_SHELL=bash

David

Re: GCC 3.3 build on AIX 5.2, ICE

[Segher Boessenkool]

Alexy Khrabrov wrote:
> Another complaint is about build's math.h, where the
> ... \
> #ifndef __cplusplus 
> ...
> #endif
> conditional are embedded in the midst of a macro definition,
> and cc considers them macro parameters --

cc is right here; line splicing is translation phase 2, while
preprocessing directives are done in phase 4.  This code is
not valid C.

Is this file part of GCC?


Segher

Re: GCC 3.3 build on AIX 5.2, done

[Alexy Khrabrov]

On Wed, Jul 02, 2003 at 04:50:40PM +0200, Segher Boessenkool wrote:
> Alexy Khrabrov wrote:
> > Another complaint is about build's math.h, where the
> > ... \
> > #ifndef __cplusplus 
> > ...
> > #endif
> > conditional are embedded in the midst of a macro definition,
> > and cc considers them macro parameters --
> 
> cc is right here; line splicing is translation phase 2, while
> preprocessing directives are done in phase 4.  This code is
> not valid C.
> 
> Is this file part of GCC?

This is what gcc has in its fixed headers as include/math.h,
line 1071, on AIX 5.2, 64 bit...  This is not gcc's source,
but whatever it hoards in the build directory.  Still it
grabs stuff without fixing...

Cheers,
Alexy