From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Iain Sandoe <developer@sandoe-acoustics.co.uk>
Cc: Richard Guenther <rguenther@suse.de>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Fix PR50999, serialize frontend specific flags (-fexceptions)
Date: Tue, 08 Nov 2011 00:30:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1111080018310.31960@digraph.polyomino.org.uk> (raw)
In-Reply-To: <5F3BC901-F820-42B8-8438-DAF166EAB6D9@sandoe-acoustics.co.uk>
On Mon, 7 Nov 2011, Iain Sandoe wrote:
> > 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).
>
> for some reason it wasn't shifted to the new scheme - perhaps Joseph recalls
> why.
In general I was concerned with options of relevance to multilib selection
(although the actual changes to multilib selection didn't get
implemented), meaning back-end and middle-end options; front-end options
were less relevant. Making similar cleanups to front-end options (i.e.
making as much use of .opt features as possible instead of ad hoc code) is
certainly still worthwhile as a cleanup. (And there is still scope for
more cleanup of some back-end options: moving some handling of enumeration
options in override hooks to use Enum in particular.)
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2011-11-08 0:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-07 12:40 Richard Guenther
2011-11-07 12:49 ` Eric Botcazou
2011-11-07 13:08 ` Richard Guenther
2011-11-07 14:11 ` Richard Guenther
2011-11-08 0:30 ` Joseph S. Myers
2011-11-07 12:49 ` Iain Sandoe
2011-11-07 12:50 ` Richard Guenther
2011-11-07 12:51 ` Iain Sandoe
2011-11-07 13:15 ` Richard Guenther
2011-11-08 0:30 ` Joseph S. Myers [this message]
2011-11-08 14:51 ` Iain Sandoe
2011-11-08 14:53 ` Richard Guenther
2011-11-08 0:27 ` Joseph S. Myers
2011-11-08 14:00 ` Richard Guenther
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1111080018310.31960@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=developer@sandoe-acoustics.co.uk \
--cc=gcc-patches@gcc.gnu.org \
--cc=rguenther@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).