From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3FA3D384242E; Thu, 11 Mar 2021 08:09:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3FA3D384242E From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/99517] __builtin_convertvector with casts Date: Thu, 11 Mar 2021 08:09:09 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 10.2.1 X-Bugzilla-Keywords: wrong-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: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Thu, 11 Mar 2021 08:09:09 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99517 --- Comment #6 from Richard Biener --- (In reply to Jakub Jelinek from comment #4) > --- gcc/ipa-icf-gimple.c.jj 2021-01-04 10:25:38.752234741 +0100 > +++ gcc/ipa-icf-gimple.c 2021-03-10 15:02:06.287502784 +0100 > @@ -667,7 +667,7 @@ func_checker::compare_gimple_call (gcall > tree fntype1 =3D gimple_call_fntype (s1); > tree fntype2 =3D gimple_call_fntype (s2); >=20=20 > - /* For direct calls we verify that types are comopatible so if we matc= ed > + /* For direct calls we verify that types are compatible so if we match= ed > callees, callers must match, too. For indirect calls however verify > function type. */ > if (!gimple_call_fndecl (s1)) > @@ -703,6 +703,14 @@ func_checker::compare_gimple_call (gcall > t1 =3D gimple_get_lhs (s1); > t2 =3D gimple_get_lhs (s2); >=20=20 > + /* For internal calls, lhs types need to be verified, as neither fntype > nor > + callee comparisions can catch that. */ > + if (gimple_call_internal_p (s1) > + && t1 > + && t2 > + && !compatible_types_p (TREE_TYPE (t1), TREE_TYPE (t2))) > + return return_false_with_msg ("GIMPLE internal call LHS type mismatc= h"); > + > return compare_operand (t1, t2, get_operand_access_type (&map, t1)); > } >=20=20 >=20 > fixes this for me, working on the testcase for testsuite now. >=20 > Anyway, I'm a little bit worried that gimple_call_fntype isn't compared f= or > direct calls, gimple_call_fntype doesn't have to match the function type = of > gimple_call_fndecl. The comment says that we match that the fndecls definitions are equal, one could argue that it's undefined behavior if the same definition is invoked via two different gimple_call_fntype signatures and thus it's OK to just go ahead (I think actual arguments are also compared so it would collide there, too). > And also surprised that compare_ssa_name e.g. doesn't compare > SSA_NAME_OCCURS_IN_ABNORMAL_PHI or SSA_NAME_PTR_INFO or SSA_NAME_RANGE_IN= FO. > Maybe for the latter two we are fine if we only optimize away > __builtin_unreachable calls after IPA, but if we do it before, e.g. some > function could have if (cond) __builtin_unreachable (); assertions that E= VRP > would stick into SSA_NAME_RANGE_INFO and another function be the same exc= ept > without those assertions. If ICF merges the latter into the former and > calls the latter with arguments violating the assertions of the former, it > might be miscompiled. Hmm, yeah. I guess one could try to carefully craft such a testcase. For example non-null ranges can also be created from dead loads like foo (int *p) { *p; if (p !=3D 0) ... when you make sure to not run DCE before EVRP. Not sure if that's enough of a building-block to create a testcase.=