https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
Jorn Wolfgang Rennecke changed:
What|Removed |Added
CC||amylaar at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
--- Comment #23 from vries at gcc dot gnu.org ---
I've made the test-case pr30957-1.c match the current compiler behaviour. The
test-case made sense for the time the committed code was working in the
compiler. It then regressed at some point, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
vries at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
mrs at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
m...@gcc.gnu.org changed:
What|Removed |Added
CC||mrs at gcc dot gnu.org
--- Comment #20
--- Comment #19 from ghazi at gcc dot gnu dot org 2010-03-30 17:16 ---
gcc.dg/pr30957-1.c still XFAILs on x86_64-unknown-linux-gnu
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from ghazi at gcc dot gnu dot org 2009-11-22 18:01 ---
Still fails
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2009-01
--- Comment #17 from ghazi at gcc dot gnu dot org 2009-01-17 02:56 ---
Reconfirming that gcc.dg/pr30957-1.c still XFAILs for me on x86_64.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from eres at il dot ibm dot com 2008-01-10 18:32 ---
This is because the test requires -fassociative-math for enabling the
variable-expansion as well as -fsigned-zeros for honor the sign of zero; but
they can not co-exist; also under -funsafe-math-optimizations.
--
h
--- Comment #15 from ubizjak at gmail dot com 2008-01-10 18:23 ---
(In reply to comment #13)
> This testcase has an execution failure on i686-pc-linux-gnu when using
> -fpic/-fPIC.
They also fail for non-pic compilations when the testcase _really_ executes the
test:
Index: testsuite/gc
--- Comment #14 from eres at il dot ibm dot com 2008-01-10 15:05 ---
-fassociative-math and -fsigned-zeros flags can not co-exist.
I guess this testcase should be removed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
--- Comment #13 from ghazi at gcc dot gnu dot org 2008-01-09 18:13 ---
This testcase has an execution failure on i686-pc-linux-gnu when using
-fpic/-fPIC.
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00366.html
--
ghazi at gcc dot gnu dot org changed:
What|Remove
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-05-09 07:27
---
This testcase (gcc.dg/pr30957-1.c) fails on spu-elf because spu-elf's float
almost always treat -0.0 as 0.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #11 from patchapp at dberlin dot org 2007-04-22 07:25 ---
Subject: Bug number PR30957
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01378.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #10 from eres at il dot ibm dot com 2007-02-26 18:34 ---
I think that the way -fnsafe-math-optimization violates ieee is important.
Introducing flag_signed_zeros, as you mensioned before, enforce
-fnsafe-math-optimization to honor signed zero. So I think MVE should honor
that
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-02-26 18:24 ---
Both -ffast-math and -funsafe-math-optimizations violate IEEE math specs so
this is an invalid bug. At one point -funsafe-math-optimizations used to not
honor signed zero but recently you have:
-flag_signed_zeros wi
--- Comment #8 from eres at il dot ibm dot com 2007-02-26 18:11 ---
MVE is enabled with -funsafe-math-optimizations as it changes the order of
summation. I think it should honor signed zero, which it does not in the
current implantation. I agree that -funsafe-math-optimizations is mor
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-26 17:57 ---
-ffast-math violates the IEEE standard in some cases so why is this option
being used to test an ieee math testcase?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #6 from eres at il dot ibm dot com 2007-02-26 15:01 ---
It seems that initializing the expansion with -zero (instead of +zero)
will solve this problem.
According IEEE standard if we have -
x += something; initializing x with -0 will cause x to get the sign of
something.
-0
--- Comment #5 from eres at il dot ibm dot com 2007-02-26 13:51 ---
The reason that this tescase fails is because the expansion is been initialized
with +0, which means that it's final result will be +0 and not -0 as expected.
expansion += d --> expansion += -0 --> +0
--
http://gc
--- Comment #4 from eres at il dot ibm dot com 2007-02-26 11:46 ---
Created an attachment (id=13113)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13113&action=view)
assembly file (PPC)
It seems that problem is in the initialization of the expansion
(which related to the sign of t
--- Comment #3 from eres at il dot ibm dot com 2007-02-25 14:52 ---
Created an attachment (id=13107)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13107&action=view)
testcase for MVE
Running the executable of the attached testcase (compiled with MVE)
succeeded. This looks strange
--- Comment #2 from eres at il dot ibm dot com 2007-02-25 14:50 ---
The execution fails also when acc is float (and not double)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
--- Comment #1 from eres at il dot ibm dot com 2007-02-25 11:33 ---
Created an attachment (id=13105)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13105&action=view)
RTL unroller's dump (compiled with -fvariable-expansion-in-unroller)
reg:DF 137 is the new variable expansion creat
25 matches
Mail list logo
