Bug 61739

Summary: __builtin_printf optimization conflicts with POSIX semantics
Product: gcc Reporter: Rich Felker <bugdal>
Component: cAssignee: Not yet assigned to anyone <unassigned>
Status: UNCONFIRMED ---    
Severity: normal CC: egallager
Priority: P3    
Version: unknown   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed:
Attachments: test case

Description Rich Felker 2014-07-08 00:37:03 UTC
Created attachment 33086 [details]
test case


"All functions that reference (FILE *) objects, except those with names ending in _unlocked, shall behave as if they use flockfile() and funlockfile() internally to obtain ownership of these (FILE *) objects."

Source: http://pubs.opengroup.org/onlinepubs/9699919799/functions/flockfile.html

GCC's transformation that eliminates printf("") causes this requirement to be ignored; the calling thread is allowed to proceed even if a lock on stdout held by another thread should block printf.

The included test-case demonstrates the issue. It should deadlock, and indeed it does with -fno-builtin. But with the default settings, the program terminates normally.

Additional thoughts on the above POSIX requirement are on a blog post I wrote a while back, http://ewontfix.com/8/
Comment 1 Andreas Schwab 2014-07-08 07:17:12 UTC
Since printf("") does not need to obtain ownership of stdout there is no conflict here.  There is no requirement that it *must* obtain ownership even if not needed.
Comment 2 Richard Biener 2014-07-08 09:25:10 UTC
Comment 3 Rich Felker 2014-07-08 14:37:29 UTC
Yes it does need to obtain ownership of the file: to set the orientation to byte mode. This is required even by ISO C (without POSIX). A simpler test case:

printf("%d\n", fwide(stdout));
Comment 4 Rich Felker 2014-07-08 14:38:23 UTC
Sorry, that should be:

printf("%d\n", fwide(stdout, 0));
Comment 5 Rich Felker 2014-07-11 18:46:56 UTC
I reopened this, but now that I'm reporting a new symptom that's independent of the original symptom, I'm wondering whether I should file a separate bug report for it, or continue the issue under this original report. Which way is best? Both have the same fix (removing the invalid optimization or replacing it with a valid one), but the user-visible erroneous behaviors are distinct.