Re: [PATCH 5/5] lto: Support #pragma GCC diagnostic [PR80922] [PR106823] [PR107936]

Hello,

The new gcc.dg/lto/pr80922 test appears to fail for all arm-none-eabi targets:

Testing gcc.dg/lto/pr80922-2, -O0 -flto -flto-partition=none -fuse-linker-plugin
doing compile
Executing on host: /build/r17-2833-g32657f29f91871/bin/arm-none-eabi-gcc   -mthumb -march=armv6s-m -mcpu=cortex-m0 -mfloat-abi=soft -mfpu=auto   -fdiagnostics-plain-output  -O0 -flto -flto-partition=none -fuse-linker-plugin  -O2 -Wfree-nonheap-object -c     -o c_lto_pr80922-2_0.o /build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-2_0.c    (timeout = 800)
spawn -ignore SIGHUP /build/r17-2833-g32657f29f91871/bin/arm-none-eabi-gcc -mthumb -march=armv6s-m -mcpu=cortex-m0 -mfloat-abi=soft -mfpu=auto -fdiagnostics-plain-output -O0 -flto -flto-partition=none -fuse-linker-plugin -O2 -Wfree-nonheap-object -c -o c_lto_pr80922-2_0.o /build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-2_0.c
pid is 703324 -703324
pid is -1
output is  status 0
PASS: gcc.dg/lto/pr80922-2 c_lto_pr80922-2_0.o assemble, -O0 -flto -flto-partition=none -fuse-linker-plugin
doing compile
Executing on host: /build/r17-2833-g32657f29f91871/bin/arm-none-eabi-gcc   -mthumb -march=armv6s-m -mcpu=cortex-m0 -mfloat-abi=soft -mfpu=auto   -fdiagnostics-plain-output  -O0 -flto -flto-partition=none -fuse-linker-plugin  -O2 -Wfree-nonheap-object -c     -o c_lto_pr80922-2_1.o /build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-2_1.c    (timeout = 800)
spawn -ignore SIGHUP /build/r17-2833-g32657f29f91871/bin/arm-none-eabi-gcc -mthumb -march=armv6s-m -mcpu=cortex-m0 -mfloat-abi=soft -mfpu=auto -fdiagnostics-plain-output -O0 -flto -flto-partition=none -fuse-linker-plugin -O2 -Wfree-nonheap-object -c -o c_lto_pr80922-2_1.o /build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-2_1.c
pid is 703370 -703370
pid is -1
output is  status 0
PASS: gcc.dg/lto/pr80922-2 c_lto_pr80922-2_1.o assemble, -O0 -flto -flto-partition=none -fuse-linker-plugin
doing compile
Executing on host: /build/r17-2833-g32657f29f91871/bin/arm-none-eabi-gcc   -mthumb -march=armv6s-m -mcpu=cortex-m0 -mfloat-abi=soft -mfpu=auto   -fdiagnostics-plain-output  -O0 -flto -flto-partition=none -fuse-linker-plugin  -O2 -Wfree-nonheap-object -c     -o c_lto_pr80922-2_2.o /build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-2_2.c    (timeout = 800)
spawn -ignore SIGHUP /build/r17-2833-g32657f29f91871/bin/arm-none-eabi-gcc -mthumb -march=armv6s-m -mcpu=cortex-m0 -mfloat-abi=soft -mfpu=auto -fdiagnostics-plain-output -O0 -flto -flto-partition=none -fuse-linker-plugin -O2 -Wfree-nonheap-object -c -o c_lto_pr80922-2_2.o /build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-2_2.c
pid is 703406 -703406
pid is -1
output is  status 0
PASS: gcc.dg/lto/pr80922-2 c_lto_pr80922-2_2.o assemble, -O0 -flto -flto-partition=none -fuse-linker-plugin
doing compile
Executing on host: /build/r17-2833-g32657f29f91871/bin/arm-none-eabi-gcc  c_lto_pr80922-2_1.o c_lto_pr80922-2_2.o  -mthumb -march=armv6s-m -mcpu=cortex-m0 -mfloat-abi=soft -mfpu=auto   -dumpbase "" -fdiagnostics-plain-output  -r       --specs=rdimon.specs -Wl,--start-group -lc -lm -Wl,--end-group --specs=nosys.specs -Wl,--allow-multiple-definition -Wl,-u,_isatty,-u,_fstat  -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -Wl,gcc_tg.o    -o c_lto_pr80922-2.o    (timeout = 800)
spawn -ignore SIGHUP /build/r17-2833-g32657f29f91871/bin/arm-none-eabi-gcc c_lto_pr80922-2_1.o c_lto_pr80922-2_2.o -mthumb -march=armv6s-m -mcpu=cortex-m0 -mfloat-abi=soft -mfpu=auto -dumpbase  -fdiagnostics-plain-output -r --specs=rdimon.specs -Wl,--start-group -lc -lm -Wl,--end-group --specs=nosys.specs -Wl,--allow-multiple-definition -Wl,-u,_isatty,-u,_fstat -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -Wl,gcc_tg.o -o c_lto_pr80922-2.o
pid is 703440 -703440
/build/r17-2833-g32657f29f91871/arm-none-eabi/bin/ld: warning: incremental linking of LTO and non-LTO objects; using -flinker-output=nolto-rel which will bypass whole program optimization
In function 'myfree2',
     inlined from 'main' at /build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-1_1.c:8:3:
