diff options
author | Jakub Jelinek <jakub@redhat.com> | 2022-05-27 11:40:42 +0200 |
---|---|---|
committer | Jakub Jelinek <jakub@redhat.com> | 2022-05-27 11:40:42 +0200 |
commit | e2f014fcefcd2ad56b31995329820bbd99072eae (patch) | |
tree | 902887f32908d417854e82e9c4b5cf2cfdeac7a0 /gcc/d/d-lang.cc | |
parent | 8255b49ed8ab37fd61d85bb48f97c618f05a8392 (diff) | |
download | gcc-e2f014fcefcd2ad56b31995329820bbd99072eae.zip gcc-e2f014fcefcd2ad56b31995329820bbd99072eae.tar.gz gcc-e2f014fcefcd2ad56b31995329820bbd99072eae.tar.bz2 |
fold-const: Fix up -fsanitize=null in C++ [PR105729]
The following testcase triggers a false positive UBSan binding a reference
to null diagnostics.
In the FE we instrument conversions from pointer to reference type
to diagnose at runtime if the operand of such a conversion is 0.
The problem is that a GENERIC folding folds
((const struct Bar *) ((const struct Foo *) this)->data) + (sizetype) range_check (x)
conversion to const struct Bar & by converting to that the first
operand of the POINTER_PLUS_EXPR. But that changes when the -fsanitize=null
binding to reference runtime check occurs. Without the optimization,
it is invoked on the result of the POINTER_PLUS_EXPR, and as range_check
call throws, that means it never triggers in the testcase.
With the optimization, it checks whether this->data is NULL and it is.
The following patch avoids that optimization during GENERIC folding when
-fsanitize=null is enabled and it is a cast from non-REFERENCE_TYPE to
REFERENCE_TYPE.
2022-05-27 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/105729
* fold-const.cc (fold_unary_loc): Don't optimize (X &) ((Y *) z + w)
to (X &) z + w if -fsanitize=null during GENERIC folding.
* g++.dg/ubsan/pr105729.C: New test.
Diffstat (limited to 'gcc/d/d-lang.cc')
0 files changed, 0 insertions, 0 deletions