Re: nptl/tst-cleanupx4 fails with gcc-4.9.0 on i686

[Allan McRae <allan at archlinux dot org>]

On 17/06/14 22:59, Aurelien Jarno wrote:
> On Wed, Apr 23, 2014 at 08:21:59PM +1000, Allan McRae wrote:
>> With the gcc-4.9.0 release I get one new failure in nptl/tst-cleanupx4
>> (there are also some ULP failures on my system).
>>
>> The output in nptl/tst-cleanupx4.out is:
>>
>> test 0
>> clh (1)
>> clh (2)
>> clh (3)
>> test 1
>> clh (1)
>> clh (4)
>> clh (5)
>> clh (6)
>> test 2
>> clh (7)
>> clh (8)
>> global = 64, expected 120
>> test 3
>> clh (1)
>> clh (2)
>> clh (9)
>> clh (10)
>>
>>
>> Has anyone looked into this?
> 
> I have found that the issue is not there when building tst-cleanup4aux.c
> with -fexceptions. I also noted that this test is now ignored on ARM,
> with the following comment:
> 
> | # This test relies on compiling part of the binary with EH information,
> | # part without, and unwinding through.  The .ARM.exidx tables have
> | # start addresses for EH regions, but no end addresses.  Every
> | # region an exception needs to propogate through must have unwind
> | # information, or a previous function's unwind table may be used
> | # by mistake.
> | tests := $(filter-out tst-cleanupx4,$(tests))
> 
> So I do wonder what we should do on i386:
> 
> (a) Ignore the test on i386 similarly to ARM.
> 
> (b) Create tst-cleanupx4aux.c, which includes tst-cleanup4aux.c but is
> built using -fexceptions, and use it to link with tst-cleanupx4.
> 
> Any opinion?
> 

I'm not sure what the best approach is here.   Anyone else care to
comment?   We need this dealt with for 2.20.

Allan