[PATCH] pthread_cleanup_push macro generates warning when -Wclobbered is set

[Florian Weimer]

On 11/14/2017 11:06 PM, Joseph Myers wrote:
> On Tue, 14 Nov 2017, Florian Weimer wrote:
> 
>> On 11/14/2017 10:47 PM, Joseph Myers wrote:
>>> On Tue, 14 Nov 2017, Florian Weimer wrote:
>>>
>>>> Your test case already used an indirect call before the change with GCC 7.
>>>> I
>>>> think we should try to fix this in GCC.  GCC 4.8 used to generate a direct
>>>> call here, so this is a minor regression in the area of security
>>>> hardening.
>>>
>>> How do you suggest the compiler could tell that longjmp is only ever
>>> called from the same iteration of the outer loop as setjmp?
>>
>> I'm not sure if I understand your question correctly.
>>
>> The jump buffer does not even live as long as one iteration of the loop, so it
>> necessarily has to be the same iteration.
> 
> The "returns twice" information in GCC does not link the possible second
> return to the lifetime of a particular object.

But the control flow in pthread_cleanup_push is such that for both 
returns, local objects of limited scope are referenced immediately, so 
the compiler could infer that.

We could however take the position that C11 requires that once you call 
setjmp, the lifetime of all objects begins and ends and the beginning 
and end of the closest enclosing scope which has an object of variably 
modified type.  This would preclude unrolling loops and putting declared 
objects at different addresses, for example.  With this interpretation, 
the compiler cannot infer that the loop iteration is the same.  (GCC 
could perform the this transformation conservatively for any frame which 
has a call to a returns-twice function; no new attribute is needed.)

However, I still don't see how this matters here.  __cancel_routine and 
__cancel_arg are not addressable and not written to after initialization 
(and that's also true for the future argument in Paul's reproducer). 
This means that even with the POSIX interpretation if setjmp (where 
object lifetimes do not float outwards, and the address of the jump 
buffer matters), there is no wiggle room for the implementation to 
change the value of these variables.

Thanks,
Florian