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

["ghazi at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From ghazi at gcc dot gnu dot org  2005-06-10 01:20 -------
(In reply to comment #22)
> Subject: Re:  GCC should combine adjacent stdio calls
> On Thu, Jun 09, 2005 at 07:52:42PM -0000, joseph at codesourcery dot com 
wrote:
> > (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.
> > 
> Gah, so we'll need to parse the format string then.  Oh, well.
> Diego.

While I agree that we need to parse the format string, that's to solve other 
issues like detecting %n.  I'm not convinced the above a-b-c cases Joseph cites 
are so clear-cut against doing the transformation.  To me it seems all three 
cases are pathological self clobbering actions (read&write to the same place in 
one action) or rely on when the OS decides to sync the disk.

In case (a), you're suggesting that the programmer would allocate a buffer to 
be used by stdio buffering, pass it to setvbuf, then effectively read and write 
to this buffer in the same printf statement by printing the contents of the 
buffer through the very stream it's being used by for buffering.  First of all 
I'd like to know if the standard guarantees the contents of a stdio buffer (not 
just when it's flushed) at enough level of detail to reliably retrieve results 
from it in the midst of buffering through it.  I checked and found different 
contents between glibc and solaris2.

Case (b) involves fmemopen, and I assume you refer to a case where you open 
memory for writing, printf to the resulting FILE*, and pass a pointer to the 
memory area back into printf.  This can only lead to disaster as you clobber 
the same memory you are reading from.  Since fmemopen is a gnu extension, it 
can do whatever it wants, but I suspect you're entering unspecified territory 
here for C programs.

Case (c) with mmap again looks like you're reading and writing to the same 
place, but the results depend on how buffering and disk syncing interact.  
Again, what guarantees from the C standards do we have here on what the results 
should look like?  Since IIRC mmap isn't part of C, there are no guarantees.


I'm willing to be convinced otherwise, can you construct a valid code snippet 
whose behavior is completely specified which works with two separate printf 
statements but fails when they're combined?


-- 


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