| Message ID | 20101122130551.GA24469@nightcrawler |
|---|---|
| State | New |
| Headers | show |
On 11/22/2010 05:05 AM, Nathan Froyd wrote: > Just as $SUBJECT suggests. The only target where this could possibly > matter is ARM, since it has a non-trivial implementation of > FLOAT_WORDS_BIG_ENDIAN. However, as discussed in: > > http://gcc.gnu.org/ml/gcc/2010-11/msg00393.html > > the ARM ABI doesn't implement decimal floats (so ARM is not affected by > the libdecnumber/libbid changes) and contains its own custom FP > functions, so any FP-related changes don't matter either. > > Tested on x86_64-unknown-linux-gnu. OK to commit? > > -Nathan > > gcc/ > * cppbuiltin.c (define_builtin_macros_for_type_sizes): Define > __FLOAT_WORD_ORDER__ according to FLOAT_WORDS_BIG_ENDIAN. > * config/dfp-bit.h (LIBGCC2_FLOAT_WORDS_BIG_ENDIAN): Delete. > * doc/cpp.texi (__FLOAT_WORD_ORDER__): Document. > * system.h (LIBGCC2_FLOAT_WORDS_BIG_ENDIAN): Poison. > > libgcc/ > * config/libbid/bid_conf.h (BID_BIG_ENDIAN): Define in terms of > __FLOAT_WORD_ORDER__. > * config/libbid/bid_gcc_intrinsics.h (LIBGCC2_FLOAT_WORDS_BIG_ENDIAN): > Delete. > > libdecnumber/ > * dconfig.h (LIBGCC2_FLOAT_WORDS_BIG_ENDIAN): Delete. > (WORDS_BIG_ENDIAN): Define based on value of __FLOAT_WORD_ORDER__. Ok. r~
Out of interest, would this allow replacing FLOAT_BIT_ORDER_MISMATCH and FLOAT_WORD_ORDER_MISMATCH as used by fp-bit.c? They aren't target macros in that they're defined by makefile rules in t-* files rather than in target headers, but it would still be good to get rid of those ad hoc rules. (I think FLOAT_BIT_ORDER_MISMATCH basically means "this is little-endian" and I'm not sure of the exact semantics of FLOAT_WORD_ORDER_MISMATCH or how it interacts with FLOAT_BIT_ORDER_MISMATCH.)
On Mon, 2010-11-22 at 08:26 -0800, Richard Henderson wrote: > On 11/22/2010 05:05 AM, Nathan Froyd wrote: > > Just as $SUBJECT suggests. The only target where this could possibly > > matter is ARM, since it has a non-trivial implementation of > > FLOAT_WORDS_BIG_ENDIAN. However, as discussed in: > > > > http://gcc.gnu.org/ml/gcc/2010-11/msg00393.html > > > > the ARM ABI doesn't implement decimal floats (so ARM is not affected by > > the libdecnumber/libbid changes) and contains its own custom FP > > functions, so any FP-related changes don't matter either. > > > > Tested on x86_64-unknown-linux-gnu. OK to commit? > > > > -Nathan > > > > gcc/ > > * cppbuiltin.c (define_builtin_macros_for_type_sizes): Define > > __FLOAT_WORD_ORDER__ according to FLOAT_WORDS_BIG_ENDIAN. > > * config/dfp-bit.h (LIBGCC2_FLOAT_WORDS_BIG_ENDIAN): Delete. > > * doc/cpp.texi (__FLOAT_WORD_ORDER__): Document. > > * system.h (LIBGCC2_FLOAT_WORDS_BIG_ENDIAN): Poison. > > > > libgcc/ > > * config/libbid/bid_conf.h (BID_BIG_ENDIAN): Define in terms of > > __FLOAT_WORD_ORDER__. > > * config/libbid/bid_gcc_intrinsics.h (LIBGCC2_FLOAT_WORDS_BIG_ENDIAN): > > Delete. > > > > libdecnumber/ > > * dconfig.h (LIBGCC2_FLOAT_WORDS_BIG_ENDIAN): Delete. > > (WORDS_BIG_ENDIAN): Define based on value of __FLOAT_WORD_ORDER__. > > Ok. Hi, The cppbuiltin.c change likely broke arm bootstrap, the following appeared between rev 167107 and 167167 on my autotester: /home/guerby/build-37/./prev-gcc/xgcc -B/home/guerby/build-37/./prev-gcc/ -B/n/37/guerby/install-trunk-37-167167/armv7l-unknown-linux-gnueabi/bin/ -B/n/37/guerby/install-trunk-37-167167/armv7l-unknown-linux-gnueabi/bin/ -B/n/37/guerb\ y/install-trunk-37-167167/armv7l-unknown-linux-gnueabi/lib/ -isystem /n/37/guerby/install-trunk-37-167167/armv7l-unknown-linux-gnueabi/include -isystem /n/37/guerby/install-trunk-37-167167/armv7l-unknown-linux-gnueabi/sys-include \ -g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definitio\ n -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I/opt/cfarm/gmp-4.2.4/include -I/opt/cfarm/mpfr-2.4.2/include -I/opt/cfarm/mp\ c-0.8/include -I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/dpd -I../libdecnumber \ -DGCC_INCLUDE_DIR=\"/n/37/guerby/install-trunk-37-167167/lib/gcc/armv7l-unknown-linux-gnueabi/4.6.0/include\" -DFIXED_INCLUDE_DIR=\"/n/37/guerby/install-trunk-37-167167/lib/gcc/armv7l-unknown-linux-gnueabi/4.6.0/include-fix\ ed\" -DGPLUSPLUS_INCLUDE_DIR=\"/n/37/guerby/install-trunk-37-167167/lib/gcc/armv7l-unknown-linux-gnueabi/4.6.0/../../../../include/c++/4.6.0\" -DGPLUSPLUS_TOOL_INCLUDE_DIR=\"/n/37/guerby/install-trunk-37-167167/lib/gcc/armv7l-unknown\ -linux-gnueabi/4.6.0/../../../../include/c++/4.6.0/armv7l-unknown-linux-gnueabi\" -DGPLUSPLUS_BACKWARD_INCLUDE_DIR=\"/n/37/guerby/install-trunk-37-167167/lib/gcc/armv7l-unknown-linux-gnueabi/4.6.0/../../../../include/c++/4.6.0/backwa\ rd\" -DLOCAL_INCLUDE_DIR=\"/usr/local/include\" -DCROSS_INCLUDE_DIR=\"/n/37/guerby/install-trunk-37-167167/lib/gcc/armv7l-unknown-linux-gnueabi/4.6.0/../../../../armv7l-unknown-linux-gnueabi/sys-include\" -DTOOL_INCLUDE_DIR=\"/n/37/g\ uerby/install-trunk-37-167167/lib/gcc/armv7l-unknown-linux-gnueabi/4.6.0/../../../../armv7l-unknown-linux-gnueabi/include\" -DPREFIX=\"/n/37/guerby/install-trunk-37-167167/\" -DSTANDARD_EXEC_PREFIX=\"/n/37/guerby/install-trunk-37-167\ 167/lib/gcc/\" -DBASEVER="\"4.6.0\"" \ -c ../../trunk/gcc/cppbuiltin.c -o cppbuiltin.o ../../trunk/gcc/cppbuiltin.c: In function 'define_builtin_macros_for_type_sizes': ../../trunk/gcc/cppbuiltin.c:161:25: error: implicit declaration of function 'arm_float_words_big_endian' [-Werror=implicit-function-declaration] cc1: all warnings being treated as errors make[3]: *** [cppbuiltin.o] Error 1 make[3]: Leaving directory `/home/guerby/build-37/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/guerby/build-37' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/guerby/build-37' make: *** [bootstrap] Error 2 This reminds me of: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44458 Which was about a missing include "tm_p.h". May be there's a better way to fix this once and for all rather than adding another missing include? Sincerely, Laurent
On Sat, Nov 27, 2010 at 09:28:21PM +0100, Laurent GUERBY wrote: > On Mon, 2010-11-22 at 08:26 -0800, Richard Henderson wrote: > > > Tested on x86_64-unknown-linux-gnu. OK to commit? > > > gcc/ > > > * cppbuiltin.c (define_builtin_macros_for_type_sizes): Define > > > __FLOAT_WORD_ORDER__ according to FLOAT_WORDS_BIG_ENDIAN. > > The cppbuiltin.c change likely broke arm bootstrap, the following > appeared between rev 167107 and 167167 on my autotester: > > This reminds me of: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44458 > > Which was about a missing include "tm_p.h". > > May be there's a better way to fix this once and for all > rather than adding another missing include? Sorry about the breakage. I should have double-checked this on ARM. I don't know that there's any better way to fix this at the moment than including tm_p.h in cppbuiltin.c. -Nathan
On Sat, 27 Nov 2010, Nathan Froyd wrote: > > Which was about a missing include "tm_p.h". > > > > May be there's a better way to fix this once and for all > > rather than adding another missing include? > > Sorry about the breakage. I should have double-checked this on ARM. I > don't know that there's any better way to fix this at the moment than > including tm_p.h in cppbuiltin.c. The better way of avoiding a tm_p.h include is usually a target hook conversion of the relevant target macro (FLOAT_WORDS_BIG_ENDIAN). In the present case, the hook already exists purely as a targhooks.c wrapper to the macro; all the remaining users of the macro need to be converted to the hook before any targets can define the hook in place of the macro (but cppbuiltin.c could be changed on its own to use the hook like java/jcf-parse.c, without any of the other changes).
On Sat, Nov 27, 2010 at 11:17:31PM +0000, Joseph S. Myers wrote: > On Sat, 27 Nov 2010, Nathan Froyd wrote: > > Sorry about the breakage. I should have double-checked this on ARM. I > > don't know that there's any better way to fix this at the moment than > > including tm_p.h in cppbuiltin.c. > > The better way of avoiding a tm_p.h include is usually a target hook > conversion of the relevant target macro (FLOAT_WORDS_BIG_ENDIAN). In the > present case, the hook already exists purely as a targhooks.c wrapper to > the macro; all the remaining users of the macro need to be converted to > the hook before any targets can define the hook in place of the macro (but > cppbuiltin.c could be changed on its own to use the hook like > java/jcf-parse.c, without any of the other changes). That would be better. I suppose the concerns about performance impact from TARGET_FLOAT_WORDS_BIG_ENDIAN would be somewhat less than converting BITS_PER_UNIT or WORDS_BIG_ENDIAN. -Nathan
On Sat, 2010-11-27 at 15:57 -0800, Nathan Froyd wrote: > On Sat, Nov 27, 2010 at 11:17:31PM +0000, Joseph S. Myers wrote: > > On Sat, 27 Nov 2010, Nathan Froyd wrote: > > > Sorry about the breakage. I should have double-checked this on ARM. I > > > don't know that there's any better way to fix this at the moment than > > > including tm_p.h in cppbuiltin.c. > > > > The better way of avoiding a tm_p.h include is usually a target hook > > conversion of the relevant target macro (FLOAT_WORDS_BIG_ENDIAN). In the > > present case, the hook already exists purely as a targhooks.c wrapper to > > the macro; all the remaining users of the macro need to be converted to > > the hook before any targets can define the hook in place of the macro (but > > cppbuiltin.c could be changed on its own to use the hook like > > java/jcf-parse.c, without any of the other changes). > > That would be better. I suppose the concerns about performance impact > from TARGET_FLOAT_WORDS_BIG_ENDIAN would be somewhat less than > converting BITS_PER_UNIT or WORDS_BIG_ENDIAN. Hi, Could someone commit at least a temporary fix to restore bootstrap on this platform? Thanks in advance, Laurent PS: is arm-linux considered as a primary platform wrt bootsrap?
On 30/11/2010 16:05, Laurent GUERBY wrote: > > PS: is arm-linux considered as a primary platform wrt bootsrap? arm-linux-gnueabi is on the list. http://gcc.gnu.org/gcc-4.6/criteria.html cheers, DaveK
diff --git a/gcc/config/dfp-bit.h b/gcc/config/dfp-bit.h index 20688b1..c1ee377 100644 --- a/gcc/config/dfp-bit.h +++ b/gcc/config/dfp-bit.h @@ -33,11 +33,6 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #include "coretypes.h" #include "tm.h" -#ifndef LIBGCC2_FLOAT_WORDS_BIG_ENDIAN -#define LIBGCC2_FLOAT_WORDS_BIG_ENDIAN \ - (__BYTE_ORDER__ != __ORDER_LITTLE_ENDIAN__) -#endif - #ifndef LIBGCC2_LONG_DOUBLE_TYPE_SIZE #define LIBGCC2_LONG_DOUBLE_TYPE_SIZE LONG_DOUBLE_TYPE_SIZE #endif diff --git a/gcc/cppbuiltin.c b/gcc/cppbuiltin.c index 7ed6080..f0f650f 100644 --- a/gcc/cppbuiltin.c +++ b/gcc/cppbuiltin.c @@ -157,6 +157,11 @@ define_builtin_macros_for_type_sizes (cpp_reader *pfile) cpp_define (pfile, "__BYTE_ORDER__=__ORDER_PDP_ENDIAN__"); } + cpp_define_formatted (pfile, "__FLOAT_WORD_ORDER__=%s", + (FLOAT_WORDS_BIG_ENDIAN + ? "__ORDER_BIG_ENDIAN__" + : "__ORDER_LITTLE_ENDIAN__")); + /* ptr_type_node can't be used here since ptr_mode is only set when toplev calls backend_init which is not done with -E switch. */ cpp_define_formatted (pfile, "__SIZEOF_POINTER__=%d", diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi index ddcf814..7d78d12 100644 --- a/gcc/doc/cpp.texi +++ b/gcc/doc/cpp.texi @@ -2289,6 +2289,11 @@ You should use these macros for testing like this: #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ @end smallexample +@item __FLOAT_WORD_ORDER__ +@code{__FLOAT_WORD_ORDER__} is defined to one of the values +@code{__ORDER_LITTLE_ENDIAN__} or @code{__ORDER_BIG_ENDIAN__} to reflect +the layout of the words of multi-word floating-point quantities. + @item __DEPRECATED This macro is defined, with value 1, when compiling a C++ source file with warnings about deprecated constructs enabled. These warnings are diff --git a/gcc/system.h b/gcc/system.h index 73e5139..d37ff2a 100644 --- a/gcc/system.h +++ b/gcc/system.h @@ -799,7 +799,8 @@ extern void fancy_abort (const char *, int, const char *) ATTRIBUTE_NORETURN; TARGET_HANDLE_OFAST TARGET_OPTION_OPTIMIZATION /* Hooks into libgcc2. */ - #pragma GCC poison LIBGCC2_DOUBLE_TYPE_SIZE LIBGCC2_WORDS_BIG_ENDIAN + #pragma GCC poison LIBGCC2_DOUBLE_TYPE_SIZE LIBGCC2_WORDS_BIG_ENDIAN \ + LIBGCC2_FLOAT_WORDS_BIG_ENDIAN /* Miscellaneous macros that are no longer used. */ #pragma GCC poison USE_MAPPED_LOCATION diff --git a/libdecnumber/dconfig.h b/libdecnumber/dconfig.h index 26b963c..503cb61 100644 --- a/libdecnumber/dconfig.h +++ b/libdecnumber/dconfig.h @@ -28,12 +28,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #include "coretypes.h" #include "tm.h" -#ifndef LIBGCC2_FLOAT_WORDS_BIG_ENDIAN -#define LIBGCC2_FLOAT_WORDS_BIG_ENDIAN \ - (__BYTE_ORDER__ != __ORDER_LITTLE_ENDIAN__) -#endif - -#if LIBGCC2_FLOAT_WORDS_BIG_ENDIAN +#if __FLOAT_WORD_ORDER__ == __ORDER_BIG_ENDIAN__ #define WORDS_BIGENDIAN 1 #endif diff --git a/libgcc/config/libbid/bid_conf.h b/libgcc/config/libbid/bid_conf.h index d22980d..93e60ed 100644 --- a/libgcc/config/libbid/bid_conf.h +++ b/libgcc/config/libbid/bid_conf.h @@ -516,7 +516,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #endif #ifndef BID_BIG_ENDIAN -#define BID_BIG_ENDIAN LIBGCC2_FLOAT_WORDS_BIG_ENDIAN +#define BID_BIG_ENDIAN __FLOAT_WORD_ORDER__ == __ORDER_BIG_ENDIAN__ #endif #ifndef BID_THREAD diff --git a/libgcc/config/libbid/bid_gcc_intrinsics.h b/libgcc/config/libbid/bid_gcc_intrinsics.h index f536e3b..7d65705 100644 --- a/libgcc/config/libbid/bid_gcc_intrinsics.h +++ b/libgcc/config/libbid/bid_gcc_intrinsics.h @@ -30,11 +30,6 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #include "coretypes.h" #include "tm.h" -#ifndef LIBGCC2_FLOAT_WORDS_BIG_ENDIAN -#define LIBGCC2_FLOAT_WORDS_BIG_ENDIAN \ - (__BYTE_ORDER__ != __ORDER_LITTLE_ENDIAN__) -#endif - #ifndef LIBGCC2_LONG_DOUBLE_TYPE_SIZE #define LIBGCC2_LONG_DOUBLE_TYPE_SIZE LONG_DOUBLE_TYPE_SIZE #endif
Just as $SUBJECT suggests. The only target where this could possibly matter is ARM, since it has a non-trivial implementation of FLOAT_WORDS_BIG_ENDIAN. However, as discussed in: http://gcc.gnu.org/ml/gcc/2010-11/msg00393.html the ARM ABI doesn't implement decimal floats (so ARM is not affected by the libdecnumber/libbid changes) and contains its own custom FP functions, so any FP-related changes don't matter either. Tested on x86_64-unknown-linux-gnu. OK to commit? -Nathan gcc/ * cppbuiltin.c (define_builtin_macros_for_type_sizes): Define __FLOAT_WORD_ORDER__ according to FLOAT_WORDS_BIG_ENDIAN. * config/dfp-bit.h (LIBGCC2_FLOAT_WORDS_BIG_ENDIAN): Delete. * doc/cpp.texi (__FLOAT_WORD_ORDER__): Document. * system.h (LIBGCC2_FLOAT_WORDS_BIG_ENDIAN): Poison. libgcc/ * config/libbid/bid_conf.h (BID_BIG_ENDIAN): Define in terms of __FLOAT_WORD_ORDER__. * config/libbid/bid_gcc_intrinsics.h (LIBGCC2_FLOAT_WORDS_BIG_ENDIAN): Delete. libdecnumber/ * dconfig.h (LIBGCC2_FLOAT_WORDS_BIG_ENDIAN): Delete. (WORDS_BIG_ENDIAN): Define based on value of __FLOAT_WORD_ORDER__.