Possible Issue in ieeefp.h

[Joel Sherrill]

On 11/21/2016 12:03 PM, Joel Sherrill wrote:
>
>
> On 11/21/2016 10:52 AM, Craig Howland wrote:
>>
>>
>> On 11/21/2016 11:38 AM, Joel Sherrill wrote:
>>>
>>>
>>> On 11/21/2016 10:26 AM, Craig Howland wrote:
>>>> 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.
>>>
>>> I have never poked in this area before. Where is this generated?
>>> Help on where to look and what could be broken is appreciated.
>>>
>>> Thanks.
>>>
>>>> Craig
>>>>
>>>
>>> --joel
>> float.h is generally assumed to be supplied by the compiler, in a fashion
>> similar to stdarg.h, as it contains compiler-specific sizes.  (I just took a
>> look at the GCC 4.1.1 PowerPC cross compiler's float.h, and they pretty much
>> just turn their internal defines into the C-required names.)  Probably the
>> --with-fortran option is messing things up.  Could you perhaps build without it
>> just to get the right float.h, and then use that as a bootstrap of sorts to make
>> the --with-fortran build work?  (Any way of finding the right float.h for your
>> GCC version should work.)
>
> Hmm.. my C/C++ toolset has this in float.h which looks correct:
>
> /* Number of base-FLT_RADIX digits in the significand, p.  */
> #undef FLT_MANT_DIG
> #undef DBL_MANT_DIG
> #undef LDBL_MANT_DIG
> #define FLT_MANT_DIG    __FLT_MANT_DIG__
> #define DBL_MANT_DIG    __DBL_MANT_DIG__
> #define LDBL_MANT_DIG   __LDBL_MANT_DIG__
>
> I will ask the user what the one in their build tree looks like.
> If that looks OK, maybe the source file that isn't compiling
> isn't including float.h. The user report doesn't go back far enough
> to have a file -- only errors in ieeefp.h.
>
> I have a thread to pull on. Thanks.

And I have something more concrete. :)

So far multiple RTEMS targets have built FORTRAN OK. But
the i386 (which is the one the user was trying) fails
with this:

/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/i386-rtems4.12-gcc-6-20161110-newlib-2.4.0.20161025-x86_64-linux-gnu-1/gcc-6-20161110/newlib/libc/include/ieeefp.h:152:2: error: #error "double and long double are the same size but LDBL_EQ_DBL is not defined"
  #error "double and long double are the same size but LDBL_EQ_DBL is not defined"
   ^~~~~

The versions of gcc and newlib are in this version string
from sparc-rtems4.12-gcc:

sparc-rtems4.12-gcc (GCC) 6.2.1 20161110 (RTEMS 4.12, RSB 1c68dbb293922863d5f48ec05559b0fc4b4ea893, Newlib 2.4.0.20161025)

It is nice to see ieeefp.h being defensive. Is the bug
in machine/ieeefp.h which should define this?

Thanks again.

--joel

> Thanks.
>
>> Craig
>>
>
> --joel
>