[PATCH] avoid -Wnonnull for printf format in dead code (PR 87041)
Martin Sebor
msebor@gmail.com
Thu Nov 15 19:06:00 GMT 2018
On 11/15/2018 02:39 AM, Matthew Malcomson wrote:
> On 02/11/18 09:54, Christophe Lyon wrote:
>> Hi,
>>
>> I've noticed failure on targets using newlib (aarch64-elf and arm-eabi):
>> FAIL: gcc.c-torture/execute/printf-2.c
>> FAIL: gcc.c-torture/execute/user-printf.c
>>
>> my gcc.log contains:
>> gcc.c-torture/execute/user-printf.c -O0 execution test (reason: TCL
>> LOOKUP CHANNEL exp5)
>> which is not very helpful
>>
>
> @Christophe
> Can I ask if your DejaGNU board setup has "needs_status_wrapper 1" for
> both of these boards?
>
> I believe this problem is caused by an interaction with the DejaGNU
> status wrapper.
>
> When the status wrapper is needed, DejaGNU looks at stdout for a line
> saying "*** EXIT code <number>" indicating what the status code was.
> When it doesn't find that line it assumes an exit code of 2.
> Without the status wrapper DejaGNU takes the return code from the
> program executed.
>
> Because these tests use "freopen ()" on stdout, the status wrapper fails
> to print to the IO channel DejaGNU is listening on, hence DejaGNU fails
> to find it's line, uses an exit code of 2, and fails the test.
>
>
> @Martin
> Would these tests still be valid having run freopen on stderr and using
> fprintf instead of printf?
> That makes the testcases pass for me.
The printf-2.c test specifically exercises the printf built-in,
i.e., not fprintf, so changing it to use fprintf would defeat
its purpose.
user-printf.c does something similar but for a user-defined
function with attribute format (printf).
The purpose of the tests is to verify that what they read from
the temporary file matches what they wrote (i.e,, that none of
the printf() or user_print() calls was incorrectly eliminated).
> If not we could add an
> { dg-require-effective-target unwrapped }
> directive in the testcases to stop the failure complaints.
I'm not familiar with this directive or really know what
a status wrapper is but as long as it doesn't change the I/O
the test does I think it should be fine.
Martin
More information about the Gcc-patches
mailing list