Bug 61739 - __builtin_printf optimization conflicts with POSIX semantics
Summary: __builtin_printf optimization conflicts with POSIX semantics
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: unknown
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2014-07-08 00:37 UTC by Rich Felker
Modified: 2019-06-14 19:00 UTC (History)
0 users

See Also:
Known to work:
Known to fail:
Last reconfirmed:

test case (196 bytes, text/x-csrc)
2014-07-08 00:37 UTC, Rich Felker

Note You need to log in before you can comment on or make changes to this bug.
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.