Re: Problem with egcs and denormalized constants?

Re: Problem with egcs and denormalized constants?

[David Edelsohn]

>>>>> Randy Gobbel writes:

Randy> P.S.: I just said the flMin problem was an egcs bug.  It's actually an
Randy> asm bug, because the constant is correct in the .s file:

Randy> .LC8:
Randy> .float 0d1.40129846432481707092e-45

	If I understand correctly, the bug actually is in glibc.  I
presume that the GNU assembler is not receiving the correct value when it
calls upon glibc to parse the constant for it to emit into the object
file.

David

Re: Problem with egcs and denormalized constants?

[David Edelsohn]

>>>>> Randy Gobbel writes:

Randy> P.S.: I just said the flMin problem was an egcs bug.  It's actually an
Randy> asm bug, because the constant is correct in the .s file:

Randy> .LC8:
Randy> .float 0d1.40129846432481707092e-45

	If I understand correctly, the bug actually is in glibc.  I
presume that the GNU assembler is not receiving the correct value when it
calls upon glibc to parse the constant for it to emit into the object
file.

David

RE: Problem with egcs and denormalized constants?

[Gary Thomas]

This turns out to be a bug in the GAS IEEE FP code.  It could potentially
happen on any platform, but it is seldom seen from C code.  This is because
most of the GCC/EGCS back-ends generate raw hex values for the FP constants.
The PowerPC back-end uses the ".float" directive instead.

Anyway, I have a patch for GAS which fixes it.  I'll be making a new set of
binutils RPMS (rev 19b) which should be available later today at:
  ftp://ftp.linuxppc.org/linuxppc/users/gdt/redhat/RPMS/ppc/

On 04-Mar-99 Kevin B. Hendricks wrote:
> Hi,
> 
> The LinuxPPC port of JDK 1.2 can't pass the Java Compatibility Kit runtime-vm
> tests because of some sort of error which is related to having very small
> de-nromalized float constants.
> 
> I don't know whether this is an egcs problem (it happens with both egcs 1.1.1
> and egcs 1.0.2), glibc problem (tested with the very latest glibc 1.99 rpm from
> Gary) but it is an error.  
> 
> Will someone please compile and try the follwoing very simple test program and
> help me understand what is happening here.  Is this an egcs problem?
> 
> [root@kbhend fltbug]# cat t3.c
>#include <unistd.h>
>#include <stdlib.h>
>#include <string.h>
>#include <stdio.h>
> 
> 
> float flMin (int i)
>  {
>    float fl;
>    if (i == 0) fl = 1.4023984e-37F;
>    if (i == 1) fl = 1.4023984e-38F;
>    if (i == 2) fl = 1.4023984e-39F;
>    if (i == 3) fl = 1.4023984e-40F;
>    if (i == 4) fl = 1.4023984e-41F;
>    if (i == 5) fl = 1.4023984e-42F;
>    if (i == 6) fl = 1.4023984e-43F;
>    if (i == 7) fl = 1.4023984e-44F;
>    if (i == 8) fl = 1.4023984e-45F;
>    return fl;
>  }
> 
> 
> int main(int argc, char** argv)
> {
>   int i;
>   float f;
> 
>   for (i=0;i<9;i++) {
>      f = flMin(i);
>      fprintf(stdout,"flmin(%1d) is %20.13e\n",i,f);
>   }
>   fprintf(stdout,"But flmin(7)/10.0F is %20.13e\n",(flMin(7)/10.0F));
> }
> 
> 
> Here is the output from my LinuxPPC box:
> 
> [root@kbhend fltbug]# ./t3
> flmin(0) is  1.4023984275674e-37
> flmin(1) is  1.4023983434895e-38
> flmin(2) is  1.4023984836193e-39
> flmin(3) is  1.4023914771270e-40
> flmin(4) is  1.4024195030963e-41
> flmin(5) is  1.4026997627891e-42
> flmin(6) is  1.4012984643248e-43
> flmin(7) is  1.4012984643248e-44
> flmin(8) is  0.0000000000000e+00
> But flmin(7)/10.0F is  1.4012984643248e-45            
> 
> 
> Here is the correct output from my AIX box using an old version of gcc:
> 
> kbhend$ gcc -ot3 -O0 t3.c
> kbhend$ ./t3
> flmin(0) is  1.4023984275674e-37
> flmin(1) is  1.4023983434895e-38
> flmin(2) is  1.4023984836193e-39
> flmin(3) is  1.4023914771270e-40
> flmin(4) is  1.4024195030963e-41
> flmin(5) is  1.4026997627891e-42
> flmin(6) is  1.4012984643248e-43
> flmin(7) is  1.4012984643248e-44
> flmin(8) is  1.4012984643248e-45
> But flmin(7)/10.0F is  1.4012984643248e-45
> 
> 
> Notice the difference in the value of flmin(8) when loaded from a constant.
> 
> I looked at the assmebler and the constant for that value is correctly
> identified and present.
> 
> What do you think?
> 
> Kevin

