From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13199 invoked by alias); 17 Mar 2003 23:33:59 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 13121 invoked by uid 48); 17 Mar 2003 23:33:58 -0000 Date: Mon, 17 Mar 2003 23:33:00 -0000 Message-ID: <20030317233358.13120.qmail@sources.redhat.com> To: debian-gcc@lists.debian.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, jason@gcc.gnu.org, parisc-linux@lists.parisc-linux.org, tausq@debian.org From: jason@gcc.gnu.org Reply-To: jason@gcc.gnu.org, debian-gcc@lists.debian.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, jason@gcc.gnu.org, parisc-linux@lists.parisc-linux.org, tausq@debian.org, gcc-gnats@gcc.gnu.org Subject: Re: c++/10091: [3.3 regression] [parisc] ICE in cp_expr_size, at cp/cp-lang.c:307 X-SW-Source: 2003-03/txt/msg01174.txt.bz2 List-Id: Synopsis: [3.3 regression] [parisc] ICE in cp_expr_size, at cp/cp-lang.c:307 State-Changed-From-To: open->analyzed State-Changed-By: jason State-Changed-When: Mon Mar 17 23:33:58 2003 State-Changed-Why: The problem is that the #pragma pack means that _GEIdx::addr might not have the usual alignment of an ftn_addr, so we can't just take the address of current.addr in order to bind it to a reference. expand_expr knows this, and tries to make a bitwise copy and take the address of that. But since ftn_addr has a copy constructor, we can't make bitwise copies, so we abort. Now, in your particular testcase ftn_golded_nodelist_index::current does in fact have enough alignment for a ftn_addr, so we'd be OK just using the address of current.addr (it would be different if either of the latter two classes began with, say, a char field). But the backend doesn't currently track alignment info from enclosing classes, so we are conservative and fail. We used to err in the other direction: taking the address of a packed field would lose any information about it possibly having less alignment, and things trying to use the resulting pointer could get a bus error. See g++.dg/other/packed1.C. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10091