Hi Tom!
On Tue, 26 Feb 2019 12:28:34 +0100, Tom de Vries <tdevr...@suse.de> wrote:
> On 26-02-19 10:40, Thomas Schwinge wrote:
> > 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
With '-fdump-rtl-all' added, I see it appear in
'btest_lto.ltrans0.166r.expand':
./btest_lto.ltrans0.166r.expand: (symbol_ref:DI ("global.2528")
[flags 0x2] <var_decl 0xf7400170 global>)) [...]/libbacktrace/btest.c:399 -1
./btest_lto.ltrans0.166r.expand: (symbol_ref:DI ("global.2528")
[flags 0x2] <var_decl 0xf7400170 global>)) [...]/libbacktrace/btest.c:433 -1
./btest_lto.ltrans0.166r.expand: (symbol_ref:DI ("global.2528")
[flags 0x2] <var_decl 0xf7400170 global>)) [...]/libbacktrace/btest.c:435 -1
> How about:
> ...
> - int global;
> + static int global;
> ...
>
> Does that fix the failure?
No, that gets us "unexpected syminfo name got global.2479.2528 expected
global". ;-\
Grüße
Thomas
