From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 181C63870882; Mon, 3 Jun 2024 07:43:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 181C63870882 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1717400621; bh=pZCIYrzhPURo8j7HXmXJvh1uPW9BF1gp/BxUQe1yLb0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JGEjNtY9IGcGqGFXOqnRWfvQePPOmFkNDLuoUbkY+PtFrTj3CjVfQrLkrGVSIfOb3 4O4y4sI+VqxmcsttTq7oW1RD++RGpcbo9QpOyMpuG/mIFUFuC4+fB4B6jO7rBSm7Ix M/pokj9SduZCZmFJsdCXvAY1+WmuDPhhfmE0bn38= From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/115298] [15 Regression] Various targets failing DSE tests after recent changes due to default of -fno-fdelete-null-pointer-checks on those targets Date: Mon, 03 Jun 2024 07:43:39 +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: rguenther at suse dot de X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 15.0 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=3D115298 --- Comment #5 from rguenther at suse dot de --- On Fri, 31 May 2024, law at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D115298 >=20 > --- Comment #4 from Jeffrey A. Law --- > Agh. I was looking in the main config directory, not common/config. So = it all > makes sense now. >=20 > So if we go back to your original analysis, I think we can say things are > behaving correctly and we just need to adjust the testcase to either skip= on > these targets or add the flag. Yes. It's still bad now with a memset(p, 1) having the same effect on other archs. But it's still "correct" given in the caller one could do if (q =3D=3D (void *)0x0101010101010101) foo (p, q); so I don't really see how we can avoid this without magic hand-waving and muttering "unlikely", aka not what a compiler should do. Of course it now means that every time an INTEGER escapes which means always (a literal INTEGER would always have to be considered escaped) everything breaks down. So do we need to consider void bar () { *(int *)0xdeadbeef =3D 1; } int foo () { int x =3D 0; bar (); return x; } and consider carefully laid out stack so bar () clobbers 'x'? We do have to assume 0xdeadbeef is a valid address as otherwise UB. We do close bugs as INVALID that use the address of 'a' to get to 'b' for 'int a, b;' based on pointer arithmetic rules but we have bugs with conditional copy propagation wrecking things. That said, I'm somewhat considering to change INTEGER address behavior in points-to, making them _not_ alias any named object. Would that work in practice? We currently have ANYTHING =3D &ANYTHING ESCAPED =3D *ESCAPED ESCAPED =3D ESCAPED + UNKNOWN *ESCAPED =3D NONLOCAL NONLOCAL =3D &NONLOCAL NONLOCAL =3D &ESCAPED INTEGER =3D &ANYTHING and I'd change default INTEGER constraints to INTEGER =3D &INTEGER INTEGER =3D NONLOCAL 'INTEGER' are objects at literal addresses, they can initially refer to other 'INTEGER' objects and to global (named) objects. That excludes pointing to the stack top for example (we'd be back to ANYTHING if that's OK). Anyway, we'll see if any concrete performance issues arise from the fixed ANYTHING handling.=