This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/21982] GCC should combine adjacent stdio calls
- From: "joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 9 Jun 2005 19:15:16 -0000
- Subject: [Bug tree-optimization/21982] GCC should combine adjacent stdio calls
- References: <20050609125653.21982.ghazi@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From joseph at codesourcery dot com 2005-06-09 19:15 -------
Subject: Re: GCC should combine adjacent stdio
calls
On Thu, 9 Jun 2005, ghazi at gcc dot gnu dot org wrote:
> > We linked -Wformat into optimization before, then removed the link.
> > Although we could resurrect the status_warning function which could set a
> > status variable if it would warn rather than emitting the warning (and
> > again save and restore all the variable controlling format warnings), it's
> > not clear this is very desirable.
>
> Why is that?
>
> IIRC, the reason it was removed was that we never did any builtin printf
> trasformations with arguments beyond e.g. "%s\n", "%c". So it was easier to
> simply check these cases manually than invoking the whole format parsing
> routine.
>
> However if we now want to ensure there were no excess arguments I don't see a
> better way without mostly reimplementing a second format parser. What would
> you suggest?
The requirements for -Wformat and for testing whether you can concatenate
formats this way are rather different: there are large numbers of
variables controlling the details of warning, but optimization shouldn't
depend on these except for the standard version (so it needs to save
various variables, turn on -pedantic and set other variables to known
values - and whenever a format warning is split up this list needs
updating); many format warnings are for constructs which have well-defined
meaning but seem odd to write, and optimizing those is reasonable; the
format warning code has no reason to be concerned with %n being a problem
(although turning on -pedantic will deal with disabling this optimization
for formats with $ operand numbers).
At least, try to work out a better interface to the format checking than
the one used last time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982