From patchwork Tue Apr 4 19:29:19 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 746926 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3vyJvV1G1Lz9s83 for ; Wed, 5 Apr 2017 05:29:35 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="H0aoLsw4"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; q=dns; s=default; b=JZKXDW96+SBwmZaQwcTNpBGzIdTcy 9F5VX76Ag691ZF3GtPy+SwGAHhPhw9FOhxicGuihxORLg0/dWUR3IqWMW+wPFT3U BNHMDyZOG7u1CrdEcI+qD1H094phr1x4aVZ+VBJX5AwH82fbGS171+ohb3qdduTy JvgNcc21rpaBGQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; s=default; bh=ne2eBzV6ptJolpoKCwbYo5A3ZUk=; b=H0a oLsw4UuC+uY50QQ4YvLtPOCbRITvSQUHFsutLqzoDm7c1JlCxu/spm27WU+NQQz6 Ost65ZlYsk1+KMusMn9rLDZwt8Jd7vpK1o2Y3xPkhUyMBTy5AedXmLywsY21ecWo +cQvsf/5pI8kX4D+sjreldsm8QmUX4k/vgXVjxpI= Received: (qmail 87637 invoked by alias); 4 Apr 2017 19:29:25 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 87621 invoked by uid 89); 4 Apr 2017 19:29:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Apr 2017 19:29:22 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E77BB80F7D; Tue, 4 Apr 2017 19:29:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E77BB80F7D Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E77BB80F7D Received: from tucnak.zalov.cz (ovpn-116-72.ams2.redhat.com [10.36.116.72]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8EDC691327; Tue, 4 Apr 2017 19:29:22 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v34JTKHI027632; Tue, 4 Apr 2017 21:29:20 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v34JTJ3h027631; Tue, 4 Apr 2017 21:29:19 +0200 Date: Tue, 4 Apr 2017 21:29:19 +0200 From: Jakub Jelinek To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Avoid weird -Wpsabi warnings from NRV (PR target/80310) Message-ID: <20170404192919.GM17461@tucnak> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes Hi! When I've implemented vector -fsanitize=signed-integer-overflow, we've started to emit weirdo warnings on e.g. the following testcase. There is really no call with return value that changes ABI based on ISA options, there is just an internal fn call that is expanded completely inline (UBSAN_CHECK_*), but as the NRV pass calls aggregate_value_p even on those internal functions, we get the warning. The following patch keeps doing that for internal functions that have corresponding optab, those typically have a library counterpart, but for others that really don't have one and are always expanded inline avoids calling aggregate_value_p, we really can't NRV optimize those internal fns anyway. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2017-04-04 Jakub Jelinek PR target/80310 * tree-nvr.c: Include internal-fn.h. (pass_return_slot::execute): Ignore internal calls without direct optab. * c-c++-common/ubsan/pr80310.c: New test. Jakub --- gcc/tree-nrv.c.jj 2017-01-01 12:45:39.000000000 +0100 +++ gcc/tree-nrv.c 2017-04-04 15:51:54.864211786 +0200 @@ -28,6 +28,7 @@ along with GCC; see the file COPYING3. #include "tree-pretty-print.h" #include "gimple-iterator.h" #include "gimple-walk.h" +#include "internal-fn.h" /* This file implements return value optimizations for functions which return aggregate types. @@ -377,6 +378,12 @@ pass_return_slot::execute (function *fun if (stmt && gimple_call_lhs (stmt) && !gimple_call_return_slot_opt_p (stmt) + /* Ignore internal functions without direct optabs, + those are expanded specially and aggregate_value_p + on their result might result in undesirable warnings + with some backends. */ + && (!gimple_call_internal_p (stmt) + || direct_internal_fn_p (gimple_call_internal_fn (stmt))) && aggregate_value_p (TREE_TYPE (gimple_call_lhs (stmt)), gimple_call_fndecl (stmt))) { --- gcc/testsuite/c-c++-common/ubsan/pr80310.c.jj 2017-04-04 16:13:35.108407423 +0200 +++ gcc/testsuite/c-c++-common/ubsan/pr80310.c 2017-04-04 16:12:24.000000000 +0200 @@ -0,0 +1,12 @@ +/* PR target/80310 */ +/* { dg-do compile } */ +/* { dg-options "-O2 -fsanitize=signed-integer-overflow" } */ +/* { dg-additional-options "-mno-avx" { target i?86-*-* x86_64-*-* } } */ + +typedef int V __attribute__((vector_size (32))); + +void +foo (V *a, V *b, V *c) +{ + *a = *b + *c; /* { dg-bogus "AVX vector return without AVX enabled changes the ABI" "" { target i?86-*-* x86_64-*-* } } */ +}