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.

Reply via email to