[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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