------------------------------------------------------------------------
Gary Thomas                              |
email: gdt@linuxppc.org                  | "Fine wine is a necessity of
   ... opinions expressed here are mine  |        life for me"
       and no one else would claim them! |
                                         |      Thomas Jefferson
------------------------------------------------------------------------

Re: Problem with egcs and denormalized constants?

[Jerry Quinn]

Kevin B. Hendricks wrote:

> Will someone please compile and try the follwoing very simple test program and
> help me understand what is happening here.  Is this an egcs problem?

For what it's worth, the 990228 egcs snapshot produces the correct
result on HPPA.  So at the very least, it's not a generic problem.

-- 
Jerry Quinn                             Tel: (514) 761-8737
jquinn@nortelnetworks.com               Fax: (514) 761-8505
Speech Recognition Research

Re: Problem with egcs and denormalized constants?

[Gary Thomas]

Which of version of BINUTILS are you using?

On 05-Mar-99 Randy Gobbel wrote:
> 
> David Edelsohn wrote:
>> 
>> >>>>> Randy Gobbel writes:
>> 
>> Randy> P.S.: I just said the flMin problem was an egcs bug.  It's actually an
>> Randy> asm bug, because the constant is correct in the .s file:
>> 
>> Randy> .LC8:
>> Randy> .float 0d1.40129846432481707092e-45
>> 
>>         If I understand correctly, the bug actually is in glibc.  I
>> presume that the GNU assembler is not receiving the correct value when it
>> calls upon glibc to parse the constant for it to emit into the object
>> file.
> 
> I've been poking around in binutils a bit, and it looks to me like the
> badness is actually in gas.  Somewhere in expr.c is my current best
> guess.  As far as I can tell, gas doesn't actually call glibc to
> translate numbers, it has its own hairy platform-independent stuff for
> that.
> 
> -Randy
> -- 
> http://www.cnbc.cmu.edu/~gobbel/
> PGP fingerprint: 32 8A E8 24 A1 46 26 BC  F9 9D 0E B6 81 A9 02 0C
> 
> NOTICE: I DO NOT ACCEPT UNSOLICITED COMMERCIAL EMAIL MESSAGES OF ANY
> KIND.
> 
> [[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
> [[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
> [[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
> [[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Problem with egcs and denormalized constants?

[Gary Thomas]

On 06-Mar-99 David Edelsohn wrote:
>>>>>> Gary Thomas writes:
> 
> Gary> This turns out to be a bug in the GAS IEEE FP code.  It could potentially
> Gary> happen on any platform, but it is seldom seen from C code.  This is because
> Gary> most of the GCC/EGCS back-ends generate raw hex values for the FP constants.
> Gary> The PowerPC back-end uses the ".float" directive instead.
> 
>       The PowerPC port goes to the trouble of emitting the actual bit
> pattern for infinities, NaNs, and -0 (as opposed to +0).  Most other ports
> emit the bits consistently.  I have no problem changing EGCS to be
> consistent with the others.  I am not fully sure why the PowerPC port is
> implemented to email FP constants as FP values; it may have been a
> holdover before the port was converted to use the GCC built-in
> REAL_ARITHMETIC support.  Are there any reasons that I should not switch
> to the underlying bit patterns?
> 

I don't have a huge opinion either way.  My comment was just to note that
because the PowerPC back-end uses ".float" was how Kevin's problem became
manifest.  The error still exists in GAS and any use of that code on any
platform would trigger is, save that virtually all of the other back-ends
do not emit ".float".

I'd say leave it as is - it's fixed now.

------------------------------------------------------------------------
Gary Thomas                              |
email: gdt@linuxppc.org                  | "Fine wine is a necessity of
   ... opinions expressed here are mine  |        life for me"
       and no one else would claim them! |
                                         |      Thomas Jefferson
------------------------------------------------------------------------

Re: Problem with egcs and denormalized constants?

[Gary Thomas]

On 05-Mar-99 David Edelsohn wrote:
> 
>>>>>> Randy Gobbel writes:
> 
> Randy> I've been poking around in binutils a bit, and it looks to me like the
> Randy> badness is actually in gas.  Somewhere in expr.c is my current best
> Randy> guess.  As far as I can tell, gas doesn't actually call glibc to
> Randy> translate numbers, it has its own hairy platform-independent stuff for
> Randy> that.
> 
>       Has anyone created a small, self-contained testcase and reported
> it as a bug to binutils?
> 
> David
> 

I'm looking into it.  Note: it was only in the last few hours that this
problem with GAS/BINUTILS/??? became known.


------------------------------------------------------------------------
Gary Thomas                              |
email: gdt@linuxppc.org                  | "Fine wine is a necessity of
   ... opinions expressed here are mine  |        life for me"
       and no one else would claim them! |
                                         |      Thomas Jefferson
------------------------------------------------------------------------

Re: Problem with egcs and denormalized constants?

[David Edelsohn]

>>>>> Gary Thomas writes:

Gary> This turns out to be a bug in the GAS IEEE FP code.  It could potentially
Gary> happen on any platform, but it is seldom seen from C code.  This is because
Gary> most of the GCC/EGCS back-ends generate raw hex values for the FP constants.
Gary> The PowerPC back-end uses the ".float" directive instead.

	The PowerPC port goes to the trouble of emitting the actual bit
pattern for infinities, NaNs, and -0 (as opposed to +0).  Most other ports
emit the bits consistently.  I have no problem changing EGCS to be
consistent with the others.  I am not fully sure why the PowerPC port is
implemented to email FP constants as FP values; it may have been a
holdover before the port was converted to use the GCC built-in
REAL_ARITHMETIC support.  Are there any reasons that I should not switch
to the underlying bit patterns?

Thanks, David

Problem with egcs and denormalized constants?

[Kevin B. Hendricks]

Hi,

The LinuxPPC port of JDK 1.2 can't pass the Java Compatibility Kit runtime-vm
tests because of some sort of error which is related to having very small
de-nromalized float constants.

I don't know whether this is an egcs problem (it happens with both egcs 1.1.1
and egcs 1.0.2), glibc problem (tested with the very latest glibc 1.99 rpm from
Gary) but it is an error.  

Will someone please compile and try the follwoing very simple test program and
help me understand what is happening here.  Is this an egcs problem?

[root@kbhend fltbug]# cat t3.c
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>


float flMin (int i)
 {
   float fl;
   if (i == 0) fl = 1.4023984e-37F;
   if (i == 1) fl = 1.4023984e-38F;
   if (i == 2) fl = 1.4023984e-39F;
   if (i == 3) fl = 1.4023984e-40F;
   if (i == 4) fl = 1.4023984e-41F;
   if (i == 5) fl = 1.4023984e-42F;
   if (i == 6) fl = 1.4023984e-43F;
   if (i == 7) fl = 1.4023984e-44F;
   if (i == 8) fl = 1.4023984e-45F;
   return fl;
 }


int main(int argc, char** argv)
{
  int i;
  float f;

  for (i=0;i<9;i++) {
     f = flMin(i);
     fprintf(stdout,"flmin(%1d) is %20.13e\n",i,f);
  }
  fprintf(stdout,"But flmin(7)/10.0F is %20.13e\n",(flMin(7)/10.0F));
}


Here is the output from my LinuxPPC box:

[root@kbhend fltbug]# ./t3
flmin(0) is  1.4023984275674e-37
flmin(1) is  1.4023983434895e-38
flmin(2) is  1.4023984836193e-39
flmin(3) is  1.4023914771270e-40
flmin(4) is  1.4024195030963e-41
flmin(5) is  1.4026997627891e-42
flmin(6) is  1.4012984643248e-43
flmin(7) is  1.4012984643248e-44
flmin(8) is  0.0000000000000e+00
But flmin(7)/10.0F is  1.4012984643248e-45            


Here is the correct output from my AIX box using an old version of gcc:

kbhend$ gcc -ot3 -O0 t3.c
kbhend$ ./t3
flmin(0) is  1.4023984275674e-37
flmin(1) is  1.4023983434895e-38
flmin(2) is  1.4023984836193e-39
flmin(3) is  1.4023914771270e-40
flmin(4) is  1.4024195030963e-41
flmin(5) is  1.4026997627891e-42
flmin(6) is  1.4012984643248e-43
flmin(7) is  1.4012984643248e-44
flmin(8) is  1.4012984643248e-45
But flmin(7)/10.0F is  1.4012984643248e-45


Notice the difference in the value of flmin(8) when loaded from a constant.

I looked at the assmebler and the constant for that value is correctly
identified and present.

What do you think?

Kevin

Re: Problem with egcs and denormalized constants?

[David Edelsohn]

>>>>> Randy Gobbel writes:

Randy> I've been poking around in binutils a bit, and it looks to me like the
Randy> badness is actually in gas.  Somewhere in expr.c is my current best
Randy> guess.  As far as I can tell, gas doesn't actually call glibc to
Randy> translate numbers, it has its own hairy platform-independent stuff for
Randy> that.

	Has anyone created a small, self-contained testcase and reported
it as a bug to binutils?

David

Re: Problem with egcs and denormalized constants?

[Gary Thomas]

On 06-Mar-99 David Edelsohn wrote:
>>>>>> Gary Thomas writes:
> 
> Gary> This turns out to be a bug in the GAS IEEE FP code.  It could potentially
> Gary> happen on any platform, but it is seldom seen from C code.  This is because
> Gary> most of the GCC/EGCS back-ends generate raw hex values for the FP constants.
> Gary> The PowerPC back-end uses the ".float" directive instead.
> 
>       The PowerPC port goes to the trouble of emitting the actual bit
> pattern for infinities, NaNs, and -0 (as opposed to +0).  Most other ports
> emit the bits consistently.  I have no problem changing EGCS to be
> consistent with the others.  I am not fully sure why the PowerPC port is
> implemented to email FP constants as FP values; it may have been a
> holdover before the port was converted to use the GCC built-in
> REAL_ARITHMETIC support.  Are there any reasons that I should not switch
> to the underlying bit patterns?
> 

I don't have a huge opinion either way.  My comment was just to note that
because the PowerPC back-end uses ".float" was how Kevin's problem became
manifest.  The error still exists in GAS and any use of that code on any
platform would trigger is, save that virtually all of the other back-ends
do not emit ".float".

I'd say leave it as is - it's fixed now.

------------------------------------------------------------------------
Gary Thomas                              |
email: gdt@linuxppc.org                  | "Fine wine is a necessity of
   ... opinions expressed here are mine  |        life for me"
       and no one else would claim them! |
                                         |      Thomas Jefferson
------------------------------------------------------------------------

Re: Problem with egcs and denormalized constants?

[David Edelsohn]

>>>>> Gary Thomas writes:

Gary> This turns out to be a bug in the GAS IEEE FP code.  It could potentially
Gary> happen on any platform, but it is seldom seen from C code.  This is because
Gary> most of the GCC/EGCS back-ends generate raw hex values for the FP constants.
Gary> The PowerPC back-end uses the ".float" directive instead.

	The PowerPC port goes to the trouble of emitting the actual bit
pattern for infinities, NaNs, and -0 (as opposed to +0).  Most other ports
emit the bits consistently.  I have no problem changing EGCS to be
consistent with the others.  I am not fully sure why the PowerPC port is
implemented to email FP constants as FP values; it may have been a
holdover before the port was converted to use the GCC built-in
REAL_ARITHMETIC support.  Are there any reasons that I should not switch
to the underlying bit patterns?

Thanks, David

RE: Problem with egcs and denormalized constants?

[Gary Thomas]

This turns out to be a bug in the GAS IEEE FP code.  It could potentially
happen on any platform, but it is seldom seen from C code.  This is because
most of the GCC/EGCS back-ends generate raw hex values for the FP constants.
The PowerPC back-end uses the ".float" directive instead.

Anyway, I have a patch for GAS which fixes it.  I'll be making a new set of
binutils RPMS (rev 19b) which should be available later today at:
  ftp://ftp.linuxppc.org/linuxppc/users/gdt/redhat/RPMS/ppc/

On 04-Mar-99 Kevin B. Hendricks wrote:
> Hi,
> 
> The LinuxPPC port of JDK 1.2 can't pass the Java Compatibility Kit runtime-vm
> tests because of some sort of error which is related to having very small
> de-nromalized float constants.
> 
> I don't know whether this is an egcs problem (it happens with both egcs 1.1.1
> and egcs 1.0.2), glibc problem (tested with the very latest glibc 1.99 rpm from
> Gary) but it is an error.  
> 
> Will someone please compile and try the follwoing very simple test program and
> help me understand what is happening here.  Is this an egcs problem?
> 
> [root@kbhend fltbug]# cat t3.c
>#include <unistd.h>
>#include <stdlib.h>
>#include <string.h>
>#include <stdio.h>
> 
> 
> float flMin (int i)
>  {
>    float fl;
>    if (i == 0) fl = 1.4023984e-37F;
>    if (i == 1) fl = 1.4023984e-38F;
>    if (i == 2) fl = 1.4023984e-39F;
>    if (i == 3) fl = 1.4023984e-40F;
>    if (i == 4) fl = 1.4023984e-41F;
>    if (i == 5) fl = 1.4023984e-42F;
>    if (i == 6) fl = 1.4023984e-43F;
>    if (i == 7) fl = 1.4023984e-44F;
>    if (i == 8) fl = 1.4023984e-45F;
>    return fl;
>  }
> 
> 
> int main(int argc, char** argv)
> {
>   int i;
>   float f;
> 
>   for (i=0;i<9;i++) {
>      f = flMin(i);
>      fprintf(stdout,"flmin(%1d) is %20.13e\n",i,f);
>   }
>   fprintf(stdout,"But flmin(7)/10.0F is %20.13e\n",(flMin(7)/10.0F));
> }
> 
> 
> Here is the output from my LinuxPPC box:
> 
> [root@kbhend fltbug]# ./t3
> flmin(0) is  1.4023984275674e-37
> flmin(1) is  1.4023983434895e-38
> flmin(2) is  1.4023984836193e-39
> flmin(3) is  1.4023914771270e-40
> flmin(4) is  1.4024195030963e-41
> flmin(5) is  1.4026997627891e-42
> flmin(6) is  1.4012984643248e-43
> flmin(7) is  1.4012984643248e-44
> flmin(8) is  0.0000000000000e+00
> But flmin(7)/10.0F is  1.4012984643248e-45            
> 
> 
> Here is the correct output from my AIX box using an old version of gcc:
> 
> kbhend$ gcc -ot3 -O0 t3.c
> kbhend$ ./t3
> flmin(0) is  1.4023984275674e-37
> flmin(1) is  1.4023983434895e-38
> flmin(2) is  1.4023984836193e-39
> flmin(3) is  1.4023914771270e-40
> flmin(4) is  1.4024195030963e-41
> flmin(5) is  1.4026997627891e-42
> flmin(6) is  1.4012984643248e-43
> flmin(7) is  1.4012984643248e-44
> flmin(8) is  1.4012984643248e-45
> But flmin(7)/10.0F is  1.4012984643248e-45
> 
> 
> Notice the difference in the value of flmin(8) when loaded from a constant.
> 
> I looked at the assmebler and the constant for that value is correctly
> identified and present.
> 
> What do you think?
> 
> Kevin

------------------------------------------------------------------------
Gary Thomas                              |
email: gdt@linuxppc.org                  | "Fine wine is a necessity of
   ... opinions expressed here are mine  |        life for me"
       and no one else would claim them! |
                                         |      Thomas Jefferson
------------------------------------------------------------------------

Re: Problem with egcs and denormalized constants?

[Gary Thomas]

On 05-Mar-99 David Edelsohn wrote:
> 
>>>>>> Randy Gobbel writes:
> 
> Randy> I've been poking around in binutils a bit, and it looks to me like the
> Randy> badness is actually in gas.  Somewhere in expr.c is my current best
> Randy> guess.  As far as I can tell, gas doesn't actually call glibc to
> Randy> translate numbers, it has its own hairy platform-independent stuff for
> Randy> that.
> 
>       Has anyone created a small, self-contained testcase and reported
> it as a bug to binutils?
> 
> David
> 

I'm looking into it.  Note: it was only in the last few hours that this
problem with GAS/BINUTILS/??? became known.


------------------------------------------------------------------------
Gary Thomas                              |
email: gdt@linuxppc.org                  | "Fine wine is a necessity of
   ... opinions expressed here are mine  |        life for me"
       and no one else would claim them! |
                                         |      Thomas Jefferson
------------------------------------------------------------------------

Re: Problem with egcs and denormalized constants?

[Gary Thomas]

Which of version of BINUTILS are you using?

On 05-Mar-99 Randy Gobbel wrote:
> 
> David Edelsohn wrote:
>> 
>> >>>>> Randy Gobbel writes:
>> 
>> Randy> P.S.: I just said the flMin problem was an egcs bug.  It's actually an
>> Randy> asm bug, because the constant is correct in the .s file:
>> 
>> Randy> .LC8:
>> Randy> .float 0d1.40129846432481707092e-45
>> 
>>         If I understand correctly, the bug actually is in glibc.  I
>> presume that the GNU assembler is not receiving the correct value when it
>> calls upon glibc to parse the constant for it to emit into the object
>> file.
> 
> I've been poking around in binutils a bit, and it looks to me like the
> badness is actually in gas.  Somewhere in expr.c is my current best
> guess.  As far as I can tell, gas doesn't actually call glibc to
> translate numbers, it has its own hairy platform-independent stuff for
> that.
> 
> -Randy
> -- 
> http://www.cnbc.cmu.edu/~gobbel/
> PGP fingerprint: 32 8A E8 24 A1 46 26 BC  F9 9D 0E B6 81 A9 02 0C
> 
> NOTICE: I DO NOT ACCEPT UNSOLICITED COMMERCIAL EMAIL MESSAGES OF ANY
> KIND.
> 
> [[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
> [[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
> [[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
> [[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Problem with egcs and denormalized constants?

[David Edelsohn]

>>>>> Randy Gobbel writes:

Randy> I've been poking around in binutils a bit, and it looks to me like the
Randy> badness is actually in gas.  Somewhere in expr.c is my current best
Randy> guess.  As far as I can tell, gas doesn't actually call glibc to
Randy> translate numbers, it has its own hairy platform-independent stuff for
Randy> that.

	Has anyone created a small, self-contained testcase and reported
it as a bug to binutils?

David

Re: Problem with egcs and denormalized constants?

[Jerry Quinn]

Kevin B. Hendricks wrote:

> Will someone please compile and try the follwoing very simple test program and
> help me understand what is happening here.  Is this an egcs problem?

For what it's worth, the 990228 egcs snapshot produces the correct
result on HPPA.  So at the very least, it's not a generic problem.

-- 
Jerry Quinn                             Tel: (514) 761-8737
jquinn@nortelnetworks.com               Fax: (514) 761-8505
Speech Recognition Research

Problem with egcs and denormalized constants?

[Kevin B. Hendricks]

Hi,

The LinuxPPC port of JDK 1.2 can't pass the Java Compatibility Kit runtime-vm
tests because of some sort of error which is related to having very small
de-nromalized float constants.

I don't know whether this is an egcs problem (it happens with both egcs 1.1.1
and egcs 1.0.2), glibc problem (tested with the very latest glibc 1.99 rpm from
Gary) but it is an error.  

Will someone please compile and try the follwoing very simple test program and
help me understand what is happening here.  Is this an egcs problem?

[root@kbhend fltbug]# cat t3.c
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>


float flMin (int i)
 {
   float fl;
   if (i == 0) fl = 1.4023984e-37F;
   if (i == 1) fl = 1.4023984e-38F;
   if (i == 2) fl = 1.4023984e-39F;
   if (i == 3) fl = 1.4023984e-40F;
   if (i == 4) fl = 1.4023984e-41F;
   if (i == 5) fl = 1.4023984e-42F;
   if (i == 6) fl = 1.4023984e-43F;
   if (i == 7) fl = 1.4023984e-44F;
   if (i == 8) fl = 1.4023984e-45F;
   return fl;
 }


int main(int argc, char** argv)
{
  int i;
  float f;

  for (i=0;i<9;i++) {
     f = flMin(i);
     fprintf(stdout,"flmin(%1d) is %20.13e\n",i,f);
  }
  fprintf(stdout,"But flmin(7)/10.0F is %20.13e\n",(flMin(7)/10.0F));
}


Here is the output from my LinuxPPC box:

[root@kbhend fltbug]# ./t3
flmin(0) is  1.4023984275674e-37
flmin(1) is  1.4023983434895e-38
flmin(2) is  1.4023984836193e-39
flmin(3) is  1.4023914771270e-40
flmin(4) is  1.4024195030963e-41
flmin(5) is  1.4026997627891e-42
flmin(6) is  1.4012984643248e-43
flmin(7) is  1.4012984643248e-44
flmin(8) is  0.0000000000000e+00
But flmin(7)/10.0F is  1.4012984643248e-45            


Here is the correct output from my AIX box using an old version of gcc:

kbhend$ gcc -ot3 -O0 t3.c
kbhend$ ./t3
flmin(0) is  1.4023984275674e-37
flmin(1) is  1.4023983434895e-38
flmin(2) is  1.4023984836193e-39
flmin(3) is  1.4023914771270e-40
flmin(4) is  1.4024195030963e-41
flmin(5) is  1.4026997627891e-42
flmin(6) is  1.4012984643248e-43
flmin(7) is  1.4012984643248e-44
flmin(8) is  1.4012984643248e-45
But flmin(7)/10.0F is  1.4012984643248e-45


Notice the difference in the value of flmin(8) when loaded from a constant.

I looked at the assmebler and the constant for that value is correctly
identified and present.

What do you think?

Kevin