[gentoo-embedded] GCC bug when -ffast-math is set on arm-*-gnueabi

[Martin Guy]

Hi
  I thought I should mention this here too in case anyone else gets
 bitten by this arm-gnueabi-softfloat-specific bug.

   A GCC bug has just turned up that affects the arm-*-gnueabi
 architecture in gcc-4.[123]. While debugging libvorbisenc (which
 produces silent output files on armel), it turns out that when -O
 -ffast-math are set, GCC can produce incorrect code for the max(x,y)
 macro applied to floating point values.

  Thanks to Erik de Castro Lopo for some incisive debugging and for
 producing a minimal example (should print "0 0" but doesn't)

 /*
 **      This file is in the Public Domain.
 **
 **      This program demonstrates a bug in the -ffast-math option of the gcc
 **      armel compiler : gcc version 4.3.2 (Debian 4.3.2-1.1)
 **
 **      This works as expected:
 **
 **      > gcc -Wall -O3 gcc-test.c -o gcc-test && ./gcc-test
 **      min :       0.0000    max :       0.0000
 **
 **      Compile with -ffast-math and things goes screwy.
 **
 **      > gcc -Wall -O3 -ffast-math gcc-test.c -o gcc-test && ./gcc-test
 **      min :   99999.0000    max :       0.0000
 */

 #include <stdio.h>

 #define COUNT   10

 #define test_max(x,y)   ((x) <  (y) ? (y) : (x))
 #define test_min(x,y)   ((x) >  (y) ? (y) : (x))

 int
 main (void)
 {       /* C Standard says static data gets initialized to zero. */
        static float data [COUNT] ;
        float max = -99999.0, min = 99999.0 ;
        int k ;

        for (k = 0 ; k < COUNT ; k++)
        {       max = test_max (max, data [k]) ;
                min = test_min (min, data [k]) ;
                } ;

        printf ("min : %12.4f    max : %12.4f\n", min, max) ;

        return 0 ;
 }

 Full details at http://bugs.debian.org/515949

     M