On Tue, Nov 10, 2015 at 4:39 PM, Alan Lawrence <alan.lawre...@arm.com> wrote: > On 04/11/15 14:26, Ramana Radhakrishnan wrote: >> >> >> True and I've just been reading more of the backend - We could now start >> using blocks for constant pools as well. So let's do that. >> >> How does something like this look ? >> >> Tested on aarch64-none-elf - no regressions. >> >> 2015-11-04 Ramana Radhakrishnan <ramana.radhakrish...@arm.com> >> >> * config/aarch64/aarch64.c >> (aarch64_can_use_per_function_literal_pools_p): New. >> (aarch64_use_blocks_for_constant_p): Adjust declaration >> and use aarch64_can_use_function_literal_pools_p. >> (aarch64_select_rtx_section): Update. >> > > Since r229878, I've been seeing > > FAIL: gcc.dg/attr-weakref-1.c (test for excess errors) > UNRESOLVED: gcc.dg/attr-weakref-1.c compilation failed to produce executable > > (both previously passing) on aarch64-none-elf, aarch64_be-none-elf, and > aarch64-none-linux-gnu. Here's a log from aarch64_be-none-elf (the others > look similar): > > /work/alalaw01/build-aarch64_be-none-elf/obj/gcc2/gcc/xgcc > -B/work/alalaw01/build-aarch64_be-none-elf/obj/gcc2/gcc/ > /work/alalaw01/src/gcc/gcc/testsuite/gcc.dg/attr-weakref-1.c > -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 > /work/alalaw01/src/gcc/gcc/testsuite/gcc.dg/attr-weakref-1a.c > -specs=aem-validation.specs -lm -o ./attr-weakref-1.exe > /tmp/ccEfngi6.o:(.rodata.cst8+0x30): undefined reference to `wv12' > /tmp/ccEfngi6.o:(.rodata.cst8+0x38): undefined reference to `wv12' > /tmp/ccEfngi6.o:(.rodata.cst8+0x60): undefined reference to `wf12' > /tmp/ccEfngi6.o:(.rodata.cst8+0x68): undefined reference to `wf12' > collect2: error: ld returned 1 exit status > compiler exited with status 1 > output is: > /tmp/ccEfngi6.o:(.rodata.cst8+0x30): undefined reference to `wv12' > /tmp/ccEfngi6.o:(.rodata.cst8+0x38): undefined reference to `wv12' > /tmp/ccEfngi6.o:(.rodata.cst8+0x60): undefined reference to `wf12' > /tmp/ccEfngi6.o:(.rodata.cst8+0x68): undefined reference to `wf12' > collect2: error: ld returned 1 exit status > > FAIL: gcc.dg/attr-weakref-1.c (test for excess errors) >
Hmmm I'm surprised it failed in the first place as my testing didn't show it - I need to check on that. Nevertheless this fail has gone away in my testing with https://gcc.gnu.org/ml/gcc-cvs/2015-11/msg00453.html in a bootstrap and regression run on aarch64-none-linux-gnu. I see nothing triplet specific in the testcase here for it to fail differently. Is this something you see really with tip of trunk ? regards Ramana
