https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117482
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|12.5 |16.0
--- Comment #2 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So path isolation sees this block:
;; basic block 5, loop depth 1
;; pred: 3
;; 4
# _15 = PHI <0B(3), first_11(4)>
# .MEM_16 = PHI <.MEM_23(3), .MEM_21(4)>
# .MEM_8 = VDEF <.MEM_16>
MEM[(struct foo *)_15 + -8B].a = 0;
i_9 = i_6 + 1;
if (count_5 > i_9)
goto <bb 3>; [89.00%]
else
goto <bb 6>; [11.00%]
;; succ: 3
;; 6
It's going to do its job and isolate bb5 across the two paths. Of particular
interest is the 3->5 path which will create:
;; basic block 6, loop depth 0
;; pred: 3
# _2 = PHI <0B(3)>
# .MEM_1 = PHI <.MEM_23(3)>
# .MEM_7 = VDEF <.MEM_1>
MEM[(struct foo *)_2 + -8B].a ={v} 0;
# .MEM_25 = VDEF <.MEM_7>
__builtin_trap ();
;; succ:
So working per design. The downside is with the path isolated we'll see the
previously hidden null pointer dereference which ultimately triggers the
stringop-overflow problem with the -8 offset.
The real problem is jump threading, or the lack thereof that would make that
problem block unreachable.
In DOM2 we see the key jump thread, but reject it because it would rotate the
loop (per design). By the time we get to DOM3 it's a bit more hidden and we'd
have to cascade the jump thread to make the key block unreachable.
I could "downgrade" the warning to a NULL dereference by simplifying the
address of the MEM store. But we'd still have a bogus warning and a regression
and it's not going to lead to any further simplification, so I'm not inclined
to make that change.
I don't see this getting fixed in gcc-15.
