Possible Issue in ieeefp.h

Possible Issue in ieeefp.h

[Joel Sherrill]

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.
>
> The full command line is:
> ../source-builder/sb-set-builder
> --prefix=~/devel4.12-i386.fortran/rtems4.12 4.12/rtems-i386
> --without-rtems --with-fortran
>
> When trying to build gcc, it fails with the following errors (excerpt
> from report file
> rsb-report-i386-rtems4.12-gcc-6-20160609-newlib-2.4.0.20160527-x86_64-linux-gnu-1.txt):
>
> Tail of the build log:
> ~/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:196:38:
> error: 'EXT_FRACHBITS' undeclared here (not in a function)
> __ieee_ext_field_type  ext_frach : EXT_FRACHBITS;
>                                       ^~~~~~~~~~~~~
> ~/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:196:26:
> error: bit-field 'ext_frach' width not an integer constant
> __ieee_ext_field_type  ext_frach : EXT_FRACHBITS;
>                           ^~~~~~~~~
> /home/dev/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:197:3:
> error: unknown type name '__ieee_ext_field_type'
>    __ieee_ext_field_type  ext_exp   : EXT_EXPBITS;
>    ^~~~~~~~~~~~~~~~~~~~~
> ~/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:197:38:
> error: 'EXT_EXPBITS' undeclared here (not in a function)
> __ieee_ext_field_type  ext_exp   : EXT_EXPBITS;
>                                       ^~~~~~~~~~~
> /home/dev/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:197:26:
> error: bit-field 'ext_exp' width not an integer constant
> __ieee_ext_field_type  ext_exp   : EXT_EXPBITS;
>                           ^~~~~~~
> ~/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:198:3:
> error: unknown type name '__ieee_ext_field_type'
> __ieee_ext_field_type  ext_sign  : 1;
>    ^~~~~~~~~~~~~~~~~~~~~
>
> 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.
>
> But I will have to ask on the newlib mailing list to get an answer.
>
> --joel


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35806
Support Available                (256) 722-9985

Re: 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

Re: Possible Issue in ieeefp.h

[Joel Sherrill]

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

Re: Possible Issue in ieeefp.h

[Craig Howland]

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.)
Craig

Re: Possible Issue in ieeefp.h

[Joel Sherrill]

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.

Thanks.

> Craig
>

--joel

Re: 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
>

Re: Possible Issue in ieeefp.h

[Craig Howland]

On 11/21/2016 03:12 PM, Joel Sherrill wrote:
>
>
> On 11/21/2016 12:03 PM, Joel Sherrill wrote:
>>
>>
>> On 11/21/2016 10:52 AM, Craig Howland wrote:
>>>
>>> ...
>>
>> 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
>
No, LDBL_EQ_DBL is supposed to be defined by configure.  That check is also 
rigorous, not only requiring the mantissa length, but also the exponent range.  
As a guess, one of the latter two is perhaps missing from your float.h.

#include <float.h>
#if DBL_MANT_DIG == LDBL_MANT_DIG  &&  LDBL_MIN_EXP == DBL_MIN_EXP  && \
     LDBL_MAX_EXP == DBL_MAX_EXP
   #define _LDBL_EQ_DBL
  #else
   #error "LDBL != DBL"
#endif

Craig

Re: Possible Issue in ieeefp.h

[Joel Sherrill]

On 11/21/2016 2:19 PM, Craig Howland wrote:
> On 11/21/2016 03:12 PM, Joel Sherrill wrote:
>>
>>
>> On 11/21/2016 12:03 PM, Joel Sherrill wrote:
>>>
>>>
>>> On 11/21/2016 10:52 AM, Craig Howland wrote:
>>>>
>>>> ...
>>>
>>> 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
>>
> No, LDBL_EQ_DBL is supposed to be defined by configure.  That check is also
> rigorous, not only requiring the mantissa length, but also the exponent range.
> As a guess, one of the latter two is perhaps missing from your float.h.
>
> #include <float.h>
> #if DBL_MANT_DIG == LDBL_MANT_DIG  &&  LDBL_MIN_EXP == DBL_MIN_EXP  && \
>      LDBL_MAX_EXP == DBL_MAX_EXP
>    #define _LDBL_EQ_DBL
>   #else
>    #error "LDBL != DBL"
> #endif

