On 26-02-19 10:40, Thomas Schwinge wrote:
> Hi Tom!
>
> On Mon, 25 Feb 2019 18:11:23 +0100, Tom de Vries <tdevr...@suse.de> wrote:
>> On 25-02-19 11:48, Thomas Schwinge wrote:
>>> On Fri, 8 Feb 2019 10:42:24 +0100, Tom de Vries <tdevr...@suse.de> wrote:
>>>> Add libbacktrace test-case using -flto.
>>>
>>> I'm seeing this one fail is some configurations, but only in the
>>> 'build-gcc/libbacktrace/btest_lto.log' variant:
>
>> Meaning, compiling libbacktrace using the host compiler, so it would be
>> useful to known which compiler that is.
>>
>> [ I've tried a gcc-4.8 and gcc-6 and gcc-7 as host compiler, and a
>> couple of CFLAGS settings (-O2, -O3) to reproduce this, but didn't manage. ]
>
> Years old:
>
> $ gcc --version
> gcc (Sourcery CodeBench 2014.05-45) 4.8.3 20140320 (prerelease)
> [...]
> $ ld --version
> GNU ld (Sourcery CodeBench 2014.05-45) 2.24.51.20140217
> [...]
>
> (It'll be fine for me if you just declare that unsupported.)
>
I see. The 4.8 I tried is a 4.8.5.
>>> test5: unexpected syminfo name got global.2537 expected global
>>> PASS: backtrace_full noinline
>>> PASS: backtrace_full inline
>>> PASS: backtrace_simple noinline
>>> PASS: backtrace_simple inline
>>> FAIL: backtrace_syminfo variable
>>> FAIL btest_lto (exit status: 1)
>>>
>>> I haven't looked yet which details about these GCC build configurations
>>> might be different/important; maybe you've got an idea already?
>
> I can reproduce this with '-O0' ("unexpected syminfo name got global.2528
> expected global", in that case). With '-O0 -fdump-tree-all
> -fdump-ipa-all -save-temps', the 'global.2528' name appears only in
> 'btest_lto.ltrans0.000i.cgraph', and 'btest_lto.ltrans0.s':
>
> ./btest_lto.ltrans0.000i.cgraph: References: global.2528/12
> (addr)state.2526/56 (read)callback_three.2389/64
> (addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20
> (read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20
> (read)stderr/20 (read)failures.2527/57 (read)failures.2527/57
> (write)failures.2527/57 (read)
> ./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
> ./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
> ./btest_lto.ltrans0.000i.cgraph: References: global.2528/12
> (addr)state.2526/56 (read)callback_three.2389/64
> (addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20
> (read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20
> (read)stderr/20 (read)failures.2527/57 (read)failures.2527/57
> (write)failures.2527/57 (read)
> ./btest_lto.ltrans0.000i.cgraph:global.2528/12 (global) @0xf7454118
> ./btest_lto.ltrans0.000i.cgraph: References: global.2528/12
> (addr)state.2526/56 (read)callback_three.2389/64
> (addr)error_callback_three.2384/65 (addr)stderr/20 (read)stderr/20
> (read)stderr/20 (read)global.2528/12 (addr)global.2528/12 (addr)stderr/20
> (read)stderr/20 (read)failures.2527/57 (read)failures.2527/57
> (write)failures.2527/57 (read)
> ./btest_lto.ltrans0.s: .type global.2528, @object
> ./btest_lto.ltrans0.s: .size global.2528, 4
> ./btest_lto.ltrans0.s:global.2528:
> ./btest_lto.ltrans0.s: movq $global.2528, -8(%rbp) #, addr
> ./btest_lto.ltrans0.s: movl $global.2528, %eax #, global.22
> ./btest_lto.ltrans0.s: movl $global.2528, %ecx #, global.23
> ./btest_lto.ltrans0.s: .quad global.2528
>
How about:
...
- int global;
+ static int global;
...
Does that fix the failure?
Thanks,
- Tom
