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.