As you expected, that gave the #error. But when I broke
it apart to see which parts != none tripped. So I
added this before the error check.

#define JOEL(_x) int joel_## _x = _x;
JOEL(DBL_MANT_DIG)
JOEL(LDBL_MANT_DIG)
JOEL(DBL_MIN_EXP)
JOEL(LDBL_MIN_EXP)
JOEL(DBL_MAX_EXP)
JOEL(LDBL_MAX_EXP)

And got this in the preprocessed output.

int joel_DBL_MANT_DIG = 53;
int joel_LDBL_MANT_DIG = 64;
int joel_DBL_MIN_EXP = (-1021);
int joel_LDBL_MIN_EXP = (-16381);
int joel_DBL_MAX_EXP = 1024;
int joel_LDBL_MAX_EXP = 16384;

I'm now confused why this ifdef (line 151) trips:

#elif LDBL_MANT_DIG == DBL_MANT_DIG

That makes even less sense based on this:

$ i386-rtems4.12-gcc -dM -E - </dev/null | grep DBL_MANT_DIG
#define __LDBL_MANT_DIG__ 64
#define __DBL_MANT_DIG__ 53

I added parentheses around that #elif and it proceeds on
the i386 and m68k.

Is the addition of parentheses necessary? That would fix
one issue if that's OK to add.

Further on the two targets that have failed so far.

========= m68k
The m68k failed in the same way but DBL and LDBL really
are the same there on the first multilib that failed.
The addition of your conditional let the build continue.

But then it failed on what I think it the default
multilib. The "joel_" values were exactly the same
as on the i386 above.

================ i386 failure with addition of parens
On the i386, there is a harder build failure:

In file included from ../../../../gcc-6-20161110/libgfortran/runtime/fpu.c:29:0:
./fpu-target.h: In function 'set_fpu_except_flags':
./fpu-target.h:110:7: error: impossible constraint in 'asm'
        __asm__ __volatile__ ("fdiv\t{%y0, %0|%0, %y0}" : "+t" (f));
        ^~~~~~~
./fpu-target.h:130:7: error: impossible constraint in 'asm'
        __asm__ __volatile__ ("fdivs\t%1" : "+t" (f) : "m" (g));
        ^~~~~~~
./fpu-target.h:158:7: error: impossible constraint in 'asm'
        __asm__ __volatile__ ("fdivs\t%1" : "+t" (f) : "m" (g));

Anybody know x86 FP and the constraints enough to fix the
second problem? It looks like +t is that the top of the FP
stack is both read and written by some libgfortran target code.


This should be reproducible on i386-elf and m68k-elf
if fortran is enabled. It would really be appreciated.
This is subtle and confusing.

It has build on arm, bfin, lm32, mips, moxie, nios2,
and sparc so far. i386 and m68k have failed. I have about
a half dozen targets left to build.

Thanks


> Craig
>

Re: Possible Issue in ieeefp.h

[Craig Howland]

