Bug 21067 - Excessive optimization of floating point expression
Summary: Excessive optimization of floating point expression
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 3.4.3
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks: 16989
  Show dependency treegraph
 
Reported: 2005-04-17 07:23 UTC by bagnara
Modified: 2012-01-11 12:59 UTC (History)
2 users (show)

See Also:
Host: i686-pc-linux-gnu
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bagnara 2005-04-17 07:23:29 UTC
Compiling the following with GCC 3.4.3 (with "gcc -O2 -S file.c")

float mul2(float a, float b) {
  float v = -a * b;
  return -v;
}

produce the erroneous code

	pushl	%ebp
	movl	%esp, %ebp
	flds	8(%ebp)
	fmuls	12(%ebp)
	popl	%ebp
	ret

where the sign changes have been erroneously elided.
Notice that, depending on the rounding mode in effect,
this produces the wrong results.

Strangely enough, the code produced for

float div2(float a, float b) {
  float v = -a / b;
  return -v;
}

is instead correct.
Comment 1 Andrew Pinski 2005-04-17 07:34:12 UTC
Note GCC does not know about the rounding mode, in fact the round mode is only changeable in C99 
by the #pragma which GCC does not do right now and I thought that is a different PR already.
Comment 2 bagnara 2005-04-17 08:52:25 UTC
Subject: Re:  Excessive optimization of floating point
 expression

pinskia at gcc dot gnu dot org wrote:
> Note GCC does not know about the rounding mode,

This seems a good reason not to attempt optimizations
that only work with a given rounding mode.

> in fact the round mode is only changeable in C99 
> by the #pragma which GCC does not do right now and  I thought that is a different PR already.

I do not see the connection with the #pragma you are talking about.

IMHO, a program that uses the services of <fenv.h>, which is
covered by section 7.6 of the C99 standard, is a perfectly
legal C99 program, and thus deserves to be compiled correctly
as prescribed by that standard.
Am I missing something?
All the best,

     Roberto

Comment 3 Vincent Lefèvre 2005-06-15 16:42:49 UTC
Even without <fenv.h>, the function could be in a library called in a directed
rounding mode.

And one can change the rounding mode via a standard function in the glibc, no
need for a pragma.
Comment 4 roger 2006-05-20 15:14:52 UTC
This problem is fixed by specifying the -frounding-math command line option,
which informs the compiler that non-default rounding modes may be used.
With gcc-3.4, specifying this command line option disables this potentially
problematic transformation.

Strangely, on mainline, it looks like this transformation is no longer
triggered, which may now indicate a missed optimization regression with
(the default) -fno-rounding-math.  We should also catch the division case.
Comment 5 Vincent Lefèvre 2006-05-22 01:08:11 UTC
IMHO, -frounding-math should be the default, unless -ffast-math is given.
Comment 6 Richard Biener 2012-01-11 12:59:04 UTC
Invalid as per comment #4.