[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations

2006-10-21 Thread pinskia at gcc dot gnu dot org


--- Comment #8 from pinskia at gcc dot gnu dot org  2006-10-21 20:17 ---
*** Bug 29538 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||guillaume dot melquiond at
   ||ens-lyon dot fr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032



[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations

2005-12-19 Thread bagnara at cs dot unipr dot it


--- Comment #7 from bagnara at cs dot unipr dot it  2005-12-20 07:49 ---
I can confirm both problems (incorrect reordering and performance regression)
are present in GCC version 4.0.2 and version 4.2.0 20051209 (experimental).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032



[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations

2005-06-15 Thread vincent at vinc17 dot org

--- Additional Comments From vincent at vinc17 dot org  2005-06-15 16:49 
---
I think that this is just bug 323 (which is a real bug, not invalid). Version
3.4 added other regressions related to this bug (e.g. when one has function
calls), and this is not specific to the negate operation.

-- 
   What|Removed |Added

 CC||vincent at vinc17 dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032


[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations

2005-06-15 Thread vincent at vinc17 dot org

--- Additional Comments From vincent at vinc17 dot org  2005-06-15 17:08 
---
Oops, forget my comment. There is a bug, but 5.1.2.3#13 / 6.3.1.5#2 / 6.3.1.8#2
is not related to it if gcc does reduce the precision (due to the volatile,
that in fact prevents bug 323 from occurring here, right?).

Well, if gcc assumes more or less that all the types have the same range and
precision when doing optimization, then this could indeed be seen as bug 323. It
would be interesting to know how gcc deduced (wrongly) that it could do the
change concerning the neg.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032


[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations

2005-06-15 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-15 
17:26 ---
This is unrelated to 323.  The problem is that GCC does not implement a 
rounding modes correctly for 
C99 and therefor defines it as aways normal rounding mode and implements this 
transformation.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032


[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations

2005-04-16 Thread bagnara at cs dot unipr dot it

--- Additional Comments From bagnara at cs dot unipr dot it  2005-04-16 
12:27 ---
I can add the following:

1) the bug was not present in GCC 3.3.3 and is present since version 3.4.0, so I
think it qualifies as a regression;

2) the bug is also present in GCC 4.0.0 20050226 (prerelease), which compiles
the code even worse than done by GCC 3.4.3 (for whatever optimization level and
-march option one gives).

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032


[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations

2005-04-15 Thread bagnara at cs dot unipr dot it

--- Additional Comments From bagnara at cs dot unipr dot it  2005-04-15 
07:01 ---
Subject: Re:  GCC 3.4.3 wrongly reorders floating-point
 operations

pinskia at gcc dot gnu dot org wrote:
 Note neg just flips a bit so it is correct anyways
  and there is no loss of precession.

Can you please clarify what do you mean by correct?
I believe that:

1) The produced code is incorrect, since operations cannot
be reordered that way.  Notice that the compiler cannot
prove that the result is the same (in fact it is not,
in general, as it depends on the rounding direction).

2) A piece of standard C that, when correctly compiled,
performs a double to float conversion rounding up, when
the rounding mode is downward, or rounding down, when
the rounding mode is upward, no longer works when
compiled with GCC.  So the produced code is incorrect
not only from a language-lawyer point of view: I am
actually obtaining the wrong results.

All the best,

 Roberto Bagnara



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032


[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations

2005-04-14 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-14 
22:01 ---
Note neg just flips a bit so it is correct anyways and there is no loss of 
precession.

This also happens on ppc darwin, I don't know what to make of this.  A C person 
has to comment to say 
something about this.

-- 
   What|Removed |Added

  Component|c   |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032