This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Possible Issue in ieeefp.h



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
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]