[analyzer] non-active union member accesses are not modeled

[tianxinghe]

For the following source code:

  union u
  {
      int First;
      int Second;
  };

  int main() {
    int data;
    data = 0;
    union u n;
    n.First = data;
    int result = (int)(100 / n.Second);
    return 0;
  }

In Clang's abstract syntax tree, the member variables First and Second of the union are considered as two variables without an alias relationship. However, after generating llvm ir, they are aliases.

Clang ast: The second binop assigns 0 to n.First, and because Clang's abstract syntax tree does not consider them aliases, CSA treats n.Second as unknown when processing the third binop.

llvm ir: Lines 17 and 19 operate on the same memory area.

I think this may be causing some accuracy issues on the union. @steakhal @haoNoQ @EugeneZelenko

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Tianxing He (tianxinghe)

For the following source code: union u { int First; int Second; }; int main() { int data; data = 0; union u n; n.First = data; int result = (int)(100 / n.Second); return 0; } In Clang's abstract syntax tree, the member variables First and Second of the union are considered as two variables without an alias relationship. However, after generating llvm ir, they are aliases. Clang ast:  The second binop assigns 0 to n.First, and because Clang's abstract syntax tree does not consider them aliases, CSA treats n.Second as unknown when processing the third binop. llvm ir:  Lines 17 and 19 operate on the same memory area. I think this may be causing some accuracy issues on the union. @steakhal @haoNoQ @EugeneZelenko

[tbaederr]

Writing to First and reading from Second is UB

[tianxinghe]

Writing to First and reading from Second is UB

Thank you! Can it cause pointer-related (e.g. npd/uaf/ml) problems in certain situations? I'd like to check it in csa.

[steakhal]

AFAIK unions blessed by clang and promises not to exploit that UB. CSA is not a verification tool, and unions there are basically not implemented as per how hardware works, and only the active member will be tracked.

[llvmbot]

@llvm/issue-subscribers-clang-static-analyzer

Author: Tianxing He (tianxinghe)

For the following source code: union u { int First; int Second; }; int main() { int data; data = 0; union u n; n.First = data; int result = (int)(100 / n.Second); return 0; } In Clang's abstract syntax tree, the member variables First and Second of the union are considered as two variables without an alias relationship. However, after generating llvm ir, they are aliases. Clang ast:  The second binop assigns 0 to n.First, and because Clang's abstract syntax tree does not consider them aliases, CSA treats n.Second as unknown when processing the third binop. llvm ir:  Lines 17 and 19 operate on the same memory area. I think this may be causing some accuracy issues on the union. @steakhal @haoNoQ @EugeneZelenko

[tianxinghe]

AFAIK unions blessed by clang and promises not to exploit that UB. CSA is not a verification tool, and unions there are basically not implemented as per how hardware works, and only the active member will be tracked.

I get it. Thank you！