From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9787 invoked by alias); 22 Aug 2005 03:32:48 -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 9780 invoked by uid 22791); 22 Aug 2005 03:32:45 -0000 Received: from h-68-164-203-246.nycmny83.covad.net (HELO dberlin.org) (68.164.203.246) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 22 Aug 2005 03:32:45 +0000 Received: from [127.0.0.1] (HELO localhost) by dberlin.org (CommuniGate Pro SMTP 5.0c1) with ESMTP id 8113657; Sun, 21 Aug 2005 23:32:38 -0400 Subject: Re: Bootstrap failure on powerpc-apple-darwin8 with Ada From: Daniel Berlin To: Richard Henderson Cc: Laurent GUERBY , Chris Douty , gcc@gcc.gnu.org In-Reply-To: <20050822024458.GA29862@redhat.com> References: <90F71D27-8EDA-4E94-9F2E-B6E0CE4E27BF@ampexdata.com> <1124491018.7742.326.camel@pc.site> <1124491478.7742.328.camel@pc.site> <1124501675.7748.8.camel@linux.site> <20050821021550.GA14093@redhat.com> <1124591601.6453.36.camel@linux.site> <20050822024458.GA29862@redhat.com> Content-Type: text/plain Date: Mon, 22 Aug 2005 03:32:00 -0000 Message-Id: <1124681554.24136.5.camel@linux.site> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-08/txt/msg00571.txt.bz2 > And would that be because analyze_expr isn't implemented for Ada? That doesn't bother me so much, actually (mainly because i don't care about Ada). It's the fact that it's popping up in C/C++ that does. > > > IE if we have something very funky like: > > > > static int c; > > static int d; > > static struct foo *a = &{&c, &d}; > > > > (and if you look, andrew found a case where we are producing > > &, so this is a possibility, AFAICT) > > I disbelieve you can get this in C or C++. That's how this whole discussion popped up originally. Andrew discovered an equivalent C/C++ testcase that produces &. See PR 23171. Since C/C++'s analyze_expr (or whatever you want to produce that code) doesn't produce the nice code below for that testcase, we get screwed. > The fragment above > is a syntax error. AFAIK, all of this is simple laziness in the > Ada front end: generating & is how things were done > at the beginning of time, and it was easier to change this in the > gimplifier than to modify the code that generated this directly. > > > In the above case, we need to see the &c, &d part. > > How does analyze_expr help us here? > > By transforming to > > static struct foo tmp = { &c, &d }; > static struct foo* a = &tmp; By "gimplify static initializers", i actually meant produce the code you've listed from whatever was generating &. Nothing more. If analyze_expr (or something) actually did that, i'd be a very happy man. It doesn't, unfortunately. Another perfectly reasonable solution would be to force us to not generate such crap in the first place.