From patchwork Fri Aug 24 16:50:42 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aldy Hernandez X-Patchwork-Id: 961953 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-484380-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="Qkuwa4n4"; dkim-atps=neutral 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 41xnNc3ZCKz9s47 for ; Sat, 25 Aug 2018 02:51:12 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to:cc :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=AEu+t6H0Uxm1T8oxNGyCf9xdnI0gLMxVvQleGfGFPTEtRjGupe SiDTWlTo+z2uNiDPYL6yioSFI0AJjJyEGZLcSNMBUFOSJ1j5I8UQZ/kigE7VjDOz qIrRvS8l7e58ErLC7j0opPs4jRBCn9vQdOX7TeYxgl8/kuF/mfUpuiE3I= 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:to:cc :from:subject:message-id:date:mime-version:content-type; s= default; bh=nwcZLsRX5econljTPROEnZqQqRE=; b=Qkuwa4n4Q40ToLnAhVe0 +uJ9YMuzUSIRTx5dvq3ZGXlxezmgTms/Hf56j//34TlC4OLk0/43uzHC0fAU4ZbG pJvVNQR6uevX8oIzRmNxw4OMhSZph9myK1B2u/AhTCuXwLlIyxYVGGhaHLNYU+gX pyrKSE9jklv3pE4BAqp57ZA= Received: (qmail 61863 invoked by alias); 24 Aug 2018 16:50:50 -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 61728 invoked by uid 89); 24 Aug 2018 16:50:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY, KAM_SHORT, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=Hx-languages-length:2140 X-HELO: mail-wm0-f48.google.com Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Aug 2018 16:50:47 +0000 Received: by mail-wm0-f48.google.com with SMTP id c14-v6so2175289wmb.4 for ; Fri, 24 Aug 2018 09:50:47 -0700 (PDT) Received: from abulafia.quesejoda.com ([188.119.240.39]) by smtp.gmail.com with ESMTPSA id l130-v6sm3065025wmd.16.2018.08.24.09.50.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Aug 2018 09:50:45 -0700 (PDT) To: gcc-patches Cc: Martin Sebor From: Aldy Hernandez Subject: [PR 87059] kludge over MIN_EXPR problem causing VRP failure in value ranges Message-ID: <98ec8da7-9d53-c82a-f483-bc42dc384952@redhat.com> Date: Fri, 24 Aug 2018 12:50:42 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 X-IsSubscribed: yes As discussed in the PR, the MIN_EXPR being passed to VRP has incompatible signs. I expect MIN_EXPR to have the same type for all arguments plus the MIN_EXPR node itself, but this is not the case. The culprit on PPC is expand_builtin_strncmp, but fixing it there causes other problems on x86-64 (see PR). I believe Martin Sebor had some questions related to the x86 fallout (https://gcc.gnu.org/ml/gcc/2018-08/msg00164.html). Since it seems this has been broken for a while, and I'd like to unbreak PPC without having to take my patch out, I suggest (for now) just passing the sign of the first argument as VRP had been doing all along (through int_const_binop): int_const_binop(): ... tree type = TREE_TYPE (arg1); ... if (TREE_CODE (arg1) == INTEGER_CST && TREE_CODE (arg2) == INTEGER_CST) { wide_int warg1 = wi::to_wide (arg1), res; wide_int warg2 = wi::to_wide (arg2, TYPE_PRECISION (type)); success = wide_int_binop (res, code, warg1, warg2, sign, &overflow); poly_res = res; } At some point later, if someone is sufficiently vexed by broken MIN_EXPR, we could fix it and the x86 fall out. OK pending tests? gcc/ PR 87059/tree-optimization * tree-vrp.c (extract_range_from_binary_expr_1): Pass sign of first argument to wide_int_range_min_max. diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index 735b3646e81..7373011d901 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -1566,6 +1566,15 @@ extract_range_from_binary_expr_1 (value_range *vr, wide_int vr1_min, vr1_max; extract_range_into_wide_ints (&vr0, sign, prec, vr0_min, vr0_max); extract_range_into_wide_ints (&vr1, sign, prec, vr1_min, vr1_max); + + /* FIXME: Currently the sign of MIN_EXPR and the sign of its + arguments are not always the same. Fixing the creators of + these faulty nodes caused other problems. For now use the + sign of the first argument as VRP was previously doing. See + PR87059. */ + if (vr0.min) + sign = TYPE_SIGN (TREE_TYPE (vr0.min)); + if (wide_int_range_min_max (wmin, wmax, code, sign, prec, vr0_min, vr0_max, vr1_min, vr1_max)) set_value_range (vr, VR_RANGE,