This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] support ggc hash_map and hash_set


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

tsaunders@mozilla.com wrote:
From: Trevor Saunders <tsaunders@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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]