/build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-2_1.c:5:3: warning: '__builtin_free' called on unallocated object 'a' [-Wfree-nonheap-object]
/build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-1_1.c: In function 'main':
/build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-1_1.c:4:13: note: declared here
In function 'myfree2',
     inlined from 'main' at /build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-1_1.c:8:3:
/build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-2_1.c:10:3: warning: '__builtin_free' called on unallocated object 'c' [-Wfree-nonheap-object]
/build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-1_1.c: In function 'main':
/build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-1_1.c:4:19: note: declared here
pid is -1
output is /build/r17-2833-g32657f29f91871/arm-none-eabi/bin/ld: warning: incremental linking of LTO and non-LTO objects; using -flinker-output=nolto-rel which will bypass whole program optimization
In function 'myfree2',
     inlined from 'main' at /build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-1_1.c:8:3:
/build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-2_1.c:5:3: warning: '__builtin_free' called on unallocated object 'a' [-Wfree-nonheap-object]
/build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-1_1.c: In function 'main':
/build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-1_1.c:4:13: note: declared here
In function 'myfree2',
     inlined from 'main' at /build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-1_1.c:8:3:
/build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-2_1.c:10:3: warning: '__builtin_free' called on unallocated object 'c' [-Wfree-nonheap-object]
/build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-1_1.c: In function 'main':
/build/gcc_src/gcc/testsuite/gcc.dg/lto/pr80922-1_1.c:4:19: note: declared here
  status 0
FAIL: gcc.dg/lto/pr80922-2 c_lto_pr80922-2_2.o-c_lto_pr80922-2_2.o link, incr-link
doing compile
Executing on host: /build/r17-2833-g32657f29f91871/bin/arm-none-eabi-gcc  c_lto_pr80922-2_0.o c_lto_pr80922-2.o  -mthumb -march=armv6s-m -mcpu=cortex-m0 -mfloat-abi=soft -mfpu=auto   -dumpbase "" -fdiagnostics-plain-output  -O0 -flto -flto-partition=none -fuse-linker-plugin -O2 -Wfree-nonheap-object       --specs=rdimon.specs -Wl,--start-group -lc -lm -Wl,--end-group --specs=nosys.specs -Wl,--allow-multiple-definition -Wl,-u,_isatty,-u,_fstat  -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -Wl,gcc_tg.o   -T qemu.ld -o gcc-dg-lto-pr80922-2-01.exe    (timeout = 800)
spawn -ignore SIGHUP /build/r17-2833-g32657f29f91871/bin/arm-none-eabi-gcc c_lto_pr80922-2_0.o c_lto_pr80922-2.o -mthumb -march=armv6s-m -mcpu=cortex-m0 -mfloat-abi=soft -mfpu=auto -dumpbase  -fdiagnostics-plain-output -O0 -flto -flto-partition=none -fuse-linker-plugin -O2 -Wfree-nonheap-object --specs=rdimon.specs -Wl,--start-group -lc -lm -Wl,--end-group --specs=nosys.specs -Wl,--allow-multiple-definition -Wl,-u,_isatty,-u,_fstat -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -Wl,gcc_tg.o -T qemu.ld -o gcc-dg-lto-pr80922-2-01.exe
pid is 703533 -703533
pid is -1
output is  status 0
FAIL: gcc.dg/lto/pr80922-2  (test for LTO warnings, pr80922-2_0.c line 10 -O0 -flto -flto-partition=none -fuse-linker-plugin)
FAIL: gcc.dg/lto/pr80922-2  (test for LTO warnings, pr80922-2_0.c line 15 -O0 -flto -flto-partition=none -fuse-linker-plugin)
FAIL: gcc.dg/lto/pr80922-2  (test for LTO warnings, pr80922-2_1.c line 5 -O0 -flto -flto-partition=none -fuse-linker-plugin)
FAIL: gcc.dg/lto/pr80922-2  (test for LTO warnings, pr80922-2_1.c line 10 -O0 -flto -flto-partition=none -fuse-linker-plugin)
PASS: gcc.dg/lto/pr80922-2 c_lto_pr80922-2_0.o-c_lto_pr80922-2.o link, -O0 -flto -flto-partition=none -fuse-linker-plugin


Kind regards,
Torbjörn

On 2026-07-09 03:17, Lewis Hyatt wrote:
>> Ok, this is looks reasonable.
>>
>> As possible (future) improvement, would it not be better to output one hash
>> per symtab_node?
>> Not sure whether locations can appear somewhere without being an
>> undividable part of symtab_node/toplevel_node.
>>
> 
> During WPA, function sections get copied from the input to the output
> files without being read, so I thought it might be safer to guarantee
> each section is individually OK on its own as well. But I'm happy to
> look into this further sometime. Perhaps also a single SHA1 hash of
> all relevant maps for each of the sections containing locations would
> be more efficient too.
> 
> Thank you both for reviewing these. I am planning to commit the
> patches this weekend absent any other comments.
> 
> -Lewis