This is v3 of patch.  As pointed out by Alexander Monakov we can't rely 
on  alloca/memset since gcc can optimize this out or it can save the 
registers on the stack and the test will no longer make sense.

Now I use small asm code to deliberately overwrite TOC area on caller 
frame with zero. If the TOC is not restored by longjmp the test will 
fail and them I removed alloca/memset since it's no longer necessary for 
the test itself.

Em 25-05-2018 16:39, Rogerio Alves escreveu:
> 
> 
> Em 23-05-2018 11:24, Alexander Monakov escreveu:
>> On Wed, 23 May 2018, Rogerio Alves wrote:
>>> I don't think that alloca/memset should destroy the caller stack like is
>>> happening but, also I think we have to restore TOC to the caller 
>>> frame after
>>> the longjmp in that case also. I don't know if there's any other more 
>>> direct
>>> and robust ways to checking if TOC is correctly restored. I can't 
>>> think in
>>> anything easier than always restore.
>>
>> I'm not challenging the idea that "always restoring" is an appropriate 
>> fix.
>> My question was about *verifying* that TOC register is restored as it 
>> ought
>> to, i.e. how the testcase needs to work. Right now, the test uses my code
>> from Bugzilla that worked okay for demonstration purposes, but has 
>> issues as
>> a long-term testsuite addition:
>>
>> * it demonstrates the issue in a very intransparent fashion, relying on
>>    non-obvious interaction with alloca-memset part of the test;
>>
>> * when GCC manages to optimize out the alloca-memset part, the test
>>    will cease to work for the intended purpose.
>>
>> Alexander
>>
> 
> Ok. I understand your concern. Let me see if I can change this test to 
> check if the TOC was been restored.
> 
> Rogerio