This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH] Workaround extended precision decimal computations in float-cast-overflow-10.c (PR sanitizer/79341)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: gcc-patches at gcc dot gnu dot org
- Cc: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, Dominik Vogt <vogt at linux dot vnet dot ibm dot com>
- Date: Fri, 10 Feb 2017 20:58:05 +0100
- Subject: [PATCH] Workaround extended precision decimal computations in float-cast-overflow-10.c (PR sanitizer/79341)
- Authentication-results: sourceware.org; auth=none
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
Hi!
Apparently on s390x with -march=z10 and above at -O2, some of the _Decimal32
computations are performed in _Decimal64 precision. As the test intent
is to test the diagnostics on cast from floating point types to integral
types, the values we want to cast matter most (we want values that are
smallest or largest values already not representable in the integral type),
and already use volatile for the tem variable, so I think it is fine to
extend it.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2017-02-10 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/79341
* c-c++-common/ubsan/float-cast-overflow-8.c (TEST): Make min and max
variables volatile.
--- gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-8.c.jj 2015-10-29 09:14:30.000000000 +0100
+++ gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-8.c 2017-02-10 18:09:47.767251774 +0100
@@ -8,7 +8,7 @@
#define TEST(type1, type2) \
if (type1##_MIN) \
{ \
- type2 min = type1##_MIN; \
+ volatile type2 min = type1##_MIN; \
type2 add = -1.0; \
while (1) \
{ \
@@ -28,7 +28,7 @@
volatile type1 tem3 = cvt_##type1##_##type2 (-1.0f); \
} \
{ \
- type2 max = type1##_MAX; \
+ volatile type2 max = type1##_MAX; \
type2 add = 1.0; \
while (1) \
{ \
Jakub