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] |
On 11/21/2016 04:08 PM, Joel Sherrill wrote:
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.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. --joelNo, 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" #endifAs 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.
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?)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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |