This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ia64 linux doesn't bootstrap
- From: Janis Johnson <janis187 at us dot ibm dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: David Edelsohn <dje at watson dot ibm dot com>, Janis Johnson <janis187 at us dot ibm dot com>, Andreas Schwab <schwab at suse dot de>, Aldy Hernandez <aldyh at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 18 Oct 2002 15:36:23 -0700
- Subject: Re: ia64 linux doesn't bootstrap
- References: <200210182002.QAA29492@makai.watson.ibm.com> <5110000.1034979917@warlock.codesourcery.com>
On Fri, Oct 18, 2002 at 03:25:17PM -0700, Mark Mitchell wrote:
>
>
> --On Friday, October 18, 2002 04:02:53 PM -0400 David Edelsohn
> <dje@watson.ibm.com> wrote:
>
> > Tighten your seatbelt, the AIX failure is another case where the C
> > and C++ front-ends are not consistent with respect to the state of a DECL
> > after warnings. I am not sure which one is right.
> >
> > The testcase in g++.dg/break/bitfield7_y.C creates a bitfield that
> > is too wide:
> >
> > union U {
> > int i: 4096;
> > };
>
> The key point is that this is valid C++, but not valid C.
>
> So, C++ needs to handle it (somehow) and C does not.
>
> The way the C++ front end tries to handle this is like this. Suppose
> that your widest integer type has 64 bits. Then, G++ presents "i" as
> a 64-bit bit-field to the back end. Then, it creates some extra
> space as an unnamed giant bit field.
>
> I suspect we are running into problems with the unnamed giant field.
>
> But, nobody should every be trying to read or write those bits. Why
> is that happenning?
>
> Anyhow, what is the triplet for the target? If I run bitfield7.C on
> that target's cc1plus I take it I will see the failure?
This is the new test g++.dg/compat/break/bitfield7_main.C, when the
file bitfield7_y.C is compiled. I think you'll see the failure with
powerpc-eabisim or powerpc-unknown-linux.gnu.
Janis