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

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From joseph at codesourcery dot com  2005-06-09 19:52 -------
Subject: Re:  GCC should combine adjacent stdio
 calls

On Thu, 9 Jun 2005, dnovillo at redhat dot com wrote:

> > Although it may not be valid to manipulate the FILE * directly, it seems 
> > quite possible that a program might call another <stdio.h> function 
> > between the printf calls
> >
> That is fine.  Any call between the two builtins blocks the
> merging.
> 
> > that function on the particular implementation 
> > having a macro expansion without a function call.
> >
> Sorry, you lost me here.

Suppose an implementation defines e.g. clearerr as a macro, and the 
expansion of that macro just clears bits in the stdio structure and 
doesn't call any functions.  Then though the user's source code looks like 
it contains a function call, after preprocessing it contains manipulation 
of bits of the FILE structure for stdout instead.

> > It is also possible 
> > that values of arguments to the second built-in printf call may depend on 
> > the first one having been previously evaluated; for example, given
> > 
> > extern char *s;
> > extern int i;
> > 
> > printf("%d", i);
> > printf("%.5s", s);
> > 
> > you can't merge the printf calls because the first one could have changed 
> > what is pointed to by s.
> > 
> How can printing an integer to stdout affect 's'?  Unless 's' has
> been somehow mapped to stdout's buffer?  Is that what you have in
> mind?

(a) It could be stdio's buffer (via setvbuf).

(b) It could be a glibc memory stream opened with fmemopen (if the user 
assigned to stdout - which glibc allows - or you do this optimization on 
fprintf and not just printf).

(c) It could point to a memory mapping of the file being written.



-- 


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