On 11/21/2016 04:08 PM, Joel Sherrill wrote:
>
>
> On 11/21/2016 2:19 PM, Craig Howland wrote:
>> On 11/21/2016 03:12 PM, Joel Sherrill wrote:
>>>
>>>
>>> On 11/21/2016 12:03 PM, Joel Sherrill wrote:
>>>>
>>>>
>>>> On 11/21/2016 10:52 AM, Craig Howland wrote:
>>>>>
>>>>> ...
>>>>
>>>> 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
>>>
>> No, LDBL_EQ_DBL is supposed to be defined by configure.  That check is also
>> rigorous, not only requiring the mantissa length, but also the exponent range.
>> As a guess, one of the latter two is perhaps missing from your float.h.
>>
>> #include <float.h>
>> #if DBL_MANT_DIG == LDBL_MANT_DIG  &&  LDBL_MIN_EXP == DBL_MIN_EXP  && \
>>      LDBL_MAX_EXP == DBL_MAX_EXP
>>    #define _LDBL_EQ_DBL
>>   #else
>>    #error "LDBL != DBL"
>> #endif
>
> As you expected, that gave the #error. But when I broke
> it apart to see which parts != none tripped. So I
> added this before the error check.
>
> #define JOEL(_x) int joel_## _x = _x;
> JOEL(DBL_MANT_DIG)
> JOEL(LDBL_MANT_DIG)
> JOEL(DBL_MIN_EXP)
> JOEL(LDBL_MIN_EXP)
> JOEL(DBL_MAX_EXP)
> JOEL(LDBL_MAX_EXP)
>
> And got this in the preprocessed output.
>
> int joel_DBL_MANT_DIG = 53;
> int joel_LDBL_MANT_DIG = 64;
> int joel_DBL_MIN_EXP = (-1021);
> int joel_LDBL_MIN_EXP = (-16381);
> int joel_DBL_MAX_EXP = 1024;
> int joel_LDBL_MAX_EXP = 16384;
>
> I'm now confused why this ifdef (line 151) trips:
>
> #elif LDBL_MANT_DIG == DBL_MANT_DIG
>
> That makes even less sense based on this:
>
> $ i386-rtems4.12-gcc -dM -E - </dev/null | grep DBL_MANT_DIG
> #define __LDBL_MANT_DIG__ 64
> #define __DBL_MANT_DIG__ 53
>
> I added parentheses around that #elif and it proceeds on
> the i386 and m68k.
>
> Is the addition of parentheses necessary? That would fix
> one issue if that's OK to add.
This is very odd.  No, the parentheses should not be necessary.  I wonder if it 
is a GCC bug.  But if adding them fixes it, then it's a viable workaround to the 
likely bug.
>
> Further on the two targets that have failed so far.
>
> ========= m68k
> The m68k failed in the same way but DBL and LDBL really
> are the same there on the first multilib that failed.
> The addition of your conditional let the build continue.
>
> But then it failed on what I think it the default
> multilib. The "joel_" values were exactly the same
> as on the i386 above.
>
> ================ i386 failure with addition of parens
> On the i386, there is a harder build failure:
>
> In file included from ../../../../gcc-6-20161110/libgfortran/runtime/fpu.c:29:0:
> ./fpu-target.h: In function 'set_fpu_except_flags':
> ./fpu-target.h:110:7: error: impossible constraint in 'asm'
>        __asm__ __volatile__ ("fdiv\t{%y0, %0|%0, %y0}" : "+t" (f));
>        ^~~~~~~
> ./fpu-target.h:130:7: error: impossible constraint in 'asm'
>        __asm__ __volatile__ ("fdivs\t%1" : "+t" (f) : "m" (g));
>        ^~~~~~~
> ./fpu-target.h:158:7: error: impossible constraint in 'asm'
>        __asm__ __volatile__ ("fdivs\t%1" : "+t" (f) : "m" (g));
>
> Anybody know x86 FP and the constraints enough to fix the
> second problem? It looks like +t is that the top of the FP
> stack is both read and written by some libgfortran target code.
I am not familiar with x86 FP, but did find an i386 note that says "If any input 
operand uses the f constraint, all output reg constraints must use the & 
earlyclobber."  It does make it sound like bad code.  In a very brief search, I 
found https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175, which is the same 
error message, although from a different file.  (Is perhaps this the same issue 
emerging again with a rearrangement of things in GCC 6 vs. 4.8?)
>
>
> This should be reproducible on i386-elf and m68k-elf
> if fortran is enabled. It would really be appreciated.
> This is subtle and confusing.
>
> It has build on arm, bfin, lm32, mips, moxie, nios2,
> and sparc so far. i386 and m68k have failed. I have about
> a half dozen targets left to build.
>
> Thanks
>
>