[Bug middle-end/34992] compiler produces wrong code when optimizing

[roebel at ircam dot fr]

--- Comment #8 from roebel at ircam dot fr  2008-01-28 10:00 ---
For completeness :
I now use this function that was proposed in 
PR 323. It seems to solve my issue. Thanks for the pointer!

  inline
  void set_math_double_precision() {
fpu_control_t fpu_control ;
_FPU_GETCW(fpu_control);
fpu_control = (fpu_control  ~_FPU_EXTENDED) | _FPU_DOUBLE;
_FPU_SETCW(fpu_control);
  }


-- 


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

[Bug middle-end/34992] compiler produces wrong code when optimizing

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|critical|normal
  Component|c++ |middle-end


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

[Bug middle-end/34992] compiler produces wrong code when optimizing

[roebel at ircam dot fr]

--- Comment #4 from roebel at ircam dot fr  2008-01-27 23:05 ---

yes indeed, that fixes the problem.
now, does that mean holding double values in a set 
is not possible?


-- 


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

[Bug middle-end/34992] compiler produces wrong code when optimizing

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-01-27 23:17 ---
Even though  -mfpmath=sse is used, x87 is used in some cases still and what you
are seeing is an effect of PR 323.  Closing as a duplicate.  You should be more
careful with your comparison loop of FP values.

*** This bug has been marked as a duplicate of 323 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/34992] compiler produces wrong code when optimizing

[roebel at ircam dot fr]

--- Comment #6 from roebel at ircam dot fr  2008-01-28 00:14 ---
Andrew,

while -ffloat-store fixes the problem, this solution is obviously not
acceptable. Moreover, here the problem is not that I compare floats 
using = the problem is that std::setdouble::insert(double) compares
set elements using std::lessdouble which in this case just does not work. 

Now using std::lessdouble for a set does not seem not carefull
to me, be cause this is the default. So the default is nonsense ?

I fixed the problem by means of using  std::setdouble,dless
with dless being

struct dless{
  typedef double first_argument_type;
  typedef double second_argument_type;
  typedef bool result_type;
  volatile double d1;
  volatile double d2;
  bool operator()(double in1, double in2) {
d1 = in1;
d2 = in2;
return d1  d2;
  }
};

which proves that the problem is in the std::less operator
and not in my code. In fact this even means that 
std::lessdouble and std::greaterdouble and all 
their company is useless because you can never be sure what they 
are comparing. So many of the functions of the std::library
may fail!! Am I wrong, here ? 


-- 


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

[Bug middle-end/34992] compiler produces wrong code when optimizing

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2008-01-28 01:18 ---
(In reply to comment #6)
 Am I wrong, here ? 

Semi, what is happening is the values for std::lessdouble is being stored in
the fpr register and that is really a 80bit register and not a 64bit fp
register.  -mpc64 is another fix for the issue, but that only exists on the
trunk.


-- 


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