i386 FP comparsion bug (and sollution)

i386 FP comparsion bug (and sollution)

[Jan Hubicka]

Hi
I think I've tracked down quite important bug in condition code in i386.c/md.
The problem happends often when -mno-ieee-fp is set (that should be purpose
why it is considered as buggy) but happends rarely in normal comparsions too.

The condition code ocasinally sets the CC_REVERSED and TEST_AX (in -mno-ieee-fp
case) flags in cc_status variable. This usually works well.
Problem is, that reg-stack pass should emit some swap/mov?f patterns between
codition and jump. Handling of cc_status variable is then controlled in
NOTICE_UPDATE macro, that do approx following:
it is able to recognize condition and set the "default" flags for condition
it is able to recognize move and keep the flags and it is unable to recognize
swap and then clears the flags.
In case some instructions are between, it keeps flags correctly in case of
move patterns and sets them incorrectly in case of swap pattern. This is
easilly fixed in my tree by handling swap as move.
Problem is that before jump instruction, the NOTICE_UPDATE is called once
again for the condition insn (don't know why). It does recognize it and
sets the incorrect default values. Incorrect jump insn is emited then.

It is tricky to construct testcase, so I don't have any working with
latest snapshots without my patches, but hope description is clear.

My attempt to fix that is following: I've removed setting code from NOTICE_UPDATE
for FP conditions and added it to every pattern handling the conditions, so
flags are set correctly after pattern is output. NOTOCE_UPDATE is also modified
to recognize swap patterns, so it keeps unchanged until jump instruction is
output and everything seems to work well.

The fix is IMO rather unclean and I am not 100% sure what I am doing, so I am
asking here for some suggestions. Otherwise I will send the fix together with
some part of my patch to egcs-patches soon.

Honza
-- 
                       OK. Lets make a signature file.
+-------------------------------------------------------------------------+
|        Jan Hubicka (Jan Hubi\v{c}ka in TeX) hubicka@freesoft.cz         |
|         Czech free software foundation: http://www.freesoft.cz          |
|AA project - the new way for computer graphics - http://www.ta.jcu.cz/aa |
|  homepage: http://www.paru.cas.cz/~hubicka/ , games koules, Xonix, fast  |
|  fractal zoomer XaoS, index of Czech GNU/Linux/UN*X documentation etc.  | 
+-------------------------------------------------------------------------+

Re: i386 FP comparsion bug (and sollution)

[Jeffrey A Law]

  In message < 19981026090505.29312@atrey.karlin.mff.cuni.cz >you write:
  > The condition code ocasinally sets the CC_REVERSED and TEST_AX (in
  > -mno-ieee-fp case) flags in cc_status variable.
OK.

  > This usually works well.
  > Problem is, that reg-stack pass should emit some swap/mov?f patterns
  > between condition and jump.
"should"?  Or do you mean "could"?

Either way no instruction should ever be emitted between a cc0 setter and its
associated conditional jump.  They must be consecutive in the RTL stream on
the x86 (and any machine which defines HAVE_cc0.

So, if regstack is emitting insns between the cc0 setter and the cc0 user, then
that's a bug.

jeff

Re: i386 FP comparsion bug (and sollution)

[Jan Hubicka]

>   > This usually works well.
>   > Problem is, that reg-stack pass should emit some swap/mov?f patterns
>   > between condition and jump.
> "should"?  Or do you mean "could"?
Well according of my knowedge "should" = "could" so I really don't know :)
But reg-stack actually emits them sometimes.
> 
> Either way no instruction should ever be emitted between a cc0 setter and its
> associated conditional jump.  They must be consecutive in the RTL stream on
> the x86 (and any machine which defines HAVE_cc0.
> 
> So, if regstack is emitting insns between the cc0 setter and the cc0 user, then
> that's a bug.
Yes, it is bug. But why do not turn it to feature?
Reg-stack is last pass of optimizer, so no one after it should be confused
except the final pass. I believe I've fixed the finall pass and emiting
swaps after condition allows to emit better code.
I was looking for way to fix reg-stack pass and it seemed for me to be too
complex and result in worse code, so thats why I've choosed this solution.

Honza
> 
> jeff

-- 
                       OK. Lets make a signature file.
+-------------------------------------------------------------------------+
|        Jan Hubicka (Jan Hubi\v{c}ka in TeX) hubicka@freesoft.cz         |
|         Czech free software foundation: http://www.freesoft.cz          |
|AA project - the new way for computer graphics - http://www.ta.jcu.cz/aa |
|  homepage: http://www.paru.cas.cz/~hubicka/ , games koules, Xonix, fast  |
|  fractal zoomer XaoS, index of Czech GNU/Linux/UN*X documentation etc.  | 
+-------------------------------------------------------------------------+

Re: i386 FP comparsion bug (and sollution)

[Jeffrey A Law]

  In message < 19981030102448.60179@atrey.karlin.mff.cuni.cz >you write:
  > Yes, it is bug. But why do not turn it to feature?
No.  Not separating the cc0 from the cc0 user is a fundamental design concept,
we are not changing it anytime soon.

We need to stop regstack from inserting insns between the cc0 setter and
the cc0 user.  Anything else is unacceptable.

jeff

Re: i386 FP comparsion bug (new patch)

[Jan Hubicka]

Hi
So here is my second approach to fix the fp comparsion problem. This
patch modifies reg-stack to not use delay slot trick to pop second
operand and put REG_DEAD note instead. Operand is popped by
output_float_compare in i386.c

This patch is tested only with my quite heavily modified i386
machine description, but I don't see any purpose why it should not work
in egcs. Hope that this patch covers all cases and don't break anything.
I will probably do some more testing at monday. (running testsuite
and so on). For now I've succesfully bootstraped and compiled XaoS
(it didn't worked with -mno-ieee-fp, now it seems to work)

BTW I've claimed that this bug occours with normal compilation too,
but it is probably not true, because reg_stack probably never emits reversed
comparsion (I will try to modify it to do so soon). So this bug happends
only in -mno-ieee-fp mode.

Honza


Sat Oct 31 05:08:34 CET 1998 Jan Hubicka  (hubicka@freesoft.cz)
	* reg-stack.c: Do not emit pop insns after cc0 setter.
	(emit_pop_insn): Do not emit insn in case WHEN is NULL.
	(compare_for_stack_reg): Update REG_DEAD note and 
	do not emit push insn.

	* i386.c:
	(output_float_compare): Handle new REG_DEAD notes.

*** gcc/reg-stack.old	Sat Oct 31 03:27:03 1998
--- gcc/reg-stack.c	Sat Oct 31 05:06:07 1998
*************** delete_insn_for_stacker (insn)
*** 1700,1707 ****
  \f
  /* Emit an insn to pop virtual register REG before or after INSN.
     REGSTACK is the stack state after INSN and is updated to reflect this
!    pop.  WHEN is either emit_insn_before or emit_insn_after.  A pop insn
!    is represented as a SET whose destination is the register to be popped
     and source is the top of stack.  A death note for the top of stack
     cases the movdf pattern to pop.  */
  
--- 1700,1710 ----
  \f
  /* Emit an insn to pop virtual register REG before or after INSN.
     REGSTACK is the stack state after INSN and is updated to reflect this
!    pop.  WHEN is either emit_insn_before, emit_insn_after or NULL. 
!    in case WHEN is NULL we don't really emit the insn, just modify stack 
!    information. Caller is expected to emit insn himself.
! 
!    A pop insn is represented as a SET whose destination is the register to be popped
     and source is the top of stack.  A death note for the top of stack
     cases the movdf pattern to pop.  */
  
*************** emit_pop_insn (insn, regstack, reg, when
*** 1720,1735 ****
    if (hard_regno < FIRST_STACK_REG)
      abort ();
  
!   pop_rtx = gen_rtx_SET (VOIDmode, FP_MODE_REG (hard_regno, DFmode),
! 			 FP_MODE_REG (FIRST_STACK_REG, DFmode));
! 
!   pop_insn = (*when) (pop_rtx, insn);
!   /* ??? This used to be VOIDmode, but that seems wrong.  */
!   PUT_MODE (pop_insn, QImode);
! 
!   REG_NOTES (pop_insn) = gen_rtx_EXPR_LIST (REG_DEAD,
! 					    FP_MODE_REG (FIRST_STACK_REG, DFmode),
! 					    REG_NOTES (pop_insn));
  
    regstack->reg[regstack->top - (hard_regno - FIRST_STACK_REG)]
      = regstack->reg[regstack->top];
--- 1723,1741 ----
    if (hard_regno < FIRST_STACK_REG)
      abort ();
  
!   if (when)
!    {
!      pop_rtx = gen_rtx_SET (VOIDmode, FP_MODE_REG (hard_regno, DFmode),
! 			    FP_MODE_REG (FIRST_STACK_REG, DFmode));
! 
!      pop_insn = (*when) (pop_rtx, insn);
!      /* ??? This used to be VOIDmode, but that seems wrong.  */
!      PUT_MODE (pop_insn, QImode);
! 
!      REG_NOTES (pop_insn) = gen_rtx_EXPR_LIST (REG_DEAD,
! 					       FP_MODE_REG (FIRST_STACK_REG, DFmode),
! 					       REG_NOTES (pop_insn));
!    }
  
    regstack->reg[regstack->top - (hard_regno - FIRST_STACK_REG)]
      = regstack->reg[regstack->top];
*************** swap_rtx_condition (pat)
*** 1992,2001 ****
  /* Handle a comparison.  Special care needs to be taken to avoid
     causing comparisons that a 387 cannot do correctly, such as EQ.
  
!    Also, a pop insn may need to be emitted.  The 387 does have an
     `fcompp' insn that can pop two regs, but it is sometimes too expensive
     to do this - a `fcomp' followed by a `fstpl %st(0)' may be easier to
!    set up.  */
  
  static void
  compare_for_stack_reg (insn, regstack, pat)
--- 1998,2015 ----
  /* Handle a comparison.  Special care needs to be taken to avoid
     causing comparisons that a 387 cannot do correctly, such as EQ.
  
!    Also, a fstp instruction may need to be emitted.  The 387 does have an
     `fcompp' insn that can pop two regs, but it is sometimes too expensive
     to do this - a `fcomp' followed by a `fstpl %st(0)' may be easier to
!    set up. 
!  
!    We can not handle this by emiting fpop instruction after compare, because
!    it appears between cc0 setter and user. So we emit only
!    REG_DEAD note and handle it as a special case in machine description.
!  
!    This code used trick with delay_slot filling to emit pop insn after
!    comparsion but it didn't worked because it caused confusion with cc_status
!    in final pass. */
  
  static void
  compare_for_stack_reg (insn, regstack, pat)
*************** compare_for_stack_reg (insn, regstack, p
*** 2007,2012 ****
--- 2021,2027 ----
    rtx src1_note, src2_note;
    rtx cc0_user;
    int have_cmove; 
+   int hard_regno;
  
    src1 = get_true_reg (&XEXP (SET_SRC (pat), 0));
    src2 = get_true_reg (&XEXP (SET_SRC (pat), 1));
*************** compare_for_stack_reg (insn, regstack, p
*** 2073,2079 ****
    replace_reg (src1, FIRST_STACK_REG);
  
    if (STACK_REG_P (*src2))
!     replace_reg (src2, get_hard_regnum (regstack, *src2));
  
    if (src1_note)
      {
--- 2088,2097 ----
    replace_reg (src1, FIRST_STACK_REG);
  
    if (STACK_REG_P (*src2))
!     {
!       hard_regno = get_hard_regnum (regstack, *src2);
!       replace_reg (src2, hard_regno);
!     }
  
    if (src1_note)
      {
*************** compare_for_stack_reg (insn, regstack, p
*** 2102,2117 ****
  	}
        else
  	{
! 	  /* The 386 can only represent death of the first operand in
! 	     the case handled above.  In all other cases, emit a separate
! 	     pop and remove the death note from here.  */
! 
! 	  link_cc0_insns (insn);
! 
! 	  remove_regno_note (insn, REG_DEAD, REGNO (XEXP (src2_note, 0)));
  
! 	  emit_pop_insn (insn, regstack, XEXP (src2_note, 0),
! 			 emit_insn_after);
  	}
      }
  }
--- 2120,2130 ----
  	}
        else
  	{
! 	  /* Pop of second operand is handled using special REG_DEAD note
! 	     because we can't emit pop insn after cc0 setter */
  
! 	  emit_pop_insn (insn, regstack, XEXP (src2_note, 0), NULL);
! 	  replace_reg (&XEXP (src2_note, 0), hard_regno);
  	}
      }
  }
*** gcc/config/i386/i386.c.orig	Tue Oct 27 18:09:27 1998
--- gcc/config/i386/i386.c	Sat Oct 31 05:06:22 1998
*************** output_float_compare (insn, operands)
*** 3976,3981 ****
--- 4025,4032 ----
    rtx body = XVECEXP (PATTERN (insn), 0, 0);
    int unordered_compare = GET_MODE (SET_SRC (body)) == CCFPEQmode;
    rtx tmp;
+   int cc0_set = 1;
+   int i;
  
    if (0 && TARGET_CMOVE && STACK_REG_P (operands[1]))
      {
*************** output_float_compare (insn, operands)
*** 3999,4005 ****
    if (STACK_REG_P (operands[1])
        && stack_top_dies
        && find_regno_note (insn, REG_DEAD, REGNO (operands[1]))
!       && REGNO (operands[1]) != FIRST_STACK_REG)
      {
        /* If both the top of the 387 stack dies, and the other operand
  	 is also a stack register that dies, then this must be a
--- 4051,4057 ----
    if (STACK_REG_P (operands[1])
        && stack_top_dies
        && find_regno_note (insn, REG_DEAD, REGNO (operands[1]))
!       && REGNO (operands[1]) == FIRST_STACK_REG + 1)
      {
        /* If both the top of the 387 stack dies, and the other operand
  	 is also a stack register that dies, then this must be a
*************** output_float_compare (insn, operands)
*** 4011,4017 ****
  	    {
  	      output_asm_insn (AS2 (fucomip,%y1,%0), operands);
  	      output_asm_insn (AS1 (fstp, %y0), operands);
! 	      return "";
  	    }
  	  else
  	    output_asm_insn ("fucompp", operands);
--- 4063,4069 ----
  	    {
  	      output_asm_insn (AS2 (fucomip,%y1,%0), operands);
  	      output_asm_insn (AS1 (fstp, %y0), operands);
! 	      cc0_set = 0; 
  	    }
  	  else
  	    output_asm_insn ("fucompp", operands);
*************** output_float_compare (insn, operands)
*** 4022,4028 ****
  	    {
  	      output_asm_insn (AS2 (fcomip, %y1,%0), operands);
  	      output_asm_insn (AS1 (fstp, %y0), operands);
! 	      return "";
  	    }
  	  else
  	    output_asm_insn ("fcompp", operands);
--- 4074,4080 ----
  	    {
  	      output_asm_insn (AS2 (fcomip, %y1,%0), operands);
  	      output_asm_insn (AS1 (fstp, %y0), operands);
! 	      cc0_set = 0; 
  	    }
  	  else
  	    output_asm_insn ("fcompp", operands);
*************** output_float_compare (insn, operands)
*** 4052,4066 ****
        else if (cc_status.flags & CC_FCOMI)
  	{
  	  output_asm_insn (strcat (buf, AS2 (%z1,%y1,%0)), operands);
! 	  return "";
  	}
        else
          output_asm_insn (strcat (buf, AS1 (%z1,%y1)), operands);
      }
  
    /* Now retrieve the condition code. */
  
-   return output_fp_cc0_set (insn);
  }
  \f
  /* Output opcodes to transfer the results of FP compare or test INSN
--- 4104,4140 ----
        else if (cc_status.flags & CC_FCOMI)
  	{
  	  output_asm_insn (strcat (buf, AS2 (%z1,%y1,%0)), operands);
! 	  cc0_set = 0; 
  	}
        else
          output_asm_insn (strcat (buf, AS1 (%z1,%y1)), operands);
      }
  
    /* Now retrieve the condition code. */
+   if (cc0_set) 
+     {
+       char *r = output_fp_cc0_set (insn); 
+       if (r[0]) output_asm_insn (r, operands);
+     }
+ 
+ 
+   /* We emit fstp instruction after integer comparsions to improve scheduling */
+   for (i = 0; i < 2 ; i++)
+     {
+       if (STACK_REG_P (operands[i])
+           && find_regno_note (insn, REG_DEAD, REGNO (operands[i]))
+           && REGNO (operands[i]) != FIRST_STACK_REG 
+           && (!stack_top_dies || REGNO (operands[i]) != FIRST_STACK_REG + 1))
+         {
+           rtx xexp[i];
+           xexp[0] = gen_rtx_REG (DFmode, REGNO (operands[i]) - (stack_top_dies != 0));
+           output_asm_insn (AS1 (fstp, %y0), xexp);
+         }
+     }
+ 
+   return "";
+ 
  
  }
  \f
  /* Output opcodes to transfer the results of FP compare or test INSN

Re: i386 FP comparsion bug (and sollution)

[Jan Hubicka]

> 
>   In message <19981030102448.60179@atrey.karlin.mff.cuni.cz>you write:
>   > Yes, it is bug. But why do not turn it to feature?
> No.  Not separating the cc0 from the cc0 user is a fundamental design concept,
> we are not changing it anytime soon.
> 
> We need to stop regstack from inserting insns between the cc0 setter and
> the cc0 user.  Anything else is unacceptable.
OK
I've already read the reg-stack code and I believe I see the resonable solution.
(I should make compare code to emit fst itself (it already support it for fcompp
case and fcomp case is handlel specially in reg-stack.c, so it is probably not so bad
to add yet another exception I wanted to avoid))
I will try to make real fix today. The autor of reg-stack really knew that he is
adding code after condition so I expected it is design decision. Maybe it was
feature but it got forgotten and thats why this bug was created.
Making condition code to handle fst manually is probably better.
At the monday I will also make new version of my third patch w/o this fix
and send it separately. Maybe this fix should be resonable for 1.1.x too...

Honza
> 
> jeff

-- 
                       OK. Lets make a signature file.
+-------------------------------------------------------------------------+
|        Jan Hubicka (Jan Hubi\v{c}ka in TeX) hubicka@freesoft.cz         |
|         Czech free software foundation: http://www.freesoft.cz          |
|AA project - the new way for computer graphics - http://www.ta.jcu.cz/aa |
|  homepage: http://www.paru.cas.cz/~hubicka/ , games koules, Xonix, fast  |
|  fractal zoomer XaoS, index of Czech GNU/Linux/UN*X documentation etc.  | 
+-------------------------------------------------------------------------+

Re: i386 FP comparsion bug (and sollution)

[Marc Lehmann]

On Sat, Oct 31, 1998 at 10:07:34AM -0700, Jeffrey A Law wrote:
> No.  Not separating the cc0 from the cc0 user is a fundamental design concept,
> we are not changing it anytime soon.

I can remember that I explicitly allowed inserting (some) instructions
between the setter and the user (in pgcc), and it worked fine with fp-code.
Unfortunately I can't remember the details ;) as usual.. The code is buggy,
but in practise works perfect (I never reeceived a bug-report that was
caused by it).

> We need to stop regstack from inserting insns between the cc0 setter and
> the cc0 user.  Anything else is unacceptable.

that, of course, is true, changing this isn't possible in the foreseeable
future. Lifting this restriction is partly possible, but not a solution for
egcs.

OTOH this design decision slowly begins to hurt modern architectures.

      -----==-                                              |
      ----==-- _                                            |
      ---==---(_)__  __ ____  __       Marc Lehmann       +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com       |e|
      -=====/_/_//_/\_,_/ /_/\_\                          --+
    The choice of a GNU generation                        |
                                                          |

Re: i386 FP comparsion bug (and sollution)

[Jeffrey A Law]

  In message <19981030102448.60179@atrey.karlin.mff.cuni.cz>you write:
  > >   > This usually works well.
  > >   > Problem is, that reg-stack pass should emit some swap/mov?f patterns
  > >   > between condition and jump.
  > > "should"?  Or do you mean "could"?
  > Well according of my knowedge "should" = "could" so I really don't know :)
I think you wanted "could" :-)  Substitute "could" in your sentence and it
would be equivalent to "sometimes reg-stack emits a swap/mov insn between a cc0
setter and cc0 user".

  > But reg-stack actually emits them sometimes.
That sounds like a major bug to me.  For cc0 machines like the x86, nothing
is allowed to come between a cc0 setter and cc0 user.

  > Yes, it is bug. But why do not turn it to feature?
Because that is not how cc0 is designed to work.  It is a core and fundamental
design decision that a cc0 setter and cc0 user must not be separated.

We could change this fundamental design concept.  But that does not mean we
should change this fundamental design concept.  Even if it allows better code
in some cases.

jeff

Re: i386 FP comparsion bug (and sollution)

[Jeffrey A Law]

  In message < 19981102012555.D7828@cerebro.laendle >you write:
  > I can remember that I explicitly allowed inserting (some) instructions
  > between the setter and the user (in pgcc), and it worked fine with fp-code.
  > Unfortunately I can't remember the details ;) as usual.. The code is buggy,
  > but in practise works perfect (I never reeceived a bug-report that was
  > caused by it).
But the kind of bugs that will occur by putting insns between the setter and
user are going to be very obscure.  I wouldn't be suprised if you hadn't seen
anything fail because of this.  That does not mean what pgcc does is correct.

  > that, of course, is true, changing this isn't possible in the foreseeable
  > future. Lifting this restriction is partly possible, but not a solution for
  > egcs.
  > 
  > OTOH this design decision slowly begins to hurt modern architectures.
Note that modern ports do not use cc0 and thus do not suffer from these
problems.  One could consider rewriting the x86 port to not use cc0, or
revamping passes from final.c backwards to lift this restriction, but it's
a lot of work with unclear benefits.

jeff

Re: i386 FP comparsion bug (and sollution)

[Marc Lehmann]

On Mon, Nov 02, 1998 at 09:31:25AM -0700, Jeffrey A Law wrote:
> 
> 
>   In message < 19981102012555.D7828@cerebro.laendle >you write:
>   > I can remember that I explicitly allowed inserting (some) instructions
>   > between the setter and the user (in pgcc), and it worked fine with fp-code.
>   > Unfortunately I can't remember the details ;) as usual.. The code is buggy,
>   > but in practise works perfect (I never reeceived a bug-report that was
>   > caused by it).
> But the kind of bugs that will occur by putting insns between the setter and
> user are going to be very obscure.  I wouldn't be suprised if you hadn't seen
> anything fail because of this.  That does not mean what pgcc does is correct.

Nor does this mean the code generated by gcc is correct ;) There are quite a
few illegal assumptions in pgcc that would not be acceptable in egcs, but
work very well in practise (not that egcs isn't catching up quickly).

I didn't plea for getting rid of the checks in final.c ;)

> problems.  One could consider rewriting the x86 port to not use cc0, or
> revamping passes from final.c backwards to lift this restriction, but it's
> a lot of work with unclear benefits.

Well, this should be remembered when the x86 port is rewritten the next time
;-> Volunteers, anybody?

      -----==-                                              |
      ----==-- _                                            |
      ---==---(_)__  __ ____  __       Marc Lehmann       +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com       |e|
      -=====/_/_//_/\_,_/ /_/\_\                          --+
    The choice of a GNU generation                        |
                                                          |

Re: i386 FP comparsion bug (and sollution)

[Hans Dolfing]

>I think I've tracked down quite important bug in condition code in i386.c/md.
>The problem happends often when -mno-ieee-fp is set (that should be purpose
>why it is considered as buggy) but happends rarely in normal comparsions too.

[snip]

>It is tricky to construct testcase, so I don't have any working with
>latest snapshots without my patches, but hope description is clear.

Hi,

By coincidence, I was just constructing such a testcase. It hope it is
useful (and that we are talking about the same bug :)

Basically, if I switch on the '-mno-ieee-fp' flag
together with '-O2', a double-comparison returns 
1 instead of 0 !?!?!?!

Best regards,

	Hans

------------------Details---------------------------------------------
Setup:

Compiler built from egcs-1.0.3a sources with [gcc/g++/g77] diffs
to egcs-1.1b.

Specs:

Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnulibc1/egcs-2.91.57/specs
gcc version egcs-2.91.57 19980901 (egcs-1.1 release)

config.guess: i686-pc-linux-gnulibc1


Code: ----------------------------------------------------

#include <math.h>
#include <stdio.h>

int main(void)
{
	int i2;

	float bf = sqrt(3.0);

	i2 = (sqrt((double)bf) >2)?5:6; 

	printf("bf = %g\n",bf);
	printf("sqrt((double)bf) = %g\n",sqrt((double)bf));
	printf("(sqrt((double)bf) >2) = %d\n", (sqrt((double)bf) >2.0) );
	
	return 0;
}

Output:

----------------- 1 -----------------
Compile : gcc -mno-ieee-fp -o t bug.i686.c -lm
Run     : t
Output  :

bf = 1.73205
sqrt((double)bf) = 1.31607
(sqrt((double)bf) >2) = 0             <======= OK
----------------- 2 -----------------

Compile : gcc -O2 -mno-ieee-fp -o t bug.i686.c -lm
Run     : t
Output  :

bf = 1.73205
sqrt((double)bf) = 1.31607
(sqrt((double)bf) >2) = 1             <======= ?????

----------------- 3 -----------------

Compile : gcc -O2 -o t bug.i686.c -lm
Run     : t
Output  :

bf = 1.73205
sqrt((double)bf) = 1.31607
(sqrt((double)bf) >2) = 0             <======= OK