From patchwork Thu May 22 08:06:36 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 351377 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 0CA7214008A for ; Thu, 22 May 2014 18:06:54 +1000 (EST) 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:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=yUlzzZNOJL2kcEA+S KH0Vl0QsqEc7cq09WyuTFaY3uDDKshrhc2Kl1enmJmN+GxHZnr3KGZeFPV0vQk6T 81VW5eRc5ung6qkuRpwK+lCUo6Y3maoXWeQZ+2iOYP9S96CweDYkRg7jnLrb6upg RV2XhaLI0ERu3FesyuK4eZYjTU= 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:references:mime-version :content-type:in-reply-to; s=default; bh=3KSOJblzQHfLjIJJvFKLmKS TRgA=; b=xAoNAzNhTr5so+WZw/57SvwUw3WZ/x1or8k7qGnktapXNf1b5YlCxB2 w5WzBh1WRAjRRdxlDRc7EOpYtJlD47RK+GaSRLoI01WHq8/81KvJ3BISeD+spGDR BCVo8506ZpdHNxtzK3Pj7fUpMOPbIcrwM/pc7eMuwvJaDTPdHo+o= Received: (qmail 1117 invoked by alias); 22 May 2014 08:06:46 -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 1105 invoked by uid 89); 22 May 2014 08:06:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 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; Thu, 22 May 2014 08:06:44 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4M86fNr016237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 May 2014 04:06:41 -0400 Received: from tucnak.zalov.cz (ovpn-116-17.ams2.redhat.com [10.36.116.17]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4M86dLw004039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 22 May 2014 04:06:41 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.8/8.14.7) with ESMTP id s4M86chP013146; Thu, 22 May 2014 10:06:38 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.8/8.14.8/Submit) id s4M86a3t013145; Thu, 22 May 2014 10:06:36 +0200 Date: Thu, 22 May 2014 10:06:36 +0200 From: Jakub Jelinek To: Marek Polacek Cc: "Joseph S. Myers" , GCC Patches Subject: [PATCH] Fix LTO decimal ICE Message-ID: <20140522080636.GY10386@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20140514113839.GE10386@tucnak.redhat.com> <20140515190929.GQ10386@tucnak.redhat.com> <20140516073654.GS10386@tucnak.redhat.com> <20140520203343.GF4561@redhat.com> <20140521125100.GB5135@redhat.com> <20140521144614.GT10386@tucnak.redhat.com> <20140521185203.GV10386@tucnak.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140521185203.GV10386@tucnak.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes On Wed, May 21, 2014 at 08:52:03PM +0200, Jakub Jelinek wrote: > FAIL: c-c++-common/ubsan/float-cast-overflow-10.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) > FAIL: c-c++-common/ubsan/float-cast-overflow-10.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) > FAIL: c-c++-common/ubsan/float-cast-overflow-10.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) > FAIL: c-c++-common/ubsan/float-cast-overflow-10.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) > FAIL: c-c++-common/ubsan/float-cast-overflow-7.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) > FAIL: c-c++-common/ubsan/float-cast-overflow-7.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) > FAIL: c-c++-common/ubsan/float-cast-overflow-7.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) > FAIL: c-c++-common/ubsan/float-cast-overflow-7.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) > > The LTO ICEs on float-cast-overflow-{7,10}.c seems to be related to decimal support: > /usr/src/gcc/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-7.c:147:1: internal compiler error: in decimal_to_decnumber, at dfp.c:138 > 0x116b4cb decimal_to_decnumber > ../../gcc/dfp.c:138 ... This bug is because we leave garbage in REAL_VALUE_TYPE padding bits, but then use memcmp on REAL_VALUE_TYPE objects. All other places use memset first to clear the padding bits, so I've committed this fix as obvious to trunk and 4.9 (without testcase, because I couldn't reproduce it on anything smaller than float-cast-overflow-{7,10}.c and those require further gcc patches. > The execution test FAILs for -m32 are: > ==4494==Sanitizer CHECK failed: ../../../../../libsanitizer/ubsan/ubsan_value.cc:98 ((0 && "unexpected floating point bit width")) != (0) (0, 0) This one can be fixed by handling 96 the same as 80 and 128, apparently even clang/llvm uses 96 on i?86 and crashes in libubsan the same way. Marek, can you please handle the LLVM bureaucracy? 2014-05-22 Jakub Jelinek * tree-streamer-in.c (unpack_ts_real_cst_value_fields): Make sure all padding bits in REAL_VALUE_TYPE are cleared. Jakub --- gcc/tree-streamer-in.c.jj 2014-05-20 16:37:05.000000000 +0200 +++ gcc/tree-streamer-in.c 2014-05-22 09:40:01.300112220 +0200 @@ -168,6 +168,9 @@ unpack_ts_real_cst_value_fields (struct REAL_VALUE_TYPE r; REAL_VALUE_TYPE *rp; + /* Clear all bits of the real value type so that we can later do + bitwise comparisons to see if two values are the same. */ + memset (&r, 0, sizeof r); r.cl = (unsigned) bp_unpack_value (bp, 2); r.decimal = (unsigned) bp_unpack_value (bp, 1); r.sign = (unsigned) bp_unpack_value (bp, 1);