[Bug tree-optimization/109238] [13 Regression] tst-realloc.i:42:19: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free] in glibc tests

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109238

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #4)
> I think varying is the correct result tho?   the branch is in BB28, but bb
> 33 is a merge poi9nt again before bb 36, so we can't tell that it is
> anything but varying?
> 
> I see:
> 
> <bb 28> [local count: 428124]:
>   c_24 = realloc (p_17, 18446744073709551615);
>   if (c_24 != 0B)
>     goto <bb 29>; [99.96%]
>   else
>     goto <bb 33>; [0.04%]
>   
>   <bb 29> [local count: 427952]:
>   support_exit_failure_impl (1, "tst-realloc.c", 120, "realloc (p, -1)
> succeeded.");

^^^ this is noreturn

> 
>   <bb 30> [local count: 2741]:
>   _26 = (sizetype) i_25;
>   _27 = p_17 + _26;
>   _28 = *_27;
>   if (_28 != 255)
>     goto <bb 31>; [66.00%]
>   else
>     goto <bb 32>; [34.00%]
>   
>   <bb 31> [local count: 1809]:
>   
>   <bb 32> [local count: 2741]:
>   # ok_48 = PHI <ok_49(30), 0(31)>
>   i_29 = i_25 + 1;
>   
>   <bb 33> [local count: 2912]:         <<--  both sides of BB 28 branch
> merge here, so c_24 is varying again 
>   # i_25 = PHI <0(28), i_29(32)>
>   # ok_49 = PHI <1(28), ok_48(32)>
>   if (i_25 != 16)
>     goto <bb 30>; [94.12%]
>   else
>     goto <bb 34>; [5.88%]
>   
>   <bb 34> [local count: 171]:
>   # ok_30 = PHI <ok_49(33)>
>   if (ok_30 == 0)
>     goto <bb 35>; [0.04%]
>   else
>     goto <bb 36>; [99.96%]
>   
>   <bb 35> [local count: 0]:
>   support_exit_failure_impl (1, "tst-realloc.c", 132, "first 16 bytes were
> not correct after failed realloc");

likewise

>   <bb 36> [local count: 171]:
>   p_31 = realloc (p_17, 0);       <<-- This is dominated by bb 33 which
> merged the bb28 branch
> 
> During the cache dump the bit about
> CACHE: BB 32 DOM query for c_24, found [irange] unsigned char * VARYING at
> BB28
> CACHE: Range for DOM returns : [irange] unsigned char * VARYING
> CACHE: Range for DOM returns : [irange] unsigned char * VARYING
> 
> Is a bit of a misnomer I think, its dumping in the middle of a query and
> didnt show the fully updated value..  But I will look a bit closer at it..
> in theory that should have been non-zero, even tho I dont think it affects
> the result.

As said, the "error" calls are noreturn so the range should be [0,0] in BB36.