https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71157
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |manu at gcc dot gnu.org
--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
GCC does think that some path may dereference a null pointer since this block
survives until the end:
;; basic block 109, loop depth 0, count 0, freq 743, maybe hot
;; Invalid sum of incoming frequencies 5, should be 743
;; prev block 108, next block 1, flags: (NEW, REACHABLE)
;; pred: 59 [15.0%] (FALSE_VALUE,EXECUTABLE)
;; starting at line 7841
[pr71157.c:7841:12] # VUSE <.MEM_63>
_402 ={v} [pr71157.c:7841:12] MEM[(charD.7 *)0B];
# .MEM_388 = VDEF <.MEM_63>
# USE = nonlocal null { D.5991 } (nonlocal, escaped)
# CLB = nonlocal null { D.5991 } (nonlocal, escaped)
__builtin_trapD.1024 ();
;; succ:
this is because it thinks skip_space() may return NULL:
;; basic block 59, loop depth 2, count 0, freq 36, maybe hot
;; prev block 58, next block 60, flags: (NEW, REACHABLE)
;; pred: 57 [29.0%] (TRUE_VALUE,EXECUTABLE)
;; starting at line 7764, discriminator 2
[pr71157.c:7764:133] # PT = nonlocal escaped null
_200 = cp_11 + 12;
[pr71157.c:7764:122] # VUSE <.MEM_63>
# PT = nonlocal escaped null
# USE = nonlocal escaped null
cp_201 = skip_spacesD.5937 (_200);
[pr71157.c:7764:122] if (cp_201 != 0B)
goto <bb 61>;
else
goto <bb 109>;
;; succ: 61 [85.0%] (TRUE_VALUE,EXECUTABLE)
;; 109 [15.0%] (FALSE_VALUE,EXECUTABLE)
The location shown is just an artifact of merging expressions and not
preserving the right locations. The middle-end is not very smart at that, this
is why middle-end warnings are often confusing.
The testcase is too large for me to analyze further.
