From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28599 invoked by alias); 25 Jun 2008 21:08:39 -0000 Received: (qmail 28589 invoked by uid 22791); 25 Jun 2008 21:08:38 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 25 Jun 2008 21:08:21 +0000 Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id m5PL8BQ0002110 for ; Wed, 25 Jun 2008 22:08:12 +0100 Received: from yx-out-2324.google.com (yxl31.prod.google.com [10.190.3.223]) by zps77.corp.google.com with ESMTP id m5PL7cVN008586 for ; Wed, 25 Jun 2008 14:08:10 -0700 Received: by yx-out-2324.google.com with SMTP id 31so729125yxl.1 for ; Wed, 25 Jun 2008 14:08:10 -0700 (PDT) Received: by 10.142.204.18 with SMTP id b18mr7173482wfg.126.1214428089325; Wed, 25 Jun 2008 14:08:09 -0700 (PDT) Received: by 10.142.163.18 with HTTP; Wed, 25 Jun 2008 14:08:09 -0700 (PDT) Message-ID: <8a0e66f0806251408q61a7031fw6b568353bd63ce2@mail.gmail.com> Date: Wed, 25 Jun 2008 21:13:00 -0000 From: "Bill Maddox" To: "Rafael Espindola" Subject: Re: [lto][patch] remove local variables from types (after gimplification) Cc: "Richard Guenther" , gcc-patches , "Diego Novillo" In-Reply-To: <38a0d8450806241326w5f03bf3bo4c6e16eff91f675f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <38a0d8450806230743s2e1bdcd9q71b6266b85eef73d@mail.gmail.com> <84fc9c000806240214i38e62c88y75957c6eaaab567d@mail.gmail.com> <38a0d8450806240604r71457d6etfade401b0a38ab04@mail.gmail.com> <84fc9c000806240617me7aa397n2afde424583222ce@mail.gmail.com> <38a0d8450806241326w5f03bf3bo4c6e16eff91f675f@mail.gmail.com> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-06/txt/msg01609.txt.bz2 On Tue, Jun 24, 2008 at 1:26 PM, Rafael Espindola wrote: > 2008-06-24 Rafael Espindola > > * calls.c (must_pass_in_stack_var_size_or_pad): Don't check if > TYPE_SIZE is NULL. > * expr.c (store_field): Don't check if TYPE_SIZE is NULL. > * tree.c (reset_type_lang_specific): Set both TYPE_SIZE_UNIT > and TYPE_SIZE or none of them. Don't set TYPE_MAX_VALUE to > NULL. call set_min_and_max_values_for_integral_type. I updated to top of lto branch, and noticed the following test was first to fail: FAIL: gcc.c-torture/compile/20020210-1.c -O2 -flto (internal compiler error) In this case, the failure is due to an attempt to stream out a SAVE_EXPR node. I have a development sandbox that includes the patch, but is apparently choosing a different order in which to stream out the nodes, and which exhibits a much more interesting failure, encountering a local variable in a type. The program is trivial: void f(int a, struct {int b[a];} c) {} The problem is that the size of the *structure* type is variable, due to the embedded VLA. While this program is not valid C99, it is apparently permitted as a GNU extension, and similar constructs arise in other languages, e.g. Ada. Clearly we are not catching all of the occurrences of variables within types. This may just be an oversight, but I'd like to know if it is generally the case that the middle-end/back-end does not not need this information, or whether the justification for erasing the size of array types is specific to the case of arrays. --Bill