Bug 61739

Summary:	__builtin_printf optimization conflicts with POSIX semantics
Product:	gcc	Reporter:	Rich Felker <bugdal>
Component:	c	Assignee:	Not yet assigned to anyone <unassigned>
Status:	UNCONFIRMED ---
Severity:	normal
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

Per POSIX,

"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

Agreed.

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("");
printf("%d\n", fwide(stdout));

Comment 4 Rich Felker 2014-07-08 14:38:23 UTC

Sorry, that should be:

printf("");
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.