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

[Torvald Riegel <triegel at redhat dot com>]

On Mon, 2017-01-30 at 12:57 +0100, 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.

I may be misremembering, but I think I had to add a returns_twice
attribute to the function call that starts a transaction (for GCC's
support for transactional memory).  This was motivated by seeing sharing
of stack slots, and adding the returns_twice was supposed to fix this
back then.  Which is to say that this sounds like a regression on GCC's
side to me, too.