public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Marek Polacek <polacek@redhat.com>
Cc: "Joseph S. Myers" <joseph@codesourcery.com>,
	       GCC Patches <gcc-patches@gcc.gnu.org>
Subject: [PATCH] Fix LTO decimal ICE
Date: Thu, 22 May 2014 08:06:00 -0000	[thread overview]
Message-ID: <20140522080636.GY10386@tucnak.redhat.com> (raw)
In-Reply-To: <20140521185203.GV10386@tucnak.redhat.com>

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  <jakub@redhat.com>

	* 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

  reply	other threads:[~2014-05-22  8:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13 17:08 [PATCH] Implement -fsanitize=float-cast-overflow Marek Polacek
2014-05-13 17:38 ` Jakub Jelinek
2014-05-13 18:11 ` Joseph S. Myers
2014-05-14 11:38   ` Jakub Jelinek
2014-05-14 17:37     ` Joseph S. Myers
2014-05-15 19:09       ` Jakub Jelinek
2014-05-15 21:29         ` Joseph S. Myers
2014-05-16  7:37           ` Jakub Jelinek
2014-05-16 15:54             ` Joseph S. Myers
2014-05-20 20:33             ` [PATCH] Implement -fsanitize=float-cast-overflow (take 2) Marek Polacek
2014-05-20 21:50               ` Joseph S. Myers
2014-05-21 12:51                 ` Marek Polacek
2014-05-21 14:46                   ` Jakub Jelinek
2014-05-21 18:52                     ` Jakub Jelinek
2014-05-22  8:06                       ` Jakub Jelinek [this message]
2014-05-21 17:50                   ` Joseph S. Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140522080636.GY10386@tucnak.redhat.com \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=polacek@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).