Re: [PATCH] avoid -Wnonnull for printf format in dead code (PR 87041)

[Jeff Law <law at redhat dot com>]

On 11/15/18 12:06 PM, Martin Sebor wrote:
> 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.
Wrapping in this context refers to the dejagnu harness wrapping to
facilitate testing of remote and embedded targets where getting the real
exit status of an execution test is painful.

We wrap main, exit and abort.  The wrappers print info to stdout to
indicate exit status which can reliably be read by the harness.

At least that's my recollection of the wrapper bits.

jeff