Following this, we're seeing ICEs in tests in gcc.dg/pch.exp and g++.dg/pch.exp, with cross-builds (hosted on x86_64) targetting bare metal AArch64 and ARM (aarch64-none-elf, aarch64_be-none-elf and arm-none-eabi; I haven't tested armeb-none-eabi; builds targeting linux are OK), for *release builds only*.
Affected tests: gcc.dg/pch.exp: all variants of ./except-1.h ./inline-3.h gcc.dg/pch/except-1.c gcc.dg/pch/inline-3.c g++.dg: all variants of ./array-1.H ./empty.H ./externc-1.H ./local-1.H ./pch.H ./static-1.H ./system-1.H ./system-2.H ./template-1.H ./uninst.H ./wchar-1.H (These then lead to failures of g++.dg/pch/{array-1,...}.C and corresponding assembly comparisons). Sample log: Executing on host: build/obj/gcc2/gcc/testsuite/g++/../../xg++ -Bbuild/obj/gcc2/gcc/testsuite/g++/../../ ./template-1.H -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -Ibuild/obj/gcc2/aarch64-none-elf/ilp32/libstdc++-v3/include/aarch64-none-elf -Ibuild/obj/gcc2/aarch64-none-elf/ilp32/libstdc++-v3/include -Isrc/gcc/libstdc++-v3/libsupc++ -Isrc/gcc/libstdc++-v3/include/backward -Isrc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -g -specs=aem-ve.specs -mabi=ilp32 -mcmodel=small -o template-1.H.gch (timeout = 300) spawn build/obj/gcc2/gcc/testsuite/g++/../../xg++ -Bbuild/obj/gcc2/gcc/testsuite/g++/../../ ./template-1.H -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -Ibuild/obj/gcc2/aarch64-none-elf/ilp32/libstdc++-v3/include/aarch64-none-elf -Ibuild/obj/gcc2/aarch64-none-elf/ilp32/libstdc++-v3/include -Isrc/gcc/libstdc++-v3/libsupc++ -Isrc/gcc/libstdc++-v3/include/backward -Isrc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -g -specs=aem-ve.specs -mabi=ilp32 -mcmodel=small -o template-1.H.gch ./template-1.H:5:2: internal compiler error: in relocate_ptrs, at ggc-common.c:435 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 output is: ./array-1.H:4:2: internal compiler error: in relocate_ptrs, at ggc-common.c:435 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. FAIL: ./array-1.H -g (internal compiler error) FAIL: ./array-1.H -g (test for excess errors) Excess errors: ./array-1.H:4:2: internal compiler error: in relocate_ptrs, at ggc-common.c:435 --Alan tsaund...@mozilla.com wrote:
From: Trevor Saunders <tsaund...@mozilla.com> Hi, There are still some issues to make this work really nicely, but this part is probably good enough its worth reviewing. For one thing you can't use ggc hash_map or set in front ends with some types or gengtype will decide to put the overloads of the marking routines it provides in a front end file instead of the one it choose before breaking other front ends. However that seems to be an unrelated issue you can trigger it without using hash_map/set, so we might as well solve it separetly. I had to have the entry marking functions for set deligate to the traits class because gcc < 4.9.1 issues clearly bogus errors if you inline the code from the traits implementation. We may well want to make map work the same way at some point to enable some of the special GTY attributes like if_marked, but it doesn't seem to be necessary right now. bootstrapped + regtested without regressions on x86_64-unknown-linux-gnu, ok? Trev