From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BB18638930E9; Fri, 24 Apr 2020 08:59:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BB18638930E9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1587718790; bh=nd+kvPi/oz8Hns7tujgXGt/U4qxfObFmZupEAzmJFUo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SNSE39mYFFEstHGr6xff5RDWBmsT1DVkIRoDA/ADKlKTUKEH5fTtZRrG+ZnRfnwsu ABXEkiIfCW7qio7Pg/2jFye9/t1PkATJsVXX70T0BbQcOKrv+c+gZZpNX6/ftT/9nL yK34LAannVzpOE/0ykMm36PI1mOr7MPbmc3sHih0= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/94726] [10 Regression] ICE in uniform_vector_p, at tree.c:11214 since r10-2089-g21caa1a2649d586f Date: Fri, 24 Apr 2020 08:59:50 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: error-recovery, ice-on-invalid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc component Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 08:59:50 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94726 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jsm28 at gcc dot gnu.org, | |mpolacek at gcc dot gnu.org Component|middle-end |c --- Comment #2 from Richard Biener --- So we are building the VEC_PERM_EXPR at a point where 'a' has vector type b= ut then later via (gdb) bt #0 pop_scope () at ../../src/trunk/gcc/c/c-decl.c:1375 #1 0x0000000000976572 in pop_file_scope () at ../../src/trunk/gcc/c/c-decl.c:1456 #2 0x0000000000ac6667 in c_common_parse_file () at ../../src/trunk/gcc/c-family/c-opts.c:1191 #3 0x000000000132b2e0 in compile_file () at ../../src/trunk/gcc/toplev.c:4= 58 #4 0x000000000132e469 in do_compile () at ../../src/trunk/gcc/toplev.c:2273 we are patching up its type to an ARRAY_TYPE, resulting in invalid GENERIC for the formerly built tree. We should do no such thing here. Iff the FE wants to continue then it should simply remove the shadowed decl from the bindings and continue with the shadowing one. But here it seems to patch something up what wasn't "merged" during duplicate_decls so clearly something is "off". Oddly enough both b and b->shadowed refer to the same decl(?) and with vector type(!). I guess I don't really understand the purpose of the type "restore(?)" below: tree pop_scope (void) { ... /* It is possible for a decl not to have a name. We get here with b->id NULL in this case. */ if (b->id) { gcc_assert (I_SYMBOL_BINDING (b->id) =3D=3D b); I_SYMBOL_BINDING (b->id) =3D b->shadowed; if (b->shadowed && b->shadowed->u.type) TREE_TYPE (b->shadowed->decl) =3D b->shadowed->u.type; Martin, while we certainly can paper over this in the middle-end the issue clearly lies in the FE so I suggest to leave this to FE maintainers to sort out. I suppose similar issues might arise with double a; double foo () { return a / 3.0; }; int a =3D 0; where we should get a RDIV_EXPR with integer typed a. Hum, no, for some unknown reason _this_ testcase has 'a' still have double type and we do not run into the above code?! Ah, so in _this_ case we have two different decls in b->decl vs. b->shadowed->decl and b->shadowed->u.type is NULL. Err, for the vector case we get everything correct up to popping the vector a which somehow has itself registered as shadowed but with array type?! OK, so for the vector case we register two bindings for the same decl: #0 0x000000000097496f in bind (name=3D,= =20 decl=3D, scope=3D0x7ffff6c3b300, invisible= =3Dtrue,=20 nested=3Dfalse, locus=3D266848) at ../../src/trunk/gcc/c/c-decl.c:729 #1 0x000000000097e409 in pushdecl (x=3D) at ../../src/trunk/gcc/c/c-decl.c:3274 #2 0x0000000000982c4f in start_decl (declarator=3D0x3764510,=20 declspecs=3D0x3764450, initialized=3Dfalse, attributes=3D) at ../../src/trunk/gcc/c/c-decl.c:5177 and then #0 0x000000000097496f in bind (name=3D,= =20 decl=3D, scope=3D0x7ffff6d7e1e0, invisible= =3Dfalse,=20 nested=3Dtrue, locus=3D266848) at ../../src/trunk/gcc/c/c-decl.c:729 #1 0x000000000097e485 in pushdecl (x=3D) at ../../src/trunk/gcc/c/c-decl.c:3295 #2 0x0000000000982c4f in start_decl (declarator=3D0x3764510,=20 declspecs=3D0x3764450, initialized=3Dfalse, attributes=3D) at ../../src/trunk/gcc/c/c-decl.c:5177 and then update u.type of the shadowed here: /* Deduce size of array from initialization, if not already known. This is only needed for an initialization in the current scope; it must not be done for a file-scope initialization of a declaration with external linkage, redeclared in an inner scope with the outer declaration shadowed in an intermediate scope. */ if (TREE_CODE (type) =3D=3D ARRAY_TYPE && TYPE_DOMAIN (type) =3D=3D NULL_TREE && TREE_CODE (decl) !=3D TYPE_DECL && !(TREE_PUBLIC (decl) && current_scope !=3D file_scope)) { ... case 0: /* For global variables, update the copy of the type that exists in the binding. */ if (TREE_PUBLIC (decl)) { struct c_binding *b_ext =3D I_SYMBOL_BINDING (DECL_NAME (decl= )); while (b_ext && !B_IN_EXTERNAL_SCOPE (b_ext)) b_ext =3D b_ext->shadowed; if (b_ext && TREE_CODE (decl) =3D=3D TREE_CODE (b_ext->decl)) { if (b_ext->u.type && comptypes (b_ext->u.type, type)) b_ext->u.type =3D composite_type (b_ext->u.type, type); else b_ext->u.type =3D type; so the special case here is an array initializer. Indeed the following testcase exposes the bogus RDIV_EXPR: double a; double foo () { return a / 3.0; }; int a[] =3D { 0 }; but we're not consuming the bogus IL anywhere it would ICE.=