From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55500 invoked by alias); 1 Nov 2015 19:22:22 -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 55487 invoked by uid 89); 1 Nov 2015 19:22:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f173.google.com Received: from mail-yk0-f173.google.com (HELO mail-yk0-f173.google.com) (209.85.160.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 01 Nov 2015 19:22:20 +0000 Received: by ykdr3 with SMTP id r3so120991617ykd.1 for ; Sun, 01 Nov 2015 11:22:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5Kr11aB/8a94oN7gYC54Mn7vR09SLAgERmU9BY/HJ5g=; b=mU3C+iPYtHMgBvnpwnD5TATAoy7IuAzQ0uCXBtAv2utiaCGRGLdcgI3K5yNdy4DKNj 0lpL/oHXXo9bEJWQLnauKXbh8QUZp5VO+hk4YJiTCsToEcbHsAelQq0YCjFEDsH6m8zC YBRK19iZ4BFz5U8jP5aLKOaInpWFPOlgeLmQ9ExO4kay/Kp27CSocPeRiySoCt1y4QjH MD3ycumLeGMptFDLKMkN1mHABaf+6cb25YeypHhBhe5y7gLDwhWQGKSOjgWA2fpWEgnE nKO7jGrEHzmGIDlmHNdovoCtgOLHMuV+0VFqurHygjyTmD1xTAG8C1ENq7K0VzmogZG4 qkAQ== X-Gm-Message-State: ALoCoQnJmt1H3W1vDPGKAEC6BFvKWPCXwYD3s1BRL/pJ83RrxygaEHAwsdbNUjVE2H74FNJdIr65 MIME-Version: 1.0 X-Received: by 10.129.98.5 with SMTP id w5mr15259698ywb.285.1446405738338; Sun, 01 Nov 2015 11:22:18 -0800 (PST) Received: by 10.37.203.141 with HTTP; Sun, 1 Nov 2015 11:22:18 -0800 (PST) In-Reply-To: References: <561E4941.6030204@arm.com> Date: Sun, 01 Nov 2015 19:22:00 -0000 Message-ID: Subject: Re: [PATCH][ARM] PR target/67929 Tighten vfp3_const_double_for_bits checks From: Yvan Roux To: Ramana Radhakrishnan Cc: Kyrill Tkachov , GCC Patches , Ramana Radhakrishnan , Richard Earnshaw Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00007.txt.bz2 Hi Kyrill, On 27 October 2015 at 13:08, Ramana Radhakrishnan wrote: > On Wed, Oct 14, 2015 at 1:23 PM, Kyrill Tkachov wrote: >> Hi all, >> >> This patch fixes the referenced PR by rewriting the >> vfp3_const_double_for_bits function in arm.c >> The function is supposed to accept positive CONST_DOUBLE rtxes whose value >> is an exact power of 2 >> and whose log2 is between 1 and 32. That is values like 2.0, 4.0, 8.9, 16.0 >> etc... >> >> The current implementation seems to have been written under the assumption >> that exact_real_truncate returns >> false if the input value is not an exact integer, whereas in fact >> exact_real_truncate returns false if the >> truncation operation was not exact, which are different things. This would >> lead the function to accept any >> CONST_DOUBLE that can truncate to a power of 2, such as 4.9, 16.2 etc. >> >> In any case, I've rewritten this function and used the real_isinteger >> predicate to check if the real value >> is an exact integer. >> >> The testcase demonstrates the kind of wrong code that this patch addresses. >> >> This bug appears on GCC 5 and 4.9 as well, but due to the recent >> introduction of CONST_DOUBLE_REAL_VALUE >> this patch doesn't apply on those branches. I will soon post the >> backportable variant. >> >> Bootstrapped and tested on arm-none-linux-gnueabihf. >> >> Ok for trunk? > > > Thanks, this is OK for trunk and all release branches. > > Ramana > >> >> Thanks, >> Kyrill >> >> 2015-10-12 Kyrylo Tkachov >> >> PR target/67929 >> * config/arm/arm.c (vfp3_const_double_for_bits): Rewrite. >> * config/arm/constraints.md (Dp): Update callsite. >> * config/arm/predicates.md (const_double_vcvt_power_of_two): Likewise. >> >> 2015-10-12 Kyrylo Tkachov >> >> PR target/67929 >> * gcc.target/arm/pr67929_1.c: New test. This test fails when tested on hard-float targets, adding the following line to avoid testing it in such cases will fix the issue, but I wonder if there is a better dejaGNU directives sequence to do that. /* { dg-skip-if "avoid conflicting multilib options" { *-*-*eabihf } { "*" } { "" } } */ Cheers, Yvan