From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25315 invoked by alias); 27 Mar 2012 09:50:06 -0000 Received: (qmail 25279 invoked by uid 22791); 27 Mar 2012 09:50:03 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Mar 2012 09:49:49 +0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2R9nlg0023922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Mar 2012 09:49:48 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2R9nkwZ004635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Mar 2012 09:49:47 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2R9nkCI013067; Tue, 27 Mar 2012 04:49:46 -0500 Received: from [192.168.1.4] (/79.46.231.43) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Mar 2012 02:49:46 -0700 Message-ID: <4F718C81.70501@oracle.com> Date: Tue, 27 Mar 2012 09:50:00 -0000 From: Paolo Carlini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2 MIME-Version: 1.0 To: Richard Guenther CC: Steven Bosscher , GCC Mailing List , GCC Patches Subject: Re: [patch][RFC] bail out after front-end errors References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2012-03/txt/msg01713.txt.bz2 Hi, > On Mon, Mar 26, 2012 at 10:56 PM, Steven Bosscher wrote: >> Hello, >> >> This patch is one way to address PR44982. I see no good reason to >> cgraph_finalize_compilation_unit if there were parse errors. As Richi >> already pointed out, GCC traditionally has proceeded after parse >> errors to preserve warnings and errors we generate from the middle-end >> and during semantic analysis. But it seems to me that those warnings >> are not very meaningful after parse errors (-Wuninitialized after a >> parse error??), and errors from the middle end are mostly for exotic >> code (involving asm()s and the like). Bailing out after parse errors >> is therefore IMHO the right thing to do for the common case. >> >> Thoughts? Comments? > Conceptually it makes sense. Did you check whether allowing the > FE too proceed to final_write_globals but stop before > cgraph_finalize_compilation_unit > preserves any errors? I would expect that maybe FE global variable > diagostics are defered until that? It would be nice to finally move > the call to cgraph_finalize_compilation_unit to the middle-end ... > (warning, if you try that you run into an issue with the Java frontend ... :/) I bet it does preserve some errors. I noticed that when I analyzed a bit PR40405, see Comment #3 in particular. Thanks, Paolo.