On x86 and x86_64, started between LAST_UPDATED: Fri Sep 23 22:29:25 UTC 2005 LAST_UPDATED: Sun Sep 25 08:26:26 UTC 2005 stage1/xgcc -Bstage1/ -B/home/guerby/work/gcc/install/install-20050925T102808/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -gnatpg -gnata -I- -I. -Iada -I/home/guerby/work/gcc/version-head/gcc/ada /home/guerby/work/gcc/version-head/gcc/ada/osint.adb -o ada/osint.o +===========================GNAT BUG DETECTED==============================+ | 4.1.0 20050925 (experimental) (x86_64-unknown-linux-gnu) GCC error: | | in build_int_cst_wide, at tree.c:795 | | Error detected at osint.adb:2822:12 |
Also on ia64. Broken by this change: 2005-09-24 Richard Henderson <rth@redhat.com> * c-common.c (handle_mode_attribute): When not modifying in place, create subtypes for enumerations. (sync_resolve_return): Use TYPE_MAIN_VARIANT. * gimplify.c (create_tmp_from_val): Likewise.
This looks like a latent bug in the Ada front-end as the only change to the middle-end would be the change to use TYPE_MAIN_VARIANT.
Indeed, just reverting just the gimplify.c change gets Ada in stage3 (still running on my machine).
By Andreas.
This works at -O on x86.
> This looks like a latent bug in the Ada front-end as the only change to the > middle-end would be the change to use TYPE_MAIN_VARIANT. No, it isn't, please investigate a minimum before writing such a statement. It's a latent consistency bug in the integer-share-limit stuff. In build_int_cst_wide, we're asserting that the type of shared constants attached to a type is precisely that type: t = TREE_VEC_ELT (TYPE_CACHED_VALUES (type), ix); if (t) { /* Make sure no one is clobbering the shared constant. */ gcc_assert (TREE_TYPE (t) == type); But in set_sizetype we're boldly copying TYPE_CACHED_VALUES between types: /* We do want to use bitsizetype's cache, as we will be replacing that type. */ TYPE_CACHED_VALUES (t) = TYPE_CACHED_VALUES (bitsizetype); TYPE_CACHED_VALUES_P (t) = TYPE_CACHED_VALUES_P (bitsizetype); Nathan, who is right here?
Subject: Re: [4.1 Regression] Ada bootstrap ICE in build_int_cst_wide, at tree.c:795 ebotcazou at gcc dot gnu dot org wrote: > In build_int_cst_wide, we're asserting that the type of shared constants > attached to a type is precisely that type: > > t = TREE_VEC_ELT (TYPE_CACHED_VALUES (type), ix); > if (t) > { > /* Make sure no one is clobbering the shared constant. */ > gcc_assert (TREE_TYPE (t) == type); > > But in set_sizetype we're boldly copying TYPE_CACHED_VALUES between types: > > /* We do want to use bitsizetype's cache, as we will be replacing that > type. */ > TYPE_CACHED_VALUES (t) = TYPE_CACHED_VALUES (bitsizetype); > TYPE_CACHED_VALUES_P (t) = TYPE_CACHED_VALUES_P (bitsizetype); > > > Nathan, who is right here? Both are correct. However it looks like some integer constant created before set_sizetype is called has not got its type updated correctly. The problem here is that we have to create some types before setting size_type, and in creating those types we need to set their size to some integral constant, and that integral constant has to have a type. That uses the stub sizetype type, which we overwrite further down set_sizetype. /* Replace our original stub sizetype. */ memcpy (sizetype, t, tree_size (sizetype)); TYPE_MAIN_VARIANT (sizetype) = sizetype; My guess is that we've already created some type variants of the stub type at that point, which is not what I expected. There should really be an gcc_assert (!TYPE_NEXT_VARIANT (sizetype) && !TYPE_NEXT_VARIANT (t)); just before the memcpy nathan
I'm testing Kenner's suggestion from http://gcc.gnu.org/ml/gcc/2005-09/msg00867.html ...
> The problem here is that we have to create some types before setting > size_type, and in creating those types we need to set their size to some > integral constant, and that integral constant has to have a type. That uses > the stub sizetype type, which we overwrite further down set_sizetype. > > /* Replace our original stub sizetype. */ > memcpy (sizetype, t, tree_size (sizetype)); > TYPE_MAIN_VARIANT (sizetype) = sizetype; OK, I totally missed that the types 't' are not supposed to escape from set_sizetype, right? > My guess is that we've already created some type variants of the stub type at > that point, which is not what I expected. There should really be an > gcc_assert (!TYPE_NEXT_VARIANT (sizetype) && !TYPE_NEXT_VARIANT (t)); > just before the memcpy The bug appears to be that the second type 't' does escape from set_sizetype because it is the main variant of bitsizetype, as Richard Kenner has found. Thanks for your feedback.
(In reply to comment #8) > I'm testing Kenner's suggestion from > http://gcc.gnu.org/ml/gcc/2005-09/msg00867.html ... Works for me on i686-linux Bootstrap finished and no additional ACATS failures.
Subject: Bug 24053 CVSROOT: /cvs/gcc Module name: gcc Changes by: ebotcazou@gcc.gnu.org 2005-09-29 22:11:14 Modified files: gcc : ChangeLog stor-layout.c Log message: PR middle-end/24053 * stor-layout.c (set_sizetype): Set TYPE_MAIN_VARIANT of bitsizetype. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10052&r2=2.10053 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/stor-layout.c.diff?cvsroot=gcc&r1=1.242&r2=1.243
Fix installed on behalf of Richard.