From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 96F943858C66; Fri, 31 May 2024 06:32:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 96F943858C66 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1717137149; bh=pEh2CcZCkreg2odNrLH6gEfxugvEs3lESZZtTp0dAxk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=x5wPYnpyrG7fu2vm3JiBUXx0I30UTn3C+Z7osxDZKRXM1vEiRBDTXuSC6qg/OA4wF +f+0xoe++QSzJY0NG9raBn2PHm/zD8MXCLdvT8/Fp8ALzmHVbhsiE6u3l/ridhGoQJ kGYllz19/XGIYGUUvk5kmCq5bmOH/iS23DISSMZs= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/115298] [15 Regression] Various targets failing DSE tests after recent changes Date: Fri, 31 May 2024 06:32:28 +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: 15.0 X-Bugzilla-Keywords: testsuite-fail X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 15.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on keywords everconfirmed target_milestone 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=3D115298 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2024-05-31 Keywords| |testsuite-fail Ever confirmed|0 |1 Target Milestone|--- |15.0 --- Comment #1 from Richard Biener --- Huh, I honestly have no idea how those targets would differ here ... I do see void h (char * s) { # PT =3D anything char * s_3(D) =3D s; char a[8]; : __builtin_memset (&a, 0, 8); __builtin_strncpy (&a, s_3(D), 8); # USE =3D anything # CLB =3D anything frob (&a); a =3D{v} {CLOBBER(eos)}; return; for nds32-sim but Deleted dead call: __builtin_memset (&a, 0, 8); void h (char * s) { # PT =3D nonlocal null char * s_3(D) =3D s; char a[8]; : __builtin_strncpy (&a, s_3(D), 8); # USE =3D nonlocal escaped null { D.2716 } (escaped) # CLB =3D nonlocal escaped null { D.2716 } (escaped) frob (&a); a =3D{v} {CLOBBER(eos)}; return; for x86-64. But then the points-to solutions should not make any difference for DSE in this case ... (the points-to difference is odd in the first place of course). So for the points-to difference this is caused by -a =3D &NULL +a =3D INTEGER which likely means a different default of -fno-delete-null-pointer-checks or ADDR_SPACE_ADDRESS_ZERO_VALID. That causes us to bring in what the object at (void *)0 points to, and that's ANYTHING since we do not track objects at constant addresses in any way, and those might alias all other objects. The question is more why we generate a =3D &NULL at all, but that= 's a pre-existing issue. We now simply handle all this correctly (we didn't before, with latent wrong-code). Ah, and the DSE effect then is obviously that now 'strncpy (&a, s_3(D),..)' reads from a since s_3(D) points to anything now (which includes 'a'), so we can no longer remove/trim an earlier store to 'a'. Ah, and the a =3D &NULL constraint is from the memset. Since we pass a to frob it escapes and everything escaped memory points to also escapes so anything escapes. So I'd say it works correctly now. There might be a missing indirection between NONLOCAL and ESCAPED. Since s =3D &NONLOCAL even when anything is in ESCAPED anything isn't NONLOCAL itself (well, but of course technically s can point to NULL as well - another latent incorrectness in PTA, we do not track NULL conservatively, a correctness mistake with ADDR_SPACE_ADDRESS_ZERO_VALID). Btw, changing the testcases to extern void frob (char *); void h (char *s) { char a[8]; __builtin_memset (a, 1, sizeof a); __builtin_strncpy (a, s, sizeof a); frob (a); } shows the same effect on x86_64 - suddenly 'a' points to ANYTHING (0x010101010101...), which makes 's' point to ANYTHING and DSE is gone. Confirmed for the testsuite regression. I don't see how this is a bug though. Maybe the stack object 'a' can never be at address zero? Or any "fixed" address? I'm not sure that such constraint can be modeled in P= TA ("split" ANYTHING somehow). Adding -fdelete-null-pointer-checks to the test makes it succeed also on nds32le-elf.=