Richard Sandiford <rdsandif...@googlemail.com> writes:
> "Steve Ellcey " <sell...@mips.com> writes:
>> diff --git a/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c
>> b/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c
>> index 8ffd4d8..53c9e4f 100644
>> --- a/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c
>> +++ b/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c
>> @@ -1,6 +1,7 @@
>> /* Check that sdata-accesses are applied regardless of size or ABI. */
>> /* { dg-options -mexplicit-relocs } */
>> /* { dg-do compile { target mips*-*-elf* } } */
>> +/* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } { "" } } */
>>
>> struct s { int x[4]; };
>> struct s my_struct __attribute__((__section__(".sdata")));
>
> The other tests that hit this problem have -ffat-lto-objects in the
> dg-options line, so we might as well do the same here for consistency.
> That's OK if it works.
Sorry, scratch that. I'd missed that it wasn't in gcc.target/mips
(although arguably it should be).
This sort of thing should usually be handled automatically by
scan-assembler, and is for me:
/foo/gcc/xgcc -B/foo/gcc/ /bar/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c
-fno-diagnostics-show-caret -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
-mexplicit-relocs -ffat-lto-objects -S -isystem
/foo/mipsisa64-elf/soft-float/newlib/targ-include -isystem
/bar/newlib/libc/include -EB -msoft-float -o mips-sdata-1.s
So the test passes all variations here. I wonder what's different in
your case?
Richard
