]> git.ipfire.org Git - thirdparty/gcc.git/commit
c++: Further fix for get_member_function_from_ptrfunc [PR117259]
authorJakub Jelinek <jakub@redhat.com>
Thu, 24 Oct 2024 10:56:19 +0000 (12:56 +0200)
committerJakub Jelinek <jakub@gcc.gnu.org>
Thu, 24 Oct 2024 10:56:19 +0000 (12:56 +0200)
commitb25d3201b6338d9f71c64f524ca2974d9a1f38e8
tree2a0e03718a62cbfd4bec869ac5026382852b6be7
parent885143fa77599c44bfdd4e8e6b6987b7824db6ba
c++: Further fix for get_member_function_from_ptrfunc [PR117259]

The following testcase shows that the previous get_member_function_from_ptrfunc
changes weren't sufficient and we still have cases where
-fsanitize=undefined with pointers to member functions can cause wrong code
being generated and related false positive warnings.

The problem is that save_expr doesn't always create SAVE_EXPR, it can skip
some invariant arithmetics and in the end it could be really large
expressions which would be evaluated several times (and what is worse, with
-fsanitize=undefined those expressions then can have SAVE_EXPRs added to
their subparts for -fsanitize=bounds or -fsanitize=null or
-fsanitize=alignment instrumentation).  Tried to just build1 a SAVE_EXPR
+ add TREE_SIDE_EFFECTS instead of save_expr, but that doesn't work either,
because cp_fold happily optimizes those SAVE_EXPRs away when it sees
SAVE_EXPR operand is tree_invariant_p.

So, the following patch instead of using save_expr or building SAVE_EXPR
manually builds a TARGET_EXPR.  Both types are pointers, so it doesn't need
to be destroyed in any way, but TARGET_EXPR is what doesn't get optimized
away immediately.

2024-10-24  Jakub Jelinek  <jakub@redhat.com>

PR c++/117259
* typeck.cc (get_member_function_from_ptrfunc): Use force_target_expr
rather than save_expr for instance_ptr and function.  Don't call it
for TREE_CONSTANT.

* g++.dg/ubsan/pr117259.C: New test.
gcc/cp/typeck.cc
gcc/testsuite/g++.dg/ubsan/pr117259.C [new file with mode: 0644]