From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) by sourceware.org (Postfix) with ESMTPS id 42BC8388883C for ; Tue, 6 Jul 2021 15:41:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 42BC8388883C Received: by mail-ot1-x332.google.com with SMTP id l17-20020a9d6a910000b029048a51f0bc3cso10206731otq.13 for ; Tue, 06 Jul 2021 08:41:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vVDnHyesfTsLKBDxplxEYYng6BzmWbAhyOTrtP1DP/c=; b=Czu9gQGR0/nHNFDVRr9hymBgHNfvb5Qayct3g7mddwde1OT7Qzgc/Ie02iyJbko6l8 kkguQbUCCxw+Owpzs27Dy1R6SD3IQHtTJqGFDdnv7tSNHNeSwWJ1Rit+G3sYPLXDAwI3 4oRGbAu6biePOWRpP4cN+gRGtrDjl+gNMXSm3FN4TuPlu6nkzXiiqYRQ2+eXGhwsH6pY iWo4+Nn14Q8PT9ZH0knt2sO+LvojyaNBBqpvaxekziv7Z9XFL45ibhRiFypolAFrSKyp aOCLdTkWTGanYOhY/X25J4X41ccgScnTFM++HF1ObmVNk3/CF6kGJnRHfmbSur5l0rYe Szpw== X-Gm-Message-State: AOAM532/fvGmzmZ3ZP/4Tq0084BDRoqTX+arl5g2mUdZgK4J7JoMTiAL 50Z8LPF6Oz7GXRLuJGNsV0ZV1B8rstU= X-Google-Smtp-Source: ABdhPJyAmwSfoCok1bhNJ7nmx7BSYWB4qPNZeSAFDPddowJiaiDj/DRzxNW5D/HLgNpnqe0TjbBJ6A== X-Received: by 2002:a9d:5d14:: with SMTP id b20mr15731205oti.307.1625586061512; Tue, 06 Jul 2021 08:41:01 -0700 (PDT) Received: from [192.168.0.41] (75-166-102-22.hlrn.qwest.net. [75.166.102.22]) by smtp.gmail.com with ESMTPSA id q9sm3300673otk.18.2021.07.06.08.41.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jul 2021 08:41:01 -0700 (PDT) Subject: Re: [PATCH] handle sanitizer built-ins in -Wuninitialized (PR 101300) To: Bernhard Reutner-Fischer , Martin Sebor via Gcc-patches References: <44fabafb-9174-1739-9818-53122ef499f9@gmail.com> <20210703121316.5dd0a893@nbbrfq> From: Martin Sebor Message-ID: <73a485ae-e25d-e787-5411-859f3ba6327a@gmail.com> Date: Tue, 6 Jul 2021 09:41:00 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20210703121316.5dd0a893@nbbrfq> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 15:41:03 -0000 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 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; >> + } >> + } >> + } >>