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.
