From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C68E33858032; Thu, 3 Aug 2023 12:22:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C68E33858032 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1691065378; bh=eZWHtn+kIqStNgDrer2uj0sEA4I1he3xVg1BLNh3b40=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qmpb+ng3/+5kUfcMbrtNXNfpkSrBP3esuXrwLMDjkK08OCKdeIqDIRpcyhhBQTD36 kbIaqRL8w9iETNXE/b3V07H5EJftzqeg86nMe6g3yEiZ0a0c0CoPosQxSMiQIOa7oT 93LkjOUjfY2mN93WLu6kuZ2bcvyaQ+oeukQTGae0= From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/110702] [12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2) Date: Thu, 03 Aug 2023 12:22:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.4 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110702 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:13dfb01e5c30c3bd09333ac79d6ff96a617fea67 commit r14-2951-g13dfb01e5c30c3bd09333ac79d6ff96a617fea67 Author: Richard Biener Date: Thu Aug 3 13:11:12 2023 +0200 tree-optimization/110702 - avoid zero-based memory references in IVOPTs Sometimes IVOPTs chooses a weird induction variable which downstream leads to issues. Most of the times we can fend those off during costing by rejecting the candidate but it looks like the address description costing synthesizes is different from what we end up generating so the following fixes things up at code generation time. Specifically we avoid the create_mem_ref_raw fallback which uses a literal zero address base with the actual base in index2. For the case in question we have the address type =3D unsigned long offset =3D 0 elements =3D { [0] =3D &e * -3, [1] =3D (sizetype) a.9_30 * 232, [2] =3D ivtmp.28_44 * 4 } from which we code generate the problematical _3 =3D MEM[(long int *)0B + ivtmp.36_9 + ivtmp.28_44 * 4]; which references the object at address zero. The patch below recognizes the fallback after the fact and transforms the TARGET_MEM_REF memory reference into a LEA for which this form isn't problematic: _24 =3D &MEM[(long int *)0B + ivtmp.36_34 + ivtmp.28_44 * 4]; _3 =3D *_24; hereby avoiding the correctness issue. We'd later conclude the program terminates at the null pointer dereference and make the function pure, miscompling the main function of the testcase. PR tree-optimization/110702 * tree-ssa-loop-ivopts.cc (rewrite_use_address): When we created a NULL pointer based access rewrite that to a LEA. * gcc.dg/torture/pr110702.c: New testcase.=