From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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-Archive: List-Post: List-Help: Sender: gcc-patches-owner@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 08:06:00 -0000 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140521185203.GV10386@tucnak.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg01837.txt.bz2 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. --- 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); Jakub