From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28141 invoked by alias); 18 Oct 2002 22:34:35 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 28116 invoked from network); 18 Oct 2002 22:34:34 -0000 Received: from unknown (HELO e2.ny.us.ibm.com) (32.97.182.102) by sources.redhat.com with SMTP; 18 Oct 2002 22:34:34 -0000 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9IMYX0K077276; Fri, 18 Oct 2002 18:34:33 -0400 Received: from dyn9-47-17-68.beaverton.ibm.com (dyn9-47-17-68.beaverton.ibm.com [9.47.17.68]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9IMYUMa068426; Fri, 18 Oct 2002 18:34:31 -0400 Received: (from janis@localhost) by dyn9-47-17-68.beaverton.ibm.com (8.9.3/8.9.3) id PAA03321; Fri, 18 Oct 2002 15:36:23 -0700 Date: Fri, 18 Oct 2002 17:12:00 -0000 From: Janis Johnson To: Mark Mitchell Cc: David Edelsohn , Janis Johnson , Andreas Schwab , Aldy Hernandez , "gcc@gcc.gnu.org" Subject: Re: ia64 linux doesn't bootstrap Message-ID: <20021018153623.A3303@us.ibm.com> References: <200210182002.QAA29492@makai.watson.ibm.com> <5110000.1034979917@warlock.codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5110000.1034979917@warlock.codesourcery.com>; from mark@codesourcery.com on Fri, Oct 18, 2002 at 03:25:17PM -0700 X-SW-Source: 2002-10/txt/msg01154.txt.bz2 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 > 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