public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-115298-4-Kssj3dUplE@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-115298-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115298 Richard Biener <rguenth at gcc dot gnu.org> 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 <rguenth at gcc dot gnu.org> --- Huh, I honestly have no idea how those targets would differ here ... I do see void h (char * s) { # PT = anything char * s_3(D) = s; char a[8]; <bb 2> : __builtin_memset (&a, 0, 8); __builtin_strncpy (&a, s_3(D), 8); # USE = anything # CLB = anything frob (&a); a ={v} {CLOBBER(eos)}; return; for nds32-sim but Deleted dead call: __builtin_memset (&a, 0, 8); void h (char * s) { # PT = nonlocal null char * s_3(D) = s; char a[8]; <bb 2> : __builtin_strncpy (&a, s_3(D), 8); # USE = nonlocal escaped null { D.2716 } (escaped) # CLB = nonlocal escaped null { D.2716 } (escaped) frob (&a); a ={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 = &NULL +a = 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 = &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 = &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 = &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 PTA ("split" ANYTHING somehow). Adding -fdelete-null-pointer-checks to the test makes it succeed also on nds32le-elf.
next prev parent reply other threads:[~2024-05-31 6:32 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-05-31 4:42 [Bug tree-optimization/115298] New: " law at gcc dot gnu.org 2024-05-31 6:32 ` rguenth at gcc dot gnu.org [this message] 2024-05-31 13:50 ` [Bug tree-optimization/115298] " law at gcc dot gnu.org 2024-05-31 15:04 ` rguenther at suse dot de 2024-05-31 17:37 ` law at gcc dot gnu.org 2024-05-31 17:37 ` law at gcc dot gnu.org 2024-06-03 7:43 ` [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 rguenther at suse dot de
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-115298-4-Kssj3dUplE@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).