From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29850 invoked by alias); 9 Sep 2014 14:40:48 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 29840 invoked by uid 89); 9 Sep 2014 14:40:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: service87.mimecast.com Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 Sep 2014 14:40:45 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Tue, 09 Sep 2014 15:40:42 +0100 Received: from [10.1.209.51] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Sep 2014 15:40:41 +0100 Message-ID: <540F1168.1030700@arm.com> Date: Tue, 09 Sep 2014 14:40:00 -0000 From: Alan Lawrence User-Agent: Thunderbird 2.0.0.24 (X11/20101213) MIME-Version: 1.0 To: "tsaunders@mozilla.com" CC: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH] support ggc hash_map and hash_set References: <1409622988-14529-1-git-send-email-tsaunders@mozilla.com> <540F10A6.5010807@arm.com> In-Reply-To: <540F10A6.5010807@arm.com> X-MC-Unique: 114090915404207801 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00730.txt.bz2 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=3Dnever -nostdinc++ -Ibuild/obj/gcc2/aarch64-none-elf/ilp32/libstdc++-v3/include/aarch64-none-e= lf -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=3D0 -O2 -g -specs=3Daem-ve.specs -mabi=3Dilp32 -mcmodel=3Dsmall -o template-1.H.gch (timeout =3D 300) spawn build/obj/gcc2/gcc/testsuite/g++/../../xg++ -Bbuild/obj/gcc2/gcc/testsuite/g++/../../ ./template-1.H -fno-diagnostics-show-caret -fdiagnostics-color=3Dnever -nostdinc++ -Ibuild/obj/gcc2/aarch64-none-elf/ilp32/libstdc++-v3/include/aarch64-none-e= lf -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=3D0 -O2 -g -specs=3Daem-ve.specs -mabi=3Dilp32 -mcmodel=3Dsmall -o template-1.H.gch ./template-1.H:5:2: internal compiler error: in relocate_ptrs, at ggc-commo= n.c:435 Please submit a full bug report, with preprocessed source if appropriate. See 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 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 > > Hi, > > There are still some issues to make this work really nicely, but this par= t is > probably good enough its worth reviewing. > > For one thing you can't use ggc hash_map or set in front ends with some t= ypes > 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 fr= om 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 >