[Bug middle-end/55771] Negation and type conversion incorrectly exchanged

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55771

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #13 from Andrew Pinski  ---
Fixed for GCC 4.9.0+ by r0-124269 which references this PR but for some reason
it does not show up in the bugzilla.

[Bug middle-end/55771] Negation and type conversion incorrectly exchanged

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #12 from Michael Matz  ---
*** Bug 57886 has been marked as a duplicate of this bug. ***

[Bug middle-end/55771] Negation and type conversion incorrectly exchanged

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #11 from Jakub Jelinek  2012-12-21 
14:08:19 UTC ---

I'd keep it for FLOAT_TYPE_P -> FLOAT_TYPE_P for now, perhaps premature, but

clearly we don't have any GIMPLE optimization that would do the job (or RTL).

int

foo (double x)

{

  float a = x;

  double b = -x;

  float c = -a;

  float d = b;

  return c == d;

}



int

bar (double x)

{

  return (-(float) x) == ((float) -x);

}



with -O2 -ffast-math, bar is folded into return 1;, foo is quite a lot of code,

although both are equivalent.  If the NEGATE_EXPR case is just removed, then

bar isn't optimized at all either.

[Bug middle-end/55771] Negation and type conversion incorrectly exchanged

[jakub at gcc dot gnu.org]

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



--- Comment #10 from Jakub Jelinek  2012-12-21 
13:59:29 UTC ---

Yeah, I wonder if that transformation wasn't meant to be guarded by also

FLOAT_TYPE_P (itype), comparing TYPE_PRECISION of a floating type with say

integer type or vector type etc. looks fishy.

[Bug middle-end/55771] Negation and type conversion incorrectly exchanged

[rguenth at gcc dot gnu.org]

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



--- Comment #9 from Richard Biener  2012-12-21 
13:57:40 UTC ---

And as usual - convert.c contains premature optimization (this one hardly

worth) and/or duplicates of fold-const.c.  Thus removing the whole

NEGATE_EXPR case looks like the correct thing to do.



Leaving for christmas, so not me.  Patch pre-approved if you want to

prepare the patch and do the testing.

[Bug middle-end/55771] Negation and type conversion incorrectly exchanged

[rguenth at gcc dot gnu.org]

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



--- Comment #8 from Richard Biener  2012-12-21 
13:55:41 UTC ---

Or rather convert.c:convert_to_real:



  /* Propagate the cast into the operation.  */

  if (itype != type && FLOAT_TYPE_P (type))

switch (TREE_CODE (expr))

  {

/* Convert (float)-x into -(float)x.  This is safe for

   round-to-nearest rounding mode.  */

case ABS_EXPR:

case NEGATE_EXPR:

  if (!flag_rounding_math

  && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (expr)))

return build1 (TREE_CODE (expr), type,

   fold (convert_to_real (type,

  TREE_OPERAND (expr, 0;

  break;



that's of course not valid for unsigned x, even when using ufloat, as the

float result is always signed.

[Bug middle-end/55771] Negation and type conversion incorrectly exchanged

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



  Component|c   |middle-end



--- Comment #7 from Richard Biener  2012-12-21 
13:52:36 UTC ---

Ah, indeed - I misremembered a dup that was doing the opposite, converting

-1.0 to unsigned and expecting -1U as result.



It's fold converting (float)(-x) to -(float)x:



float

f1()

{

  unsigned long x = 3;

  return -x;

}