https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94858
David Malcolm <dmalcolm at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2020-08-19 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> --- Thanks for filing this. Still affects trunk (my rewrite of r11-2694-g808f4dfeb3a95f50f15e71148e5c1067f90a126d didn't fix it). Seems to be an issue with state-merging; passing -fno-analyzer-state-merge eliminates the false positive. Immediately before the call to hashEmpty we have: cluster for: (*INIT_VAL(td_14(D))) ESCAPED key: {kind: direct, start: 0, size: 64, next: 64} value: ‘hashNx *’ {&HEAP_ALLOCATED_REGION(0)} key: {kind: direct, start: 96, size: 32, next: 128} value: ‘int’ {INIT_VAL(slots_15(D))} malloc: &HEAP_ALLOCATED_REGION(0): nonnull (‘index_17’) but afterwards (with state merging) we have: cluster for: (*INIT_VAL(td_14(D))) ESCAPED key: {kind: direct, start: 0, size: 64, next: 64} value: ‘hashNx *’ {UNKNOWN(hashNx *)} key: {kind: direct, start: 64, size: 32, next: 96} value: ‘int’ {(int)0} key: {kind: direct, start: 96, size: 32, next: 128} value: ‘int’ {UNKNOWN(int)} key: {kind: default, start: 0, size: 128, next: 128} value: ‘struct hashSt’ {UNKNOWN(struct hashSt)} so the pointer (first 64 bits) has somehow become UNKNOWN.