From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25171 invoked by alias); 2 Nov 2002 01:50:02 -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 25146 invoked by uid 61); 2 Nov 2002 01:50:02 -0000 Date: Fri, 01 Nov 2002 17:50:00 -0000 Message-ID: <20021102015002.25145.qmail@sources.redhat.com> To: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, germain@cs.utah.edu, nobody@gcc.gnu.org From: bangerth@dealii.org Reply-To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, germain@cs.utah.edu, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: c++/8417: g++ 3.2 generating different (and incorrect?) code from g++ 2.95.4 X-SW-Source: 2002-11/txt/msg00071.txt.bz2 List-Id: Synopsis: g++ 3.2 generating different (and incorrect?) code from g++ 2.95.4 State-Changed-From-To: open->closed State-Changed-By: bangerth State-Changed-When: Fri Nov 1 17:50:01 2002 State-Changed-Why: What you try is calling for trouble: you should not assume anything about where member variables are located relative to "this". Also, "this" may change from sub- to superclass, depending on the layout of vtables, etc. You should only try to zero out data pointed to by "this" if you absolutely know what you do, and stick to the ABI that is relevant to your platform. This said, the ABI gcc uses on Linux has changed between 2.95 and 3.2, so the inconsistent behavior is not surprising. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8417