From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17583 invoked by alias); 7 Nov 2011 12:40:24 -0000 Received: (qmail 17573 invoked by uid 22791); 7 Nov 2011 12:40:23 -0000 X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Nov 2011 12:40:10 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 2605A8B2F9; Mon, 7 Nov 2011 13:40:09 +0100 (CET) Date: Mon, 07 Nov 2011 12:50:00 -0000 From: Richard Guenther To: Iain Sandoe Cc: gcc-patches@gcc.gnu.org, "Joseph S. Myers" Subject: Re: [PATCH] Fix PR50999, serialize frontend specific flags (-fexceptions) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: 2011-11/txt/msg00929.txt.bz2 On Mon, 7 Nov 2011, Iain Sandoe wrote: > > On 7 Nov 2011, at 12:17, Richard Guenther wrote: > > > > > This tries to find a way to prepend explicitly set command-line options > > by those implicitly set by the frontend (-fexceptions in this case). > > Unfortunately we don't seem to have a good way to extract this information > > easily, so for -fexceptions I hope all frontends set that during > > init_options_struct. > > It would also be nice to preserve the Objective-C flavor (GNU/NeXT), since we > have to make a guess for this in darwin.c when in lto. How is the default selected (that's not obvious to me). flag_next_runtime doesn't use options mechanisms it seems, that's bad. Both -fgnu-runtime and -fnext-runtime are frontend-only flags, they should be at least also enabled for LTO, otherwise LTO cannot do anything about the flag (and if it were LTO supported it would already be saved properly). Please provide a patch to move flag_next_runtime to properly use the new option mechanism to avoid the need to handle it in c-opts.c explicitely (and thus avoid the need to handle it in lto explicitely). Thanks, Richard.