Possible Issue in ieeefp.h

[Craig Howland]

On 11/21/2016 11:08 AM, Joel Sherrill wrote:
> Hi
>
> An RTEMS user has tried to build GNU FORTRAN. It used to build
> and test OK. I am copying his report and my suggestion. I think
> the constants tested in ieeefp.h do NOT match those predefined
> by GCC. I need someone more knowledgable to confirm.
>
> Thanks.
>
> --joel
>
>>
>>
>> On Mon, Nov 21, 2016 at 9:24 AM, Ricardo Derbes <rmderbes@gmail.com> wrote:
>> Hello.
>> I'm trying to build rtems toolchain for i386 using
>> rtems-source-builder with fortran support (--with-fortran option).
>> The RSB I'm using has been dowloaded from git, commit
>> 534332f22a66f16b4022e87ae50c11ff20c98dcb from Sep 12 2016.
>>
>> ...
>>
>> As for my application I need fortran support, how can I fix this problem?
>> As long I can see, all symbols that the compiler claims as undeclared
>> are indeed declared and accessible in file
>> ~/devel4.12-i386.fortran/rtems-source-builder/rtems/build/i386-rtems4.12-gcc-6-20160609-newlib-2.4.0.20160527-x86_64-linux-gnu-1/gcc-6-20160609/newlib/libc/include/ieeefp.h 
>>
>> May be it's missing a symbol, e.g a proper value for LDBL_MANT_DIG ?
>>
>>
>> I see that GCC predefines these symbols:
>>
>> #define __FLT_MANT_DIG__ 24
>> #define __DEC64_MANT_DIG__ 16
>> #define __LDBL_MANT_DIG__ 53
>> #define __DBL_MANT_DIG__ 53
>> #define __DEC32_MANT_DIG__ 7
>> #define __DEC128_MANT_DIG__ 34
>>
>> And ieeefp.h in newlib has this:
>>
>> #elif LDBL_MANT_DIG == 53
>> /* This happens when doubles are 32-bits and long doubles are 64-bits.  */
>> #define EXT_EXPBITS     11
>> #define EXT_FRACHBITS   20
>> #define EXT_FRACLBITS   32
>> #define __ieee_ext_field_type unsigned long
>>
>> I am suspicious that the ifdef should use __LDBL_MANT_DIG__  not LDBL_MANT_DIG.
>>
ieeefp.h is definitely intending to use LDBL_MANT_DIG.  This is the C-standard 
defined name which is supposed to be defined in float.h, and which ieeefp.h 
directly states it is relying on.  Apparently the float.h being used is not 
properly defined/set up, and this is what needs to be corrected.
Craig