On 7/3/21 4:13 AM, Bernhard Reutner-Fischer wrote:
On Fri, 2 Jul 2021 13:21:10 -0600 Martin Sebor via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:--- a/gcc/tree-ssa-uninit.c +++ b/gcc/tree-ssa-uninit.c @@ -228,9 +228,26 @@ check_defs (ao_ref *ref, tree vdef, void *data_) gimple *def_stmt = SSA_NAME_DEF_STMT (vdef);/* The ASAN_MARK intrinsic doesn't modify the variable. */- if (is_gimple_call (def_stmt) - && gimple_call_internal_p (def_stmt, IFN_ASAN_MARK)) - return false; + if (is_gimple_call (def_stmt)) + { + if (gimple_call_internal_p (def_stmt) + && gimple_call_internal_fn (def_stmt) == IFN_ASAN_MARK) + return false; + + if (tree fndecl = gimple_call_fndecl (def_stmt)) + { + /* Some sanitizer calls pass integer arguments to built-ins + that expect pointets. Avoid using gimple_call_builtin_p()pointers What happened to the suspicion that the fnspec attribs are allegedly not correct ( https://gcc.gnu.org/legacy-ml/gcc-patches/2018-02/msg00541.html )? Wouldn't that deal with this issue transparently if additionally the args were passed in correctly? Didn't follow *san closely though.
I didn't follow the 2018 thread either but the attribute changes to ASAN_MARK discussed in the patch above ended up reverted in r257625. In general, the fnspec (and other similar) attributes need to capture even the side-effects of the sanitizer functions that aren't observable by a program. Warnings only care about the strictly observable subset of those, so there isn't always a 1-to-1 correspondence. Martin
thanks,+ which fails for such calls. */ + if (DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL) + { + built_in_function fncode = DECL_FUNCTION_CODE (fndecl); + if (fncode > BEGIN_SANITIZER_BUILTINS + && fncode < END_SANITIZER_BUILTINS) + return false; + } + } + }
