This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/21982] GCC should combine adjacent stdio calls


------- Additional Comments From ghazi at gcc dot gnu dot org  2005-06-09 17:21 -------
(In reply to comment #14)
> Subject: Re:  GCC should combine adjacent stdio
>  calls
> On Thu, 9 Jun 2005, ghazi at gcc dot gnu dot org wrote:
> > 
> > ------- Additional Comments From ghazi at gcc dot gnu dot org  2005-06-09 
16:55 -------
> > (In reply to comment #3)
> > > Subject: Re:  GCC should combine adjacent stdio
> > >  calls
> > > Another problem case is if the first format has excess arguments (which 
is 
> > > permitted by ISO C) - those arguments must be evaluated but not included 
> > > in the concatenated argument list.
> > 
> > While it may be legal, our -Wformat option warns about excess arguments and 
I 
> > would suggest we don't attempt any optimization unless we pass -Wformat 
> > cleanly.  So I think this one is surmountable.
> 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?



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]