From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31866 invoked by alias); 20 Sep 2017 12:21:35 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 31831 invoked by uid 89); 20 Sep 2017 12:21:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.3 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1476 X-HELO: mail-wr0-f172.google.com Received: from mail-wr0-f172.google.com (HELO mail-wr0-f172.google.com) (209.85.128.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Sep 2017 12:21:32 +0000 Received: by mail-wr0-f172.google.com with SMTP id u96so2008796wrb.6 for ; Wed, 20 Sep 2017 05:21:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:subject:date:message-id :user-agent:mime-version; bh=Ue2iY2uSwU1ueFyp9CJcZQ4QOtUTxfs33CHnlNAvk0Q=; b=jFPvYFsNbK/th+JWrMkx45r2IBaHJZql//Iw15kaCDfJzW0Ny/DuhY7wK9zKkST9+H VIkRRhUQ3wW5iEnD5xnUvYwZ4AVQTFXUCD6z5aTTgew1gW7rZwvXyBW3zihChGgYoER8 6AOOydZe6cAAsNPPjLdvBblfnpeoMXtRrmbUxTnlm2tFCXedhBiSrK32fSPVE9NtQ7Na DMJz6XCXLDIyCQg5siVob6Sc7/pgzeMoYrpy8rT6fYjH8diXk/HuuJBdkXkKIISgiC10 ZkNebnc/5Di9DMWPevcLcmsZTYO7lFSh0pUyh+4z5X1zD1mwiazaZmxOzs7ceZnbfSyc gtmw== X-Gm-Message-State: AHPjjUhABjlt9pW5M5NDQGLKinYqHR6Put1QIHUhX0hmGP7kXasv6+ZM uz9T87bA86iMg80Z43oWYoa4sWagpX0= X-Google-Smtp-Source: AOwi7QBxXQHXDb2NXYH2DhqcfN49jf4SQvVEVyhsosjudrpPw7eCYbqeiEBzA8Gh+AKyt8erKfAdhw== X-Received: by 10.223.154.120 with SMTP id z111mr4332657wrb.260.1505910090515; Wed, 20 Sep 2017 05:21:30 -0700 (PDT) Received: from localhost (92.40.248.127.threembb.co.uk. [92.40.248.127]) by smtp.gmail.com with ESMTPSA id o65sm1529508wmd.8.2017.09.20.05.21.29 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 20 Sep 2017 05:21:29 -0700 (PDT) From: Richard Sandiford To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Subject: SUBREG_PROMOTED_VAR_P handling in expand_direct_optab_fn Date: Wed, 20 Sep 2017 12:21:00 -0000 Message-ID: <877ewt1ry3.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-09/txt/msg01343.txt.bz2 This is needed by the later SVE LAST reductions, where an 8-bit or 16-bit result is zero- rather than sign-extended to 32 bits. I think it could occur in other situations too. Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linus-gnu. OK to install? Richard 2017-09-20 Richard Sandiford Alan Hayward David Sherwood gcc/ * internal-fn.c (expand_direct_optab_fn): Don't assign directly to a SUBREG_PROMOTED_VAR. Index: gcc/internal-fn.c =================================================================== --- gcc/internal-fn.c 2017-08-30 12:18:46.627041352 +0100 +++ gcc/internal-fn.c 2017-09-20 13:19:54.460290742 +0100 @@ -2606,7 +2606,15 @@ expand_direct_optab_fn (internal_fn fn, tree lhs = gimple_call_lhs (stmt); tree lhs_type = TREE_TYPE (lhs); rtx lhs_rtx = expand_expr (lhs, NULL_RTX, VOIDmode, EXPAND_WRITE); - create_output_operand (&ops[0], lhs_rtx, insn_data[icode].operand[0].mode); + + /* Do not assign directly to a promoted subreg, since there is no + guarantee that the instruction will leave the upper bits of the + register in the state required by SUBREG_PROMOTED_SIGN. */ + rtx dest = lhs_rtx; + if (GET_CODE (dest) == SUBREG && SUBREG_PROMOTED_VAR_P (dest)) + dest = NULL_RTX; + + create_output_operand (&ops[0], dest, insn_data[icode].operand[0].mode); for (unsigned int i = 0; i < nargs; ++i) {