[PATCH] tst-setcontext2: avoid bug from compiler optimization

[Chris Metcalf]

On 1/30/2017 6:57 AM, Florian Weimer wrote:
> On 01/27/2017 10:53 PM, Chris Metcalf wrote:
>> On 1/27/2017 4:30 PM, Florian Weimer wrote:
>>> On 01/27/2017 09:34 PM, Chris Metcalf wrote:
>>>> I'd like to commit the one-line patch below that just declares the
>>>> context
>>>> variables for test-setcontext2 as static.  I think the consensus is that
>>>> this is necessary,
>>>
>>> No, I think the test is supposed to work as-is; it is valid.
>>>
>>> So if this test is broken, it is a bug in the implementation of the
>>> context switching functions (as they are visible to applications, i.e.
>>> the fix might not be in the functions themselves, but adjusting their
>>> calling conventions, inhibiting GCC optimizations which make incorrect
>>> assumptions, etc.).
>>>
>>> If we do not have a fix right now, it is better to let the test keep
>>> failing (perhaps XFAIL it), rather than tweaking it so that it tests
>>> something else.
>>
>> We would be waiting on functionality from gcc that doesn't currently
>> exist, correct?  The current returns_twice semantics is insufficient to
>> describe the problem that we currently see with shared stack frames.
>
> I think this could still be a GCC regression in the handling of the returns_twice attribute, introduced when GCC started sharing stack slots more aggressively.  When returns_twice was initially implemented and documented, the question of stack slot reuse did not arise because GCC probably did not do it at all.
>
>> It's possible that returns_twice could be extended to also have the
>> semantics of "don't share my arguments' stack space with any other
>> variables in this function" pretty reasonably, but I don't want to try to
>> guess what will make most sense to the gcc folks.
>
> GCC already has this behavior on x86_64.  This could be an accident.
>
>> I can certainly let the test keep failing and just open a bug to reference
>> it and capture some of this discussion.
>
> Yes, would you please file a GCC bug with a preprocessed input file?

OK, so upgrading to a newer gcc seems to have fixed the problem for
me.  I was using 4.8.2, which has the problem, as does 4.8.5 (the
current 4.8 release).  However, I don't see it in 5.4, 6.3, or a gcc
tip build from earlier this month, so I think I will just upgrade my
gcc to 6.3 and not worry about it.

I'm not sure how aggressively the gcc folks backport these kinds of
things to earlier releases; if it seems like it would be helpful, I
suppose I could file a bug against 4.8 on tilegx specifically?

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com