From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-92859-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 16032 invoked by alias); 17 Mar 2004 10:55:29 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 16009 invoked from network); 17 Mar 2004 10:55:28 -0000
Received: from unknown (HELO mail.libertysurf.net) (213.36.80.91)
  by sources.redhat.com with SMTP; 17 Mar 2004 10:55:28 -0000
Received: from localhost.localdomain (212.129.22.43) by mail.libertysurf.net (6.5.036)
        id 403C47940242B444; Wed, 17 Mar 2004 11:55:21 +0100
Content-Type: text/plain;
  charset="iso-8859-1"
From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: Mark Mitchell <mark@codesourcery.com>
Subject: Re: GCC Status Report (2004-03-09)
Date: Wed, 17 Mar 2004 10:56:00 -0000
User-Agent: KMail/1.4.3
Cc: gcc@gcc.gnu.org
References: <200403091809.i29I9P04020607@sirius.codesourcery.com> <200403111030.14616.ebotcazou@act-europe.fr> <40573108.4080602@codesourcery.com>
In-Reply-To: <40573108.4080602@codesourcery.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200403171156.56151.ebotcazou@libertysurf.fr>
X-SW-Source: 2004-03/txt/msg00940.txt.bz2

> So, would you please apply Olivier's patch to the 3.4 branch and the
> mainline?  Then, we need to come up with some better long-term solution.

There is a hitch: the C front-end is relying on the clearing optimization to 
implement the semantics mandated by C99 §6.7.8 [19], that is for

struct B {
    struct A a;
    void * const b;
    struct A const * const c;
    struct A const *d;
};

bar (void *x)
{
  struct B y = { .b = x, .c = (void *) 0 };
}

the front-end sends a constructor with only 2 elements to the middle-end, 
while C99 wants b.a and b.d to be cleared too.

Amazingly, the patch causes no failure in the whole testsuite except for the 
PR's testcase (gcc.dg/20031202-1.c), which now fails everywhere.

Hum... what to do here?  Other front-ends may also be relying on this 
semantics (the middle-end clears every record or union whose constructor is 
not complete).  Maybe we could simply revert to the state of the 3.3 branch.

-- 
Eric Botcazou