Bug#1015575: papi: ftbfs with LTO (link time optimization) enabled
On 19/07/2022 18.57, Matthias Klose wrote:
Package: src:papi
Version: 6.0.0~dfsg-2
instructions_testcode.c: Assembler messages:
instructions_testcode.c:13: Error: symbol `test_loop' is already defined
make[3]: *** [/tmp/ccsnxGXX.mk:2: /tmp/cc5pR6XG.ltrans0.ltrans.o] Error 1
Only three packages have such an error:
$ grep -rl 'is already defined' qa-logs.debian.net/
qa-logs.debian.net/2022/06/09/dpkglto/tarantool_2.6.0-1_unstable_dpkglto.log
qa-logs.debian.net/2022/06/09/dpkglto/squid_5.5-1.1_unstable_dpkglto.log
qa-logs.debian.net/2022/06/09/dpkglto/papi_6.0.0~dfsg-2_unstable_dpkglto.log
$ sgrep -r test_loop .
./src/validation_tests/instructions_testcode.c: "test_loop:\n"
./src/validation_tests/instructions_testcode.c: " jnz test_loop\n"
./src/validation_tests/instructions_testcode.c: "test_loop:\n"
./src/validation_tests/instructions_testcode.c: " bnz test_loop ! repeat until zero\n"
./src/validation_tests/instructions_testcode.c: " b test_loop\n"
./src/validation_tests/instructions_testcode.c: "test_loop:\n"
./src/validation_tests/instructions_testcode.c: " bne test_loop @ repeat till zero\n"
./src/validation_tests/instructions_testcode.c: "test_loop:\n"
./src/validation_tests/instructions_testcode.c: " bne test_loop // repeat till zero\n"
./src/validation_tests/branches_testcode.c: "test_loop:\n"
./src/validation_tests/branches_testcode.c: "\tjnz test_loop\n"
./src/validation_tests/branches_testcode.c: "test_loop:\n"
./src/validation_tests/branches_testcode.c: "\tbgt test_loop\n"
./src/validation_tests/branches_testcode.c: "test_loop:\n"
./src/validation_tests/branches_testcode.c: "\tbgt test_loop\n"
./src/validation_tests/branches_testcode.c: "test_loop:\n"
./src/validation_tests/branches_testcode.c: "\tbgt test_loop\n"
Hmm, this is not a "symbol" but a "label" in inline assembly.
While at a first glance on the grep output one might think
the label is reused in different inline assembly statements,
this is not the case - the loop is just implemented for
multiple architectures. So there should only be one
occurrence.
Do you have any idea what's going wrong here?
Andreas
BTW, the compiler is way better at error reporting than
the assembler here. The compiler would have told me the
location of the previous definition.
Reply to: