https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #4 from Dominik Vogt ---
What happens in Cse1 is that the constant is propagated into the FLOAT_EXTEND
expression, resulting in
(float_expand:DD (const_double:SD -9223372036854775808))
which is eventually simplified using simplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #5 from Andreas Krebbel ---
the real_convert invocation has been added with:
commit 21be42575a11522f5b73d88da65f681711c335a0
Author: jakub
Date: Thu Mar 24 18:58:58 2011 +
PR debug/48204
* simplify-rtx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #6 from Dominik Vogt ---
This experimental patch fixes the problem:
diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index aa45973..2e67cff 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -1897,6 +1897,8 @@ simplify_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #7 from Dominik Vogt ---
(In reply to Andreas Krebbel from comment #5)
> Perhaps we have to do the real_convert unconditionally?!
The real_convert to "mode" is not enough. Before converting to the target
mode, the constant needs to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #8 from Jakub Jelinek ---
(In reply to Dominik Vogt from comment #4)
> What happens in Cse1 is that the constant is propagated into the
> FLOAT_EXTEND expression, resulting in
>
> (float_expand:DD (const_double:SD -9223372036854775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #9 from Dominik Vogt ---
(In reply to Jakub Jelinek from comment #8)
> This isn't truncation, but extension (SDmode to DDmode). I presume all
> SDmode values are representable in DDmode, so I don't see anything wrong on
> that.
But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #10 from Jakub Jelinek ---
Then the bug happened earlier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #12 from Jakub Jelinek ---
I see this is done in:
#0 decimal_from_integer (r=0x7fffd1a0) at ../../gcc/real.c:2328
#1 0x00d9b341 in real_from_integer (r=0x7fffd1a0, fmt=...,
val_in=..., sgn=SIGNED) at ../../gcc/real.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #11 from Dominik Vogt ---
Well, then, what is the place where the constant should be truncated to what
its mode can represent?
Right at the start of the Tree dumps there seems to be a difference between
float and _Decimal32. Float c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #13 from Dominik Vogt ---
From the "optimize" dump:
With float:
if (tem.1_3 != -9.223372036854775808e+18)
With _Decimal32:
if (tem.1_3 != -9223372036854775808)
This precision of the constant and the representation as floating p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #14 from Dominik Vogt ---
To me, it looks like the same bug does not happen with float just because there
is no need to convert this to 64 bit format for the comparison.
simplify_const_unary_operation is not executed - if it was the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #15 from Jakub Jelinek ---
(In reply to Dominik Vogt from comment #14)
> To me, it looks like the same bug does not happen with float just because
> there is no need to convert this to 64 bit format for the comparison.
> simplify_con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #16 from Dominik Vogt ---
> the REAL_CSTs already contain the right rounded values for their type
Is there a way to see these values in the dumps?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #17 from Jakub Jelinek ---
Well, the values are printed. As you say, -9223372036854775808 is not valid
_Decimal32 value, so it should never be printed for something that is
_Decimal32.
Actually trying:
_Decimal32
foo (void)
{
_D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #18 from Jakub Jelinek ---
Created attachment 40741
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40741&action=edit
gcc7-pr79487.patch
Untested fix. Seems at least from eyeballing the #c0 testcase (which is not
executable) th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #19 from Dominik Vogt ---
It fixes the local test case extracted from float-cast-overflow-10.c. The
patch probably should also add a test case; the one I have is very specific to
s390x; would something like the code in comment 17 wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #20 from Jakub Jelinek ---
(In reply to Dominik Vogt from comment #19)
> It fixes the local test case extracted from float-cast-overflow-10.c. The
> patch probably should also add a test case; the one I have is very specific
> to s39
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
Jakub Jelinek changed:
What|Removed |Added
Attachment #40741|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #22 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #21)
> Created attachment 40742 [details]
> gcc7-pr79487.patch
>
> So perhaps like this? Would be nice to test it also with -O0 and the old
> compiler.
Just tried t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #23 from Dominik Vogt ---
Same result on s390x (on a zEC12 using -with-arch=zEC12):
Without patch:
* -O0 -> PASS
* -O2 -> FAIL
With patch:
* -O0 -> PASS
* -O2 -> PASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #24 from Dominik Vogt ---
No regressions on s390x biarch, and s390 on a zEC12 configured with
-with-arch=zEC12. The "volatile"-patch to float-cast-overflow-8.c is no longer
necessary. Thanks for the help!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #25 from Jakub Jelinek ---
Author: jakub
Date: Wed Feb 15 12:19:53 2017
New Revision: 245477
URL: https://gcc.gnu.org/viewcvs?rev=245477&root=gcc&view=rev
Log:
PR target/79487
* real.c (real_from_integer): Call real_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
Dominik Vogt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
24 matches
Mail list logo
