* Prevent all uses of DFP when unsupported (PR c/91985) @ 2019-11-22 16:47 Joseph Myers 2019-11-23 16:56 ` Jeff Law ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Joseph Myers @ 2019-11-22 16:47 UTC (permalink / raw) To: gcc-patches Code that directly uses _Decimal* types on architectures not supporting DFP is properly diagnosed ("error: decimal floating-point not supported for this target"), via a call to targetm.decimal_float_supported_p, if the _Decimal32, _Decimal64 or _Decimal128 keywords are used to access it. Use via mode attributes is also diagnosed ("unable to emulate 'SD'"); so is use of the FLOAT_CONST_DECIMAL64 pragma. However, it is possible to access those types via typeof applied to constants or built-in functions without such an error. I expect that there are ways to get an ICE from this; certainly it uses a completely undefined ABI. This patch arranges for the types not to exist in the compiler at all when DFP is not supported. As is done with unsupported _FloatN / _FloatNx types, the global tree nodes are left as NULL_TREE, and the built-in function machinery is made to use error_mark_node for them in that case in builtin-types.def, so that the built-in functions are unavailable. Code handling constants is adjusted to give an error, and other code that might not work with the global tree nodes being NULL_TREE is also updated. Bootstrapped with no regressions for x86_64-pc-linux-gnu. Also tested with no regressions for cross to aarch64-linux-gnu, as a configuration without DFP support. OK to commit (the changes that aren't C front-end changes)? gcc: 2019-11-22 Joseph Myers <joseph@codesourcery.com> PR c/91985 * builtin-types.def (BT_DFLOAT32, BT_DFLOAT64, BT_DFLOAT128) (BT_DFLOAT32_PTR, BT_DFLOAT64_PTR, BT_DFLOAT128_PTR): Define to error_mark_node if corresponding global tree node is NULL. * tree.c (build_common_tree_nodes): Do not initialize dfloat32_type_node, dfloat64_type_node or dfloat128_type_node if decimal floating-point not supported. gcc/c: 2019-11-22 Joseph Myers <joseph@codesourcery.com> PR c/91985 * c-decl.c (finish_declspecs): Use int instead of decimal floating-point types if decimal floating-point not supported. gcc/c-family: 2019-11-22 Joseph Myers <joseph@codesourcery.com> PR c/91985 * c-common.c (c_common_type_for_mode): Handle decimal floating-point types being NULL_TREE. * c-format.c (get_format_for_type_1): Handle specified types being NULL_TREE. * c-lex.c (interpret_float): Give an error for decimal floating-point constants when decimal floating-point not supported. gcc/lto: 2019-11-22 Joseph Myers <joseph@codesourcery.com> PR c/91985 * lto-lang.c (lto_type_for_mode): Handle decimal floating-point types being NULL_TREE. gcc/testsuite: 2019-11-22 Joseph Myers <joseph@codesourcery.com> PR c/91985 * gcc.dg/c2x-no-dfp-1.c, gcc.dg/gnu2x-builtins-no-dfp-1.c: New tests. * gcc.dg/fltconst-pedantic-dfp.c: Expect errors when decimal floating-point not supported. Index: gcc/builtin-types.def =================================================================== --- gcc/builtin-types.def (revision 278603) +++ gcc/builtin-types.def (working copy) @@ -136,12 +136,24 @@ DEF_PRIMITIVE_TYPE (BT_WINT, wint_type_node) DEF_PRIMITIVE_TYPE (BT_STRING, string_type_node) DEF_PRIMITIVE_TYPE (BT_CONST_STRING, const_string_type_node) -DEF_PRIMITIVE_TYPE (BT_DFLOAT32, dfloat32_type_node) -DEF_PRIMITIVE_TYPE (BT_DFLOAT64, dfloat64_type_node) -DEF_PRIMITIVE_TYPE (BT_DFLOAT128, dfloat128_type_node) -DEF_PRIMITIVE_TYPE (BT_DFLOAT32_PTR, dfloat32_ptr_type_node) -DEF_PRIMITIVE_TYPE (BT_DFLOAT64_PTR, dfloat64_ptr_type_node) -DEF_PRIMITIVE_TYPE (BT_DFLOAT128_PTR, dfloat128_ptr_type_node) +DEF_PRIMITIVE_TYPE (BT_DFLOAT32, (dfloat32_type_node + ? dfloat32_type_node + : error_mark_node)) +DEF_PRIMITIVE_TYPE (BT_DFLOAT64, (dfloat64_type_node + ? dfloat64_type_node + : error_mark_node)) +DEF_PRIMITIVE_TYPE (BT_DFLOAT128, (dfloat128_type_node + ? dfloat128_type_node + : error_mark_node)) +DEF_PRIMITIVE_TYPE (BT_DFLOAT32_PTR, (dfloat32_ptr_type_node + ? dfloat32_ptr_type_node + : error_mark_node)) +DEF_PRIMITIVE_TYPE (BT_DFLOAT64_PTR, (dfloat64_ptr_type_node + ? dfloat64_ptr_type_node + : error_mark_node)) +DEF_PRIMITIVE_TYPE (BT_DFLOAT128_PTR, (dfloat128_ptr_type_node + ? dfloat128_ptr_type_node + : error_mark_node)) DEF_PRIMITIVE_TYPE (BT_VALIST_REF, va_list_ref_type_node) DEF_PRIMITIVE_TYPE (BT_VALIST_ARG, va_list_arg_type_node) Index: gcc/c/c-decl.c =================================================================== --- gcc/c/c-decl.c (revision 278603) +++ gcc/c/c-decl.c (working copy) @@ -11619,7 +11619,9 @@ finish_declspecs (struct c_declspecs *specs) case cts_dfloat128: gcc_assert (!specs->long_p && !specs->long_long_p && !specs->short_p && !specs->signed_p && !specs->unsigned_p && !specs->complex_p); - if (specs->typespec_word == cts_dfloat32) + if (!targetm.decimal_float_supported_p ()) + specs->type = integer_type_node; + else if (specs->typespec_word == cts_dfloat32) specs->type = dfloat32_type_node; else if (specs->typespec_word == cts_dfloat64) specs->type = dfloat64_type_node; Index: gcc/c-family/c-common.c =================================================================== --- gcc/c-family/c-common.c (revision 278603) +++ gcc/c-family/c-common.c (working copy) @@ -2321,11 +2321,14 @@ c_common_type_for_mode (machine_mode mode, int uns return build_vector_type_for_mode (inner_type, mode); } - if (mode == TYPE_MODE (dfloat32_type_node)) + if (dfloat32_type_node != NULL_TREE + && mode == TYPE_MODE (dfloat32_type_node)) return dfloat32_type_node; - if (mode == TYPE_MODE (dfloat64_type_node)) + if (dfloat64_type_node != NULL_TREE + && mode == TYPE_MODE (dfloat64_type_node)) return dfloat64_type_node; - if (mode == TYPE_MODE (dfloat128_type_node)) + if (dfloat128_type_node != NULL_TREE + && mode == TYPE_MODE (dfloat128_type_node)) return dfloat128_type_node; if (ALL_SCALAR_FIXED_POINT_MODE_P (mode)) Index: gcc/c-family/c-format.c =================================================================== --- gcc/c-family/c-format.c (revision 278603) +++ gcc/c-family/c-format.c (working copy) @@ -4390,7 +4390,7 @@ get_format_for_type_1 (const format_kind_info *fki for (int i = 0; i < FMT_LEN_MAX; i++) { const format_type_detail *ftd = &spec->types[i]; - if (!ftd->type) + if (!ftd->type || *ftd->type == NULL_TREE) continue; if (matching_type_p (*ftd->type, effective_arg_type)) { Index: gcc/c-family/c-lex.c =================================================================== --- gcc/c-family/c-lex.c (revision 278603) +++ gcc/c-family/c-lex.c (working copy) @@ -877,7 +877,12 @@ interpret_float (const cpp_token *token, unsigned /* Decode type based on width and properties. */ if (flags & CPP_N_DFLOAT) - if ((flags & CPP_N_WIDTH) == CPP_N_LARGE) + if (!targetm.decimal_float_supported_p ()) + { + error ("decimal floating-point not supported for this target"); + return error_mark_node; + } + else if ((flags & CPP_N_WIDTH) == CPP_N_LARGE) type = dfloat128_type_node; else if ((flags & CPP_N_WIDTH) == CPP_N_SMALL) type = dfloat32_type_node; Index: gcc/lto/lto-lang.c =================================================================== --- gcc/lto/lto-lang.c (revision 278603) +++ gcc/lto/lto-lang.c (working copy) @@ -1051,11 +1051,14 @@ lto_type_for_mode (machine_mode mode, int unsigned return build_vector_type_for_mode (inner_type, mode); } - if (mode == TYPE_MODE (dfloat32_type_node)) + if (dfloat32_type_node != NULL_TREE + && mode == TYPE_MODE (dfloat32_type_node)) return dfloat32_type_node; - if (mode == TYPE_MODE (dfloat64_type_node)) + if (dfloat64_type_node != NULL_TREE + && mode == TYPE_MODE (dfloat64_type_node)) return dfloat64_type_node; - if (mode == TYPE_MODE (dfloat128_type_node)) + if (dfloat128_type_node != NULL_TREE + && mode == TYPE_MODE (dfloat128_type_node)) return dfloat128_type_node; if (ALL_SCALAR_FIXED_POINT_MODE_P (mode)) Index: gcc/testsuite/gcc.dg/c2x-no-dfp-1.c =================================================================== --- gcc/testsuite/gcc.dg/c2x-no-dfp-1.c (nonexistent) +++ gcc/testsuite/gcc.dg/c2x-no-dfp-1.c (working copy) @@ -0,0 +1,12 @@ +/* Test DFP types and constants rejected if no DFP support. Bug + 91985. */ +/* { dg-do compile { target { ! dfp } } } */ +/* { dg-options "-std=c2x" } */ + +_Decimal32 d32a; /* { dg-error "not supported" } */ +_Decimal64 d64a; /* { dg-error "not supported" } */ +_Decimal128 d128a; /* { dg-error "not supported" } */ + +_Bool d32b = 1.0DF; /* { dg-error "not supported" } */ +_Bool d64b = 1.0DD; /* { dg-error "not supported" } */ +_Bool d128b = 1.0DL; /* { dg-error "not supported" } */ Index: gcc/testsuite/gcc.dg/fltconst-pedantic-dfp.c =================================================================== --- gcc/testsuite/gcc.dg/fltconst-pedantic-dfp.c (revision 278603) +++ gcc/testsuite/gcc.dg/fltconst-pedantic-dfp.c (working copy) @@ -2,5 +2,8 @@ /* { dg-options "-pedantic" } */ double a = 1.dl; /* { dg-warning "decimal float" } */ +/* { dg-error "not supported for this target" "not supported" { target { ! dfp } } .-1 } */ double b = 1.df; /* { dg-warning "decimal float" } */ +/* { dg-error "not supported for this target" "not supported" { target { ! dfp } } .-1 } */ double c = 1.dd; /* { dg-warning "decimal float" } */ +/* { dg-error "not supported for this target" "not supported" { target { ! dfp } } .-1 } */ Index: gcc/testsuite/gcc.dg/gnu2x-builtins-no-dfp-1.c =================================================================== --- gcc/testsuite/gcc.dg/gnu2x-builtins-no-dfp-1.c (nonexistent) +++ gcc/testsuite/gcc.dg/gnu2x-builtins-no-dfp-1.c (working copy) @@ -0,0 +1,18 @@ +/* Test C2x built-in functions: test DFP built-in functions are not + available when no DFP support. Bug 91985. */ +/* { dg-do compile { target { ! dfp } } } */ +/* { dg-options "-std=gnu2x" } */ + +int fabsd32 (void); +int fabsd64 (void); +int fabsd128 (void); +int nand32 (void); +int nand64 (void); +int nand128 (void); + +__typeof__ (__builtin_fabsd32 (0)) d32; /* { dg-warning "implicit" } */ +__typeof__ (__builtin_fabsd64 (0)) d64; /* { dg-warning "implicit" } */ +__typeof__ (__builtin_fabsd128 (0)) d128; /* { dg-warning "implicit" } */ +__typeof__ (__builtin_nand32 (0)) d32n; /* { dg-warning "implicit" } */ +__typeof__ (__builtin_nand64 (0)) d64n; /* { dg-warning "implicit" } */ +__typeof__ (__builtin_nand128 (0)) d128n; /* { dg-warning "implicit" } */ Index: gcc/tree.c =================================================================== --- gcc/tree.c (revision 278603) +++ gcc/tree.c (working copy) @@ -10334,23 +10334,26 @@ build_common_tree_nodes (bool signed_char) uint64_type_node = make_or_reuse_type (64, 1); /* Decimal float types. */ - dfloat32_type_node = make_node (REAL_TYPE); - TYPE_PRECISION (dfloat32_type_node) = DECIMAL32_TYPE_SIZE; - SET_TYPE_MODE (dfloat32_type_node, SDmode); - layout_type (dfloat32_type_node); - dfloat32_ptr_type_node = build_pointer_type (dfloat32_type_node); + if (targetm.decimal_float_supported_p ()) + { + dfloat32_type_node = make_node (REAL_TYPE); + TYPE_PRECISION (dfloat32_type_node) = DECIMAL32_TYPE_SIZE; + SET_TYPE_MODE (dfloat32_type_node, SDmode); + layout_type (dfloat32_type_node); + dfloat32_ptr_type_node = build_pointer_type (dfloat32_type_node); - dfloat64_type_node = make_node (REAL_TYPE); - TYPE_PRECISION (dfloat64_type_node) = DECIMAL64_TYPE_SIZE; - SET_TYPE_MODE (dfloat64_type_node, DDmode); - layout_type (dfloat64_type_node); - dfloat64_ptr_type_node = build_pointer_type (dfloat64_type_node); + dfloat64_type_node = make_node (REAL_TYPE); + TYPE_PRECISION (dfloat64_type_node) = DECIMAL64_TYPE_SIZE; + SET_TYPE_MODE (dfloat64_type_node, DDmode); + layout_type (dfloat64_type_node); + dfloat64_ptr_type_node = build_pointer_type (dfloat64_type_node); - dfloat128_type_node = make_node (REAL_TYPE); - TYPE_PRECISION (dfloat128_type_node) = DECIMAL128_TYPE_SIZE; - SET_TYPE_MODE (dfloat128_type_node, TDmode); - layout_type (dfloat128_type_node); - dfloat128_ptr_type_node = build_pointer_type (dfloat128_type_node); + dfloat128_type_node = make_node (REAL_TYPE); + TYPE_PRECISION (dfloat128_type_node) = DECIMAL128_TYPE_SIZE; + SET_TYPE_MODE (dfloat128_type_node, TDmode); + layout_type (dfloat128_type_node); + dfloat128_ptr_type_node = build_pointer_type (dfloat128_type_node); + } complex_integer_type_node = build_complex_type (integer_type_node, true); complex_float_type_node = build_complex_type (float_type_node, true); -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Prevent all uses of DFP when unsupported (PR c/91985) 2019-11-22 16:47 Prevent all uses of DFP when unsupported (PR c/91985) Joseph Myers @ 2019-11-23 16:56 ` Jeff Law 2019-11-25 20:36 ` Rainer Orth 2019-11-27 21:55 ` Thomas Schwinge 2 siblings, 0 replies; 21+ messages in thread From: Jeff Law @ 2019-11-23 16:56 UTC (permalink / raw) To: Joseph Myers, gcc-patches On 11/22/19 9:40 AM, Joseph Myers wrote: > Code that directly uses _Decimal* types on architectures not > supporting DFP is properly diagnosed ("error: decimal floating-point > not supported for this target"), via a call to > targetm.decimal_float_supported_p, if the _Decimal32, _Decimal64 or > _Decimal128 keywords are used to access it. Use via mode attributes > is also diagnosed ("unable to emulate 'SD'"); so is use of the > FLOAT_CONST_DECIMAL64 pragma. However, it is possible to access those > types via typeof applied to constants or built-in functions without > such an error. I expect that there are ways to get an ICE from this; > certainly it uses a completely undefined ABI. > > This patch arranges for the types not to exist in the compiler at all > when DFP is not supported. As is done with unsupported _FloatN / > _FloatNx types, the global tree nodes are left as NULL_TREE, and the > built-in function machinery is made to use error_mark_node for them in > that case in builtin-types.def, so that the built-in functions are > unavailable. Code handling constants is adjusted to give an error, > and other code that might not work with the global tree nodes being > NULL_TREE is also updated. > > Bootstrapped with no regressions for x86_64-pc-linux-gnu. Also tested > with no regressions for cross to aarch64-linux-gnu, as a configuration > without DFP support. OK to commit (the changes that aren't C front-end > changes)? > > gcc: > 2019-11-22 Joseph Myers <joseph@codesourcery.com> > > PR c/91985 > * builtin-types.def (BT_DFLOAT32, BT_DFLOAT64, BT_DFLOAT128) > (BT_DFLOAT32_PTR, BT_DFLOAT64_PTR, BT_DFLOAT128_PTR): Define to > error_mark_node if corresponding global tree node is NULL. > * tree.c (build_common_tree_nodes): Do not initialize > dfloat32_type_node, dfloat64_type_node or dfloat128_type_node if > decimal floating-point not supported. > > gcc/c: > 2019-11-22 Joseph Myers <joseph@codesourcery.com> > > PR c/91985 > * c-decl.c (finish_declspecs): Use int instead of decimal > floating-point types if decimal floating-point not supported. > > gcc/c-family: > 2019-11-22 Joseph Myers <joseph@codesourcery.com> > > PR c/91985 > * c-common.c (c_common_type_for_mode): Handle decimal > floating-point types being NULL_TREE. > * c-format.c (get_format_for_type_1): Handle specified types being > NULL_TREE. > * c-lex.c (interpret_float): Give an error for decimal > floating-point constants when decimal floating-point not > supported. > > gcc/lto: > 2019-11-22 Joseph Myers <joseph@codesourcery.com> > > PR c/91985 > * lto-lang.c (lto_type_for_mode): Handle decimal floating-point > types being NULL_TREE. > > gcc/testsuite: > 2019-11-22 Joseph Myers <joseph@codesourcery.com> > > PR c/91985 > * gcc.dg/c2x-no-dfp-1.c, gcc.dg/gnu2x-builtins-no-dfp-1.c: New > tests. > * gcc.dg/fltconst-pedantic-dfp.c: Expect errors when decimal > floating-point not supported. OK jeff ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Prevent all uses of DFP when unsupported (PR c/91985) 2019-11-22 16:47 Prevent all uses of DFP when unsupported (PR c/91985) Joseph Myers 2019-11-23 16:56 ` Jeff Law @ 2019-11-25 20:36 ` Rainer Orth 2019-11-26 1:05 ` Joseph Myers 2019-11-26 14:02 ` Andreas Schwab 2019-11-27 21:55 ` Thomas Schwinge 2 siblings, 2 replies; 21+ messages in thread From: Rainer Orth @ 2019-11-25 20:36 UTC (permalink / raw) To: Joseph Myers; +Cc: gcc-patches, Jonathan Wakely Hi Joseph, > Code that directly uses _Decimal* types on architectures not > supporting DFP is properly diagnosed ("error: decimal floating-point > not supported for this target"), via a call to > targetm.decimal_float_supported_p, if the _Decimal32, _Decimal64 or > _Decimal128 keywords are used to access it. Use via mode attributes > is also diagnosed ("unable to emulate 'SD'"); so is use of the > FLOAT_CONST_DECIMAL64 pragma. However, it is possible to access those > types via typeof applied to constants or built-in functions without > such an error. I expect that there are ways to get an ICE from this; > certainly it uses a completely undefined ABI. > > This patch arranges for the types not to exist in the compiler at all > when DFP is not supported. As is done with unsupported _FloatN / > _FloatNx types, the global tree nodes are left as NULL_TREE, and the > built-in function machinery is made to use error_mark_node for them in > that case in builtin-types.def, so that the built-in functions are > unavailable. Code handling constants is adjusted to give an error, > and other code that might not work with the global tree nodes being > NULL_TREE is also updated. > > Bootstrapped with no regressions for x86_64-pc-linux-gnu. Also tested > with no regressions for cross to aarch64-linux-gnu, as a configuration > without DFP support. OK to commit (the changes that aren't C front-end > changes)? AFAICS this caused +FAIL: libstdc++-abi/abi_check on Solaris. In libstdc++.log I find # of added symbols: 0 # of missing symbols: 9 # of undesignated symbols: 0 # of incompatible symbols: 9 9 missing symbols 0 _ZTIDf typeinfo for decimal32 version status: unversioned type: object type size: 8 status: subtracted [...] and a few more, all DFP related. They used to be emitted by g++ for __fundamental_type_info in libsupc++/fundamental_type_info.cc and lived in the CXXABI_1.3.4 version. However, since Solaris *does* lack DFP support, that's no longer the case. I'm uncertain how best to deal with this, however. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Prevent all uses of DFP when unsupported (PR c/91985) 2019-11-25 20:36 ` Rainer Orth @ 2019-11-26 1:05 ` Joseph Myers 2019-11-26 12:21 ` Jonathan Wakely 2019-11-26 14:02 ` Andreas Schwab 1 sibling, 1 reply; 21+ messages in thread From: Joseph Myers @ 2019-11-26 1:05 UTC (permalink / raw) To: Rainer Orth; +Cc: gcc-patches, Jonathan Wakely On Mon, 25 Nov 2019, Rainer Orth wrote: > and a few more, all DFP related. They used to be emitted by g++ for > __fundamental_type_info in libsupc++/fundamental_type_info.cc and lived > in the CXXABI_1.3.4 version. However, since Solaris *does* lack DFP > support, that's no longer the case. I'm uncertain how best to deal with > this, however. As I understand it, _GLIBCXX_USE_DECIMAL_FLOAT should already have been undefined for this target, and so std::decimal::decimal32 etc. should not have been usable (both the header not working without that define, and the mode attributes in the header being rejected by the front end when DFP is unsupported). I.e. such defines in libsupc++ would never have been usable on this target, so I think they are something it should be safe to remove from the ABI baseline. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Prevent all uses of DFP when unsupported (PR c/91985) 2019-11-26 1:05 ` Joseph Myers @ 2019-11-26 12:21 ` Jonathan Wakely 2019-11-27 12:18 ` Rainer Orth 0 siblings, 1 reply; 21+ messages in thread From: Jonathan Wakely @ 2019-11-26 12:21 UTC (permalink / raw) To: Joseph Myers; +Cc: Rainer Orth, gcc-patches On 26/11/19 00:57 +0000, Joseph Myers wrote: >On Mon, 25 Nov 2019, Rainer Orth wrote: > >> and a few more, all DFP related. They used to be emitted by g++ for >> __fundamental_type_info in libsupc++/fundamental_type_info.cc and lived >> in the CXXABI_1.3.4 version. However, since Solaris *does* lack DFP >> support, that's no longer the case. I'm uncertain how best to deal with >> this, however. > >As I understand it, _GLIBCXX_USE_DECIMAL_FLOAT should already have been >undefined for this target, and so std::decimal::decimal32 etc. should not >have been usable (both the header not working without that define, and the >mode attributes in the header being rejected by the front end when DFP is >unsupported). I.e. such defines in libsupc++ would never have been usable >on this target, so I think they are something it should be safe to remove >from the ABI baseline. If it's actually impossible that any real program could have depended on those symbols, then I agree. We could consider adding some useless stubs with those symbol names (as aliases of something else?) so the symbols are still in the library, to keep various tools happy. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Prevent all uses of DFP when unsupported (PR c/91985) 2019-11-26 12:21 ` Jonathan Wakely @ 2019-11-27 12:18 ` Rainer Orth 2019-11-27 17:49 ` Joseph Myers 0 siblings, 1 reply; 21+ messages in thread From: Rainer Orth @ 2019-11-27 12:18 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Joseph Myers, gcc-patches Hi Jonathan, > On 26/11/19 00:57 +0000, Joseph Myers wrote: >>On Mon, 25 Nov 2019, Rainer Orth wrote: >> >>> and a few more, all DFP related. They used to be emitted by g++ for >>> __fundamental_type_info in libsupc++/fundamental_type_info.cc and lived >>> in the CXXABI_1.3.4 version. However, since Solaris *does* lack DFP >>> support, that's no longer the case. I'm uncertain how best to deal with >>> this, however. >> >>As I understand it, _GLIBCXX_USE_DECIMAL_FLOAT should already have been >>undefined for this target, and so std::decimal::decimal32 etc. should not >>have been usable (both the header not working without that define, and the >>mode attributes in the header being rejected by the front end when DFP is >>unsupported). I.e. such defines in libsupc++ would never have been usable >>on this target, so I think they are something it should be safe to remove >>from the ABI baseline. > > If it's actually impossible that any real program could have depended > on those symbols, then I agree. this is exactly what I've got no way of telling, that's why I was asking for guidance. Just removing the DFP symbols from the baselines works, of course. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Prevent all uses of DFP when unsupported (PR c/91985) 2019-11-27 12:18 ` Rainer Orth @ 2019-11-27 17:49 ` Joseph Myers 2019-11-27 18:01 ` Jakub Jelinek 0 siblings, 1 reply; 21+ messages in thread From: Joseph Myers @ 2019-11-27 17:49 UTC (permalink / raw) To: Rainer Orth; +Cc: Jonathan Wakely, gcc-patches On Wed, 27 Nov 2019, Rainer Orth wrote: > Hi Jonathan, > > > On 26/11/19 00:57 +0000, Joseph Myers wrote: > >>On Mon, 25 Nov 2019, Rainer Orth wrote: > >> > >>> and a few more, all DFP related. They used to be emitted by g++ for > >>> __fundamental_type_info in libsupc++/fundamental_type_info.cc and lived > >>> in the CXXABI_1.3.4 version. However, since Solaris *does* lack DFP > >>> support, that's no longer the case. I'm uncertain how best to deal with > >>> this, however. > >> > >>As I understand it, _GLIBCXX_USE_DECIMAL_FLOAT should already have been > >>undefined for this target, and so std::decimal::decimal32 etc. should not > >>have been usable (both the header not working without that define, and the > >>mode attributes in the header being rejected by the front end when DFP is > >>unsupported). I.e. such defines in libsupc++ would never have been usable > >>on this target, so I think they are something it should be safe to remove > >>from the ABI baseline. > > > > If it's actually impossible that any real program could have depended > > on those symbols, then I agree. > > this is exactly what I've got no way of telling, that's why I was asking > for guidance. Just removing the DFP symbols from the baselines works, > of course. I don't think any real program could have used those symbols; it would have required using __typeof (__builtin_fabsd32 (0)) or similar to access types that weren't normally available for those targets (and by accessing the types using builtins like that, you're getting a completely undefined function-calling ABI for them anyway). -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Prevent all uses of DFP when unsupported (PR c/91985) 2019-11-27 17:49 ` Joseph Myers @ 2019-11-27 18:01 ` Jakub Jelinek 2020-01-16 14:49 ` Szabolcs Nagy 0 siblings, 1 reply; 21+ messages in thread From: Jakub Jelinek @ 2019-11-27 18:01 UTC (permalink / raw) To: Joseph Myers; +Cc: Rainer Orth, Jonathan Wakely, gcc-patches On Wed, Nov 27, 2019 at 05:48:21PM +0000, Joseph Myers wrote: > > > On 26/11/19 00:57 +0000, Joseph Myers wrote: > > >>On Mon, 25 Nov 2019, Rainer Orth wrote: > > >> > > >>> and a few more, all DFP related. They used to be emitted by g++ for > > >>> __fundamental_type_info in libsupc++/fundamental_type_info.cc and lived > > >>> in the CXXABI_1.3.4 version. However, since Solaris *does* lack DFP > > >>> support, that's no longer the case. I'm uncertain how best to deal with > > >>> this, however. > > >> > > >>As I understand it, _GLIBCXX_USE_DECIMAL_FLOAT should already have been > > >>undefined for this target, and so std::decimal::decimal32 etc. should not > > >>have been usable (both the header not working without that define, and the > > >>mode attributes in the header being rejected by the front end when DFP is > > >>unsupported). I.e. such defines in libsupc++ would never have been usable > > >>on this target, so I think they are something it should be safe to remove > > >>from the ABI baseline. > > > > > > If it's actually impossible that any real program could have depended > > > on those symbols, then I agree. > > > > this is exactly what I've got no way of telling, that's why I was asking > > for guidance. Just removing the DFP symbols from the baselines works, > > of course. > > I don't think any real program could have used those symbols; it would > have required using __typeof (__builtin_fabsd32 (0)) or similar to access > types that weren't normally available for those targets (and by accessing > the types using builtins like that, you're getting a completely undefined > function-calling ABI for them anyway). I think various tools we use to check ABI will be unhappy about removal of symbols. Can't we on targets that do support aliases and don't support decimal float e.g. alias the DFP rtti symbols to void rtti symbols? Jakub ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Prevent all uses of DFP when unsupported (PR c/91985) 2019-11-27 18:01 ` Jakub Jelinek @ 2020-01-16 14:49 ` Szabolcs Nagy 2020-01-16 14:50 ` Jakub Jelinek 0 siblings, 1 reply; 21+ messages in thread From: Szabolcs Nagy @ 2020-01-16 14:49 UTC (permalink / raw) To: Jakub Jelinek, Joseph Myers; +Cc: nd, Rainer Orth, Jonathan Wakely, gcc-patches On 27/11/2019 18:00, Jakub Jelinek wrote: > On Wed, Nov 27, 2019 at 05:48:21PM +0000, Joseph Myers wrote: >>>> On 26/11/19 00:57 +0000, Joseph Myers wrote: >>>>> On Mon, 25 Nov 2019, Rainer Orth wrote: >>>>> >>>>>> and a few more, all DFP related. They used to be emitted by g++ for >>>>>> __fundamental_type_info in libsupc++/fundamental_type_info.cc and lived >>>>>> in the CXXABI_1.3.4 version. However, since Solaris *does* lack DFP >>>>>> support, that's no longer the case. I'm uncertain how best to deal with >>>>>> this, however. >>>>> >>>>> As I understand it, _GLIBCXX_USE_DECIMAL_FLOAT should already have been >>>>> undefined for this target, and so std::decimal::decimal32 etc. should not >>>>> have been usable (both the header not working without that define, and the >>>>> mode attributes in the header being rejected by the front end when DFP is >>>>> unsupported). I.e. such defines in libsupc++ would never have been usable >>>>> on this target, so I think they are something it should be safe to remove >>>> >from the ABI baseline. >>>> >>>> If it's actually impossible that any real program could have depended >>>> on those symbols, then I agree. >>> >>> this is exactly what I've got no way of telling, that's why I was asking >>> for guidance. Just removing the DFP symbols from the baselines works, >>> of course. >> >> I don't think any real program could have used those symbols; it would >> have required using __typeof (__builtin_fabsd32 (0)) or similar to access >> types that weren't normally available for those targets (and by accessing >> the types using builtins like that, you're getting a completely undefined >> function-calling ABI for them anyway). > > I think various tools we use to check ABI will be unhappy about removal > of symbols. Can't we on targets that do support aliases and don't support > decimal float e.g. alias the DFP rtti symbols to void rtti symbols? what is the expected way to fix this issue? i see hppa-linux-gnu baseline was updated to remove the decimal rtti symbols, but other targets were not. is it better to update the baseline or wait for a generic fix? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Prevent all uses of DFP when unsupported (PR c/91985) 2020-01-16 14:49 ` Szabolcs Nagy @ 2020-01-16 14:50 ` Jakub Jelinek 0 siblings, 0 replies; 21+ messages in thread From: Jakub Jelinek @ 2020-01-16 14:50 UTC (permalink / raw) To: Szabolcs Nagy; +Cc: Joseph Myers, nd, Rainer Orth, Jonathan Wakely, gcc-patches On Thu, Jan 16, 2020 at 02:42:29PM +0000, Szabolcs Nagy wrote: > what is the expected way to fix this issue? > > i see hppa-linux-gnu baseline was updated to remove > the decimal rtti symbols, but other targets were not. > > is it better to update the baseline or wait for a > generic fix? My preference is a generic fix and we have a regression PR about this. Jakub ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Prevent all uses of DFP when unsupported (PR c/91985) 2019-11-25 20:36 ` Rainer Orth 2019-11-26 1:05 ` Joseph Myers @ 2019-11-26 14:02 ` Andreas Schwab 1 sibling, 0 replies; 21+ messages in thread From: Andreas Schwab @ 2019-11-26 14:02 UTC (permalink / raw) To: Rainer Orth; +Cc: Joseph Myers, gcc-patches, Jonathan Wakely On Nov 25 2019, Rainer Orth wrote: > AFAICS this caused > > +FAIL: libstdc++-abi/abi_check > > on Solaris. In libstdc++.log I find That happens on all targets that don't support decimal float. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Prevent all uses of DFP when unsupported (PR c/91985) 2019-11-22 16:47 Prevent all uses of DFP when unsupported (PR c/91985) Joseph Myers 2019-11-23 16:56 ` Jeff Law 2019-11-25 20:36 ` Rainer Orth @ 2019-11-27 21:55 ` Thomas Schwinge 2019-11-27 22:39 ` Joseph Myers 2 siblings, 1 reply; 21+ messages in thread From: Thomas Schwinge @ 2019-11-27 21:55 UTC (permalink / raw) To: Joseph Myers, Julian Brown Cc: gcc-patches, Richard Biener, Jakub Jelinek, Jeff Law [-- Attachment #1: Type: text/plain, Size: 15994 bytes --] Hi! Re <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91985#c4>, which reports (and I hereby confirm) that these changes quoted below introduce "lto1: internal compiler error" for (at least) nvptx offloading, and such a backtrace seemed vaguely familiar, and I did remember having fixed a similar issue before, and indeed it seems to be another instance of such a problem. In particular, and assuming that I'm understanding this correctly, the following part of the changes (for brevity formatted with 'diff --ignore-space-change'): --- gcc/tree.c +++ gcc/tree.c @@ -10334,6 +10334,8 @@ build_common_tree_nodes (bool signed_char) uint64_type_node = make_or_reuse_type (64, 1); /* Decimal float types. */ + if (targetm.decimal_float_supported_p ()) + { dfloat32_type_node = make_node (REAL_TYPE); TYPE_PRECISION (dfloat32_type_node) = DECIMAL32_TYPE_SIZE; SET_TYPE_MODE (dfloat32_type_node, SDmode); @@ -10351,6 +10353,7 @@ build_common_tree_nodes (bool signed_char) SET_TYPE_MODE (dfloat128_type_node, TDmode); layout_type (dfloat128_type_node); dfloat128_ptr_type_node = build_pointer_type (dfloat128_type_node); + } complex_integer_type_node = build_complex_type (integer_type_node, true); complex_float_type_node = build_complex_type (float_type_node, true); ... does introduce a mismatch in the 'preload_common_nodes' between target (for example, x86_64-pc-linux-gnu with 'targetm.decimal_float_supported_p'), and the offload target (for example, nvptx-none without 'targetm.decimal_float_supported_p'), and then LTO read-in explodes because the codes are then offset between producer (target) and consumer (offload target). For reference/context of the previous issue, see <http://mid.mail-archive.com/87twdgb9zi.fsf@hertz.schwinge.homeip.net>, and following messages. If I turn that conditional cited above into 'if (1)', then nvptx offloading testing seems to return to normality, but I have not yet assessed whether that has any ill effects on decimal float types support, and/or how this should be fixed properly. (Julian, please have a look, if you can, or tell me if you're busy with other things.) For reference: On 2019-11-22T16:40:01+0000, Joseph Myers <joseph@codesourcery.com> wrote: > Code that directly uses _Decimal* types on architectures not > supporting DFP is properly diagnosed ("error: decimal floating-point > not supported for this target"), via a call to > targetm.decimal_float_supported_p, if the _Decimal32, _Decimal64 or > _Decimal128 keywords are used to access it. Use via mode attributes > is also diagnosed ("unable to emulate 'SD'"); so is use of the > FLOAT_CONST_DECIMAL64 pragma. However, it is possible to access those > types via typeof applied to constants or built-in functions without > such an error. I expect that there are ways to get an ICE from this; > certainly it uses a completely undefined ABI. > > This patch arranges for the types not to exist in the compiler at all > when DFP is not supported. As is done with unsupported _FloatN / > _FloatNx types, the global tree nodes are left as NULL_TREE, and the > built-in function machinery is made to use error_mark_node for them in > that case in builtin-types.def, so that the built-in functions are > unavailable. Code handling constants is adjusted to give an error, > and other code that might not work with the global tree nodes being > NULL_TREE is also updated. > > Bootstrapped with no regressions for x86_64-pc-linux-gnu. Also tested > with no regressions for cross to aarch64-linux-gnu, as a configuration > without DFP support. OK to commit (the changes that aren't C front-end > changes)? > > gcc: > 2019-11-22 Joseph Myers <joseph@codesourcery.com> > > PR c/91985 > * builtin-types.def (BT_DFLOAT32, BT_DFLOAT64, BT_DFLOAT128) > (BT_DFLOAT32_PTR, BT_DFLOAT64_PTR, BT_DFLOAT128_PTR): Define to > error_mark_node if corresponding global tree node is NULL. > * tree.c (build_common_tree_nodes): Do not initialize > dfloat32_type_node, dfloat64_type_node or dfloat128_type_node if > decimal floating-point not supported. > > gcc/c: > 2019-11-22 Joseph Myers <joseph@codesourcery.com> > > PR c/91985 > * c-decl.c (finish_declspecs): Use int instead of decimal > floating-point types if decimal floating-point not supported. > > gcc/c-family: > 2019-11-22 Joseph Myers <joseph@codesourcery.com> > > PR c/91985 > * c-common.c (c_common_type_for_mode): Handle decimal > floating-point types being NULL_TREE. > * c-format.c (get_format_for_type_1): Handle specified types being > NULL_TREE. > * c-lex.c (interpret_float): Give an error for decimal > floating-point constants when decimal floating-point not > supported. > > gcc/lto: > 2019-11-22 Joseph Myers <joseph@codesourcery.com> > > PR c/91985 > * lto-lang.c (lto_type_for_mode): Handle decimal floating-point > types being NULL_TREE. > > gcc/testsuite: > 2019-11-22 Joseph Myers <joseph@codesourcery.com> > > PR c/91985 > * gcc.dg/c2x-no-dfp-1.c, gcc.dg/gnu2x-builtins-no-dfp-1.c: New > tests. > * gcc.dg/fltconst-pedantic-dfp.c: Expect errors when decimal > floating-point not supported. > > Index: gcc/builtin-types.def > =================================================================== > --- gcc/builtin-types.def (revision 278603) > +++ gcc/builtin-types.def (working copy) > @@ -136,12 +136,24 @@ DEF_PRIMITIVE_TYPE (BT_WINT, wint_type_node) > DEF_PRIMITIVE_TYPE (BT_STRING, string_type_node) > DEF_PRIMITIVE_TYPE (BT_CONST_STRING, const_string_type_node) > > -DEF_PRIMITIVE_TYPE (BT_DFLOAT32, dfloat32_type_node) > -DEF_PRIMITIVE_TYPE (BT_DFLOAT64, dfloat64_type_node) > -DEF_PRIMITIVE_TYPE (BT_DFLOAT128, dfloat128_type_node) > -DEF_PRIMITIVE_TYPE (BT_DFLOAT32_PTR, dfloat32_ptr_type_node) > -DEF_PRIMITIVE_TYPE (BT_DFLOAT64_PTR, dfloat64_ptr_type_node) > -DEF_PRIMITIVE_TYPE (BT_DFLOAT128_PTR, dfloat128_ptr_type_node) > +DEF_PRIMITIVE_TYPE (BT_DFLOAT32, (dfloat32_type_node > + ? dfloat32_type_node > + : error_mark_node)) > +DEF_PRIMITIVE_TYPE (BT_DFLOAT64, (dfloat64_type_node > + ? dfloat64_type_node > + : error_mark_node)) > +DEF_PRIMITIVE_TYPE (BT_DFLOAT128, (dfloat128_type_node > + ? dfloat128_type_node > + : error_mark_node)) > +DEF_PRIMITIVE_TYPE (BT_DFLOAT32_PTR, (dfloat32_ptr_type_node > + ? dfloat32_ptr_type_node > + : error_mark_node)) > +DEF_PRIMITIVE_TYPE (BT_DFLOAT64_PTR, (dfloat64_ptr_type_node > + ? dfloat64_ptr_type_node > + : error_mark_node)) > +DEF_PRIMITIVE_TYPE (BT_DFLOAT128_PTR, (dfloat128_ptr_type_node > + ? dfloat128_ptr_type_node > + : error_mark_node)) > > DEF_PRIMITIVE_TYPE (BT_VALIST_REF, va_list_ref_type_node) > DEF_PRIMITIVE_TYPE (BT_VALIST_ARG, va_list_arg_type_node) > Index: gcc/c/c-decl.c > =================================================================== > --- gcc/c/c-decl.c (revision 278603) > +++ gcc/c/c-decl.c (working copy) > @@ -11619,7 +11619,9 @@ finish_declspecs (struct c_declspecs *specs) > case cts_dfloat128: > gcc_assert (!specs->long_p && !specs->long_long_p && !specs->short_p > && !specs->signed_p && !specs->unsigned_p && !specs->complex_p); > - if (specs->typespec_word == cts_dfloat32) > + if (!targetm.decimal_float_supported_p ()) > + specs->type = integer_type_node; > + else if (specs->typespec_word == cts_dfloat32) > specs->type = dfloat32_type_node; > else if (specs->typespec_word == cts_dfloat64) > specs->type = dfloat64_type_node; > Index: gcc/c-family/c-common.c > =================================================================== > --- gcc/c-family/c-common.c (revision 278603) > +++ gcc/c-family/c-common.c (working copy) > @@ -2321,11 +2321,14 @@ c_common_type_for_mode (machine_mode mode, int uns > return build_vector_type_for_mode (inner_type, mode); > } > > - if (mode == TYPE_MODE (dfloat32_type_node)) > + if (dfloat32_type_node != NULL_TREE > + && mode == TYPE_MODE (dfloat32_type_node)) > return dfloat32_type_node; > - if (mode == TYPE_MODE (dfloat64_type_node)) > + if (dfloat64_type_node != NULL_TREE > + && mode == TYPE_MODE (dfloat64_type_node)) > return dfloat64_type_node; > - if (mode == TYPE_MODE (dfloat128_type_node)) > + if (dfloat128_type_node != NULL_TREE > + && mode == TYPE_MODE (dfloat128_type_node)) > return dfloat128_type_node; > > if (ALL_SCALAR_FIXED_POINT_MODE_P (mode)) > Index: gcc/c-family/c-format.c > =================================================================== > --- gcc/c-family/c-format.c (revision 278603) > +++ gcc/c-family/c-format.c (working copy) > @@ -4390,7 +4390,7 @@ get_format_for_type_1 (const format_kind_info *fki > for (int i = 0; i < FMT_LEN_MAX; i++) > { > const format_type_detail *ftd = &spec->types[i]; > - if (!ftd->type) > + if (!ftd->type || *ftd->type == NULL_TREE) > continue; > if (matching_type_p (*ftd->type, effective_arg_type)) > { > Index: gcc/c-family/c-lex.c > =================================================================== > --- gcc/c-family/c-lex.c (revision 278603) > +++ gcc/c-family/c-lex.c (working copy) > @@ -877,7 +877,12 @@ interpret_float (const cpp_token *token, unsigned > > /* Decode type based on width and properties. */ > if (flags & CPP_N_DFLOAT) > - if ((flags & CPP_N_WIDTH) == CPP_N_LARGE) > + if (!targetm.decimal_float_supported_p ()) > + { > + error ("decimal floating-point not supported for this target"); > + return error_mark_node; > + } > + else if ((flags & CPP_N_WIDTH) == CPP_N_LARGE) > type = dfloat128_type_node; > else if ((flags & CPP_N_WIDTH) == CPP_N_SMALL) > type = dfloat32_type_node; > Index: gcc/lto/lto-lang.c > =================================================================== > --- gcc/lto/lto-lang.c (revision 278603) > +++ gcc/lto/lto-lang.c (working copy) > @@ -1051,11 +1051,14 @@ lto_type_for_mode (machine_mode mode, int unsigned > return build_vector_type_for_mode (inner_type, mode); > } > > - if (mode == TYPE_MODE (dfloat32_type_node)) > + if (dfloat32_type_node != NULL_TREE > + && mode == TYPE_MODE (dfloat32_type_node)) > return dfloat32_type_node; > - if (mode == TYPE_MODE (dfloat64_type_node)) > + if (dfloat64_type_node != NULL_TREE > + && mode == TYPE_MODE (dfloat64_type_node)) > return dfloat64_type_node; > - if (mode == TYPE_MODE (dfloat128_type_node)) > + if (dfloat128_type_node != NULL_TREE > + && mode == TYPE_MODE (dfloat128_type_node)) > return dfloat128_type_node; > > if (ALL_SCALAR_FIXED_POINT_MODE_P (mode)) > Index: gcc/testsuite/gcc.dg/c2x-no-dfp-1.c > =================================================================== > --- gcc/testsuite/gcc.dg/c2x-no-dfp-1.c (nonexistent) > +++ gcc/testsuite/gcc.dg/c2x-no-dfp-1.c (working copy) > @@ -0,0 +1,12 @@ > +/* Test DFP types and constants rejected if no DFP support. Bug > + 91985. */ > +/* { dg-do compile { target { ! dfp } } } */ > +/* { dg-options "-std=c2x" } */ > + > +_Decimal32 d32a; /* { dg-error "not supported" } */ > +_Decimal64 d64a; /* { dg-error "not supported" } */ > +_Decimal128 d128a; /* { dg-error "not supported" } */ > + > +_Bool d32b = 1.0DF; /* { dg-error "not supported" } */ > +_Bool d64b = 1.0DD; /* { dg-error "not supported" } */ > +_Bool d128b = 1.0DL; /* { dg-error "not supported" } */ > Index: gcc/testsuite/gcc.dg/fltconst-pedantic-dfp.c > =================================================================== > --- gcc/testsuite/gcc.dg/fltconst-pedantic-dfp.c (revision 278603) > +++ gcc/testsuite/gcc.dg/fltconst-pedantic-dfp.c (working copy) > @@ -2,5 +2,8 @@ > /* { dg-options "-pedantic" } */ > > double a = 1.dl; /* { dg-warning "decimal float" } */ > +/* { dg-error "not supported for this target" "not supported" { target { ! dfp } } .-1 } */ > double b = 1.df; /* { dg-warning "decimal float" } */ > +/* { dg-error "not supported for this target" "not supported" { target { ! dfp } } .-1 } */ > double c = 1.dd; /* { dg-warning "decimal float" } */ > +/* { dg-error "not supported for this target" "not supported" { target { ! dfp } } .-1 } */ > Index: gcc/testsuite/gcc.dg/gnu2x-builtins-no-dfp-1.c > =================================================================== > --- gcc/testsuite/gcc.dg/gnu2x-builtins-no-dfp-1.c (nonexistent) > +++ gcc/testsuite/gcc.dg/gnu2x-builtins-no-dfp-1.c (working copy) > @@ -0,0 +1,18 @@ > +/* Test C2x built-in functions: test DFP built-in functions are not > + available when no DFP support. Bug 91985. */ > +/* { dg-do compile { target { ! dfp } } } */ > +/* { dg-options "-std=gnu2x" } */ > + > +int fabsd32 (void); > +int fabsd64 (void); > +int fabsd128 (void); > +int nand32 (void); > +int nand64 (void); > +int nand128 (void); > + > +__typeof__ (__builtin_fabsd32 (0)) d32; /* { dg-warning "implicit" } */ > +__typeof__ (__builtin_fabsd64 (0)) d64; /* { dg-warning "implicit" } */ > +__typeof__ (__builtin_fabsd128 (0)) d128; /* { dg-warning "implicit" } */ > +__typeof__ (__builtin_nand32 (0)) d32n; /* { dg-warning "implicit" } */ > +__typeof__ (__builtin_nand64 (0)) d64n; /* { dg-warning "implicit" } */ > +__typeof__ (__builtin_nand128 (0)) d128n; /* { dg-warning "implicit" } */ > Index: gcc/tree.c > =================================================================== > --- gcc/tree.c (revision 278603) > +++ gcc/tree.c (working copy) > @@ -10334,23 +10334,26 @@ build_common_tree_nodes (bool signed_char) > uint64_type_node = make_or_reuse_type (64, 1); > > /* Decimal float types. */ > - dfloat32_type_node = make_node (REAL_TYPE); > - TYPE_PRECISION (dfloat32_type_node) = DECIMAL32_TYPE_SIZE; > - SET_TYPE_MODE (dfloat32_type_node, SDmode); > - layout_type (dfloat32_type_node); > - dfloat32_ptr_type_node = build_pointer_type (dfloat32_type_node); > + if (targetm.decimal_float_supported_p ()) > + { > + dfloat32_type_node = make_node (REAL_TYPE); > + TYPE_PRECISION (dfloat32_type_node) = DECIMAL32_TYPE_SIZE; > + SET_TYPE_MODE (dfloat32_type_node, SDmode); > + layout_type (dfloat32_type_node); > + dfloat32_ptr_type_node = build_pointer_type (dfloat32_type_node); > > - dfloat64_type_node = make_node (REAL_TYPE); > - TYPE_PRECISION (dfloat64_type_node) = DECIMAL64_TYPE_SIZE; > - SET_TYPE_MODE (dfloat64_type_node, DDmode); > - layout_type (dfloat64_type_node); > - dfloat64_ptr_type_node = build_pointer_type (dfloat64_type_node); > + dfloat64_type_node = make_node (REAL_TYPE); > + TYPE_PRECISION (dfloat64_type_node) = DECIMAL64_TYPE_SIZE; > + SET_TYPE_MODE (dfloat64_type_node, DDmode); > + layout_type (dfloat64_type_node); > + dfloat64_ptr_type_node = build_pointer_type (dfloat64_type_node); > > - dfloat128_type_node = make_node (REAL_TYPE); > - TYPE_PRECISION (dfloat128_type_node) = DECIMAL128_TYPE_SIZE; > - SET_TYPE_MODE (dfloat128_type_node, TDmode); > - layout_type (dfloat128_type_node); > - dfloat128_ptr_type_node = build_pointer_type (dfloat128_type_node); > + dfloat128_type_node = make_node (REAL_TYPE); > + TYPE_PRECISION (dfloat128_type_node) = DECIMAL128_TYPE_SIZE; > + SET_TYPE_MODE (dfloat128_type_node, TDmode); > + layout_type (dfloat128_type_node); > + dfloat128_ptr_type_node = build_pointer_type (dfloat128_type_node); > + } > > complex_integer_type_node = build_complex_type (integer_type_node, true); > complex_float_type_node = build_complex_type (float_type_node, true); Grüße Thomas [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 658 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Prevent all uses of DFP when unsupported (PR c/91985) 2019-11-27 21:55 ` Thomas Schwinge @ 2019-11-27 22:39 ` Joseph Myers 2019-11-28 14:22 ` Thomas Schwinge 0 siblings, 1 reply; 21+ messages in thread From: Joseph Myers @ 2019-11-27 22:39 UTC (permalink / raw) To: Thomas Schwinge Cc: Julian Brown, gcc-patches, Richard Biener, Jakub Jelinek, Jeff Law On Wed, 27 Nov 2019, Thomas Schwinge wrote: > If I turn that conditional cited above into 'if (1)', then nvptx > offloading testing seems to return to normality, but I have not yet > assessed whether that has any ill effects on decimal float types support, > and/or how this should be fixed properly. (Julian, please have a look, > if you can, or tell me if you're busy with other things.) Whatever allows this to work for _FloatN types (when x86_64 supports _Float128 but nxptx doesn't, for example) should be applied to the DFP types as well. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Prevent all uses of DFP when unsupported (PR c/91985) 2019-11-27 22:39 ` Joseph Myers @ 2019-11-28 14:22 ` Thomas Schwinge 2019-11-28 14:44 ` [PATCH] Fix decimal floating-point LTO streaming for offloading compilation Julian Brown 0 siblings, 1 reply; 21+ messages in thread From: Thomas Schwinge @ 2019-11-28 14:22 UTC (permalink / raw) To: Julian Brown, Joseph Myers Cc: gcc-patches, Richard Biener, Jakub Jelinek, Jeff Law, Kwok Cheung Yeung [-- Attachment #1.1: Type: text/plain, Size: 1267 bytes --] Hi! So, testing just finished, and indeed: On 2019-11-27T22:33:25+0000, Joseph Myers <joseph@codesourcery.com> wrote: > On Wed, 27 Nov 2019, Thomas Schwinge wrote: > >> If I turn that conditional cited above into 'if (1)', then nvptx >> offloading testing seems to return to normality, but I have not yet >> assessed whether that has any ill effects on decimal float types support, ... this (see attached) doesn't disturb x86_64-pc-linux-gnu (with nvptx offloading) as well as powerpc64le-unknown-linux-gnu (without offloading) tests in any way. >> and/or how this should be fixed properly. (Julian, please have a look, >> if you can, or tell me if you're busy with other things.) > > Whatever allows this to work for _FloatN types (when x86_64 supports > _Float128 but nxptx doesn't, for example) should be applied to the DFP > types as well. Joseph, Julian, or anyone else, please review if that's (conceptually) the correct fix, and before commit, I'll then remove the 'if' conditional, and re-indent, obviously. If approving this patch (conceptually), please respond with "Reviewed-by: NAME <EMAIL>" so that your effort will be recorded in the commit log, see <https://gcc.gnu.org/wiki/Reviewed-by>. Grüße Thomas [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.2: 0001-WIP-Unconditionally-enable-decimal-float-types.trunk.patch --] [-- Type: text/x-diff, Size: 845 bytes --] From 272dfd2d0bd05ca32a12a3d30ea2871030e5d784 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge <tschwing@mentor.com> Date: Thu, 28 Nov 2019 09:17:57 +0100 Subject: [PATCH] WIP Unconditionally enable decimal float types in 'gcc/tree.c:build_common_tree_nodes' --- gcc/tree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/tree.c b/gcc/tree.c index 5ae250ee595..d61496518fa 100644 --- a/gcc/tree.c +++ b/gcc/tree.c @@ -10334,7 +10334,7 @@ build_common_tree_nodes (bool signed_char) uint64_type_node = make_or_reuse_type (64, 1); /* Decimal float types. */ - if (targetm.decimal_float_supported_p ()) + if (1 || targetm.decimal_float_supported_p ()) { dfloat32_type_node = make_node (REAL_TYPE); TYPE_PRECISION (dfloat32_type_node) = DECIMAL32_TYPE_SIZE; -- 2.17.1 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 658 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH] Fix decimal floating-point LTO streaming for offloading compilation @ 2019-11-28 14:44 ` Julian Brown 2019-11-28 15:15 ` Joseph Myers 2019-11-28 15:23 ` Thomas Schwinge 0 siblings, 2 replies; 21+ messages in thread From: Julian Brown @ 2019-11-28 14:44 UTC (permalink / raw) To: gcc-patches, Joseph Myers, Thomas Schwinge [-- Attachment #1: Type: text/plain, Size: 1664 bytes --] As mentioned in PR91985, offloading compilation is broken at present because of an issue with LTO streaming. With thanks to Joseph for hints, here's a solution. Unlike e.g. the _FloatN types, when decimal floating-point types are enabled, common tree nodes are created for each float type size (e.g. dfloat32_type_node) and also a pointer to each type is created (e.g. dfloat32_ptr_type_node). tree-streamer.c:record_common_node emits these like: <float:32> (dfloat32_type_node) <float:64> (dfloat64_type_node) <float:128> (dfloat128_type_node) <float:32> * (dfloat32_ptr_type_node) <float:32> <float:64> * (dfloat64_ptr_type_node) <float:64> <float:128> * (dfloat128_ptr_type_node) <float:128> I.e., with explicit emission of a copy of the pointed-to type following the pointer itself. When DFP is disabled, we instead get: <<< error >>> <<< error >>> <<< error >>> <<< error >>> <<< error >>> <<< error >>> So, the number of nodes emitted during LTO write-out in the host/read-in in the offload compiler do not match. This patch restores the number of nodes emitted by creating dfloatN_ptr_type_node as generic pointers rather than treating them as flat error_type_nodes. I don't think there's an easy way of creating an "error_type_node *", nor do I know if that would really be preferable. Tested with offloading to NVPTX & bootstrapped. OK to apply? Thanks, Julian ChangeLog gcc/ * tree.c (build_common_tree_nodes): Use pointer type for dfloat32_ptr_type_node, dfloat64_ptr_type_node and dfloat128_ptr_type_node when decimal floating point support is disabled. [-- Attachment #2: fix-dfp-lto-streaming-1.diff --] [-- Type: text/x-patch, Size: 1253 bytes --] commit 17119773a8a45af098364b4faafe68f2e868479a Author: Julian Brown <julian@codesourcery.com> Date: Wed Nov 27 18:41:56 2019 -0800 Fix decimal floating-point LTO streaming for offloading compilation gcc/ * tree.c (build_common_tree_nodes): Use pointer type for dfloat32_ptr_type_node, dfloat64_ptr_type_node and dfloat128_ptr_type_node when decimal floating point support is disabled. diff --git a/gcc/tree.c b/gcc/tree.c index 5ae250ee595..db3f225ea7f 100644 --- a/gcc/tree.c +++ b/gcc/tree.c @@ -10354,6 +10354,15 @@ build_common_tree_nodes (bool signed_char) layout_type (dfloat128_type_node); dfloat128_ptr_type_node = build_pointer_type (dfloat128_type_node); } + else + { + /* These must be pointers else tree-streamer.c:record_common_node will emit + a different number of nodes depending on DFP availability, which breaks + offloading compilation. */ + dfloat32_ptr_type_node = ptr_type_node; + dfloat64_ptr_type_node = ptr_type_node; + dfloat128_ptr_type_node = ptr_type_node; + } complex_integer_type_node = build_complex_type (integer_type_node, true); complex_float_type_node = build_complex_type (float_type_node, true); ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Fix decimal floating-point LTO streaming for offloading compilation 2019-11-28 14:44 ` [PATCH] Fix decimal floating-point LTO streaming for offloading compilation Julian Brown @ 2019-11-28 15:15 ` Joseph Myers 2019-11-28 15:45 ` Segher Boessenkool ` (2 more replies) 2019-11-28 15:23 ` Thomas Schwinge 1 sibling, 3 replies; 21+ messages in thread From: Joseph Myers @ 2019-11-28 15:15 UTC (permalink / raw) To: Julian Brown; +Cc: gcc-patches, Thomas Schwinge On Thu, 28 Nov 2019, Julian Brown wrote: > Unlike e.g. the _FloatN types, when decimal floating-point types are > enabled, common tree nodes are created for each float type size (e.g. > dfloat32_type_node) and also a pointer to each type is created > (e.g. dfloat32_ptr_type_node). tree-streamer.c:record_common_node emits > these like: As far as I can tell, nothing actually uses those pointer nodes, or the corresponding BT_DFLOAT32_PTR etc. defined in builtin-types.def. I don't know if they ever were used, or if they were just added by analogy to e.g. float_ptr_type_node. So I'd suggest simply removing all references to those tree nodes and corresponding BT_*, from builtin-types.def, jit/jit-builtins.c (commented out), tree-core.h, tree.c, tree.h. Hopefully that will solve the offloading problem. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Fix decimal floating-point LTO streaming for offloading compilation 2019-11-28 15:15 ` Joseph Myers @ 2019-11-28 15:45 ` Segher Boessenkool 2019-11-28 18:25 ` Julian Brown 2019-11-28 19:45 ` Richard Biener 2 siblings, 0 replies; 21+ messages in thread From: Segher Boessenkool @ 2019-11-28 15:45 UTC (permalink / raw) To: Joseph Myers; +Cc: Julian Brown, gcc-patches, Thomas Schwinge Hi Joseph, On Thu, Nov 28, 2019 at 03:04:05PM +0000, Joseph Myers wrote: > On Thu, 28 Nov 2019, Julian Brown wrote: > > Unlike e.g. the _FloatN types, when decimal floating-point types are > > enabled, common tree nodes are created for each float type size (e.g. > > dfloat32_type_node) and also a pointer to each type is created > > (e.g. dfloat32_ptr_type_node). tree-streamer.c:record_common_node emits > > these like: > > As far as I can tell, nothing actually uses those pointer nodes, or the > corresponding BT_DFLOAT32_PTR etc. defined in builtin-types.def. I don't > know if they ever were used, or if they were just added by analogy to e.g. > float_ptr_type_node. > > So I'd suggest simply removing all references to those tree nodes and > corresponding BT_*, from builtin-types.def, jit/jit-builtins.c (commented > out), tree-core.h, tree.c, tree.h. Hopefully that will solve the > offloading problem. So your patch caused at least three problems, none of them completely worked out yet, none of them trivial. Maybe this isn't such a good idea during stage 3. Segher ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Fix decimal floating-point LTO streaming for offloading compilation 2019-11-28 15:15 ` Joseph Myers 2019-11-28 15:45 ` Segher Boessenkool @ 2019-11-28 18:25 ` Julian Brown 2019-11-28 19:22 ` Joseph Myers 2019-11-28 19:45 ` Richard Biener 2 siblings, 1 reply; 21+ messages in thread From: Julian Brown @ 2019-11-28 18:25 UTC (permalink / raw) To: Joseph Myers; +Cc: gcc-patches, Thomas Schwinge, Segher Boessenkool [-- Attachment #1: Type: text/plain, Size: 1679 bytes --] On Thu, 28 Nov 2019 15:04:05 +0000 Joseph Myers <joseph@codesourcery.com> wrote: > On Thu, 28 Nov 2019, Julian Brown wrote: > > > Unlike e.g. the _FloatN types, when decimal floating-point types are > > enabled, common tree nodes are created for each float type size > > (e.g. dfloat32_type_node) and also a pointer to each type is created > > (e.g. dfloat32_ptr_type_node). tree-streamer.c:record_common_node > > emits these like: > > As far as I can tell, nothing actually uses those pointer nodes, or > the corresponding BT_DFLOAT32_PTR etc. defined in builtin-types.def. > I don't know if they ever were used, or if they were just added by > analogy to e.g. float_ptr_type_node. > > So I'd suggest simply removing all references to those tree nodes and > corresponding BT_*, from builtin-types.def, jit/jit-builtins.c > (commented out), tree-core.h, tree.c, tree.h. Hopefully that will > solve the offloading problem. Thanks for review. How about this (lightly retested so far), assuming it passes full testing/bootstrap? Thanks, Julian ChangeLog gcc/ * builtin-types.def (BT_DFLOAT32_PTR, BT_DFLOAT64_PTR, BT_DFLOAT128_PTR) Remove. * tree-core.h (TI_DFLOAT32_PTR_TYPE, TI_DFLOAT64_PTR_TYPE, TI_DFLOAT128_PTR_TYPE): Remove. * tree.c (build_common_type_nodes): Remove dfloat32_ptr_type_node, dfloat64_ptr_type_node and dfloat128_ptr_type_node initialisation. * tree.h (dfloat32_ptr_type_node, dfloat64_ptr_type_node, dfloat128_ptr_type_node): Remove macros. gcc/jit/ * jit-builtins.c (BT_DFLOAT32_PTR, BT_DFLOAT64_PTR, BT_DFLOAT128_PTR): Remove commented-out cases. [-- Attachment #2: remove-dfp-ptr-type-nodes-1.diff --] [-- Type: text/x-patch, Size: 4339 bytes --] commit 80f69450724dbbf944a0d1e62e3ca6bdc3dd5a82 Author: Julian Brown <julian@codesourcery.com> Date: Wed Nov 27 18:41:56 2019 -0800 Remove unused decimal floating-point pointer types gcc/ * builtin-types.def (BT_DFLOAT32_PTR, BT_DFLOAT64_PTR, BT_DFLOAT128_PTR) Remove. * tree-core.h (TI_DFLOAT32_PTR_TYPE, TI_DFLOAT64_PTR_TYPE, TI_DFLOAT128_PTR_TYPE): Remove. * tree.c (build_common_type_nodes): Remove dfloat32_ptr_type_node, dfloat64_ptr_type_node and dfloat128_ptr_type_node initialisation. * tree.h (dfloat32_ptr_type_node, dfloat64_ptr_type_node, dfloat128_ptr_type_node): Remove macros. gcc/jit/ * jit-builtins.c (BT_DFLOAT32_PTR, BT_DFLOAT64_PTR, BT_DFLOAT128_PTR): Remove commented-out cases. diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def index 800b751de6d..2611e88da60 100644 --- a/gcc/builtin-types.def +++ b/gcc/builtin-types.def @@ -145,15 +145,6 @@ DEF_PRIMITIVE_TYPE (BT_DFLOAT64, (dfloat64_type_node DEF_PRIMITIVE_TYPE (BT_DFLOAT128, (dfloat128_type_node ? dfloat128_type_node : error_mark_node)) -DEF_PRIMITIVE_TYPE (BT_DFLOAT32_PTR, (dfloat32_ptr_type_node - ? dfloat32_ptr_type_node - : error_mark_node)) -DEF_PRIMITIVE_TYPE (BT_DFLOAT64_PTR, (dfloat64_ptr_type_node - ? dfloat64_ptr_type_node - : error_mark_node)) -DEF_PRIMITIVE_TYPE (BT_DFLOAT128_PTR, (dfloat128_ptr_type_node - ? dfloat128_ptr_type_node - : error_mark_node)) DEF_PRIMITIVE_TYPE (BT_VALIST_REF, va_list_ref_type_node) DEF_PRIMITIVE_TYPE (BT_VALIST_ARG, va_list_arg_type_node) diff --git a/gcc/jit/jit-builtins.c b/gcc/jit/jit-builtins.c index 850329c7b36..93d48c64c40 100644 --- a/gcc/jit/jit-builtins.c +++ b/gcc/jit/jit-builtins.c @@ -434,9 +434,6 @@ builtins_manager::make_primitive_type (enum jit_builtin_type type_id) // case BT_DFLOAT32: // case BT_DFLOAT64: // case BT_DFLOAT128: - // case BT_DFLOAT32_PTR: - // case BT_DFLOAT64_PTR: - // case BT_DFLOAT128_PTR: // case BT_VALIST_REF: // case BT_VALIST_ARG: // case BT_I1: diff --git a/gcc/tree-core.h b/gcc/tree-core.h index 12e078882da..f76f68d835d 100644 --- a/gcc/tree-core.h +++ b/gcc/tree-core.h @@ -695,9 +695,6 @@ enum tree_index { TI_DFLOAT32_TYPE, TI_DFLOAT64_TYPE, TI_DFLOAT128_TYPE, - TI_DFLOAT32_PTR_TYPE, - TI_DFLOAT64_PTR_TYPE, - TI_DFLOAT128_PTR_TYPE, TI_VOID_LIST_NODE, diff --git a/gcc/tree.c b/gcc/tree.c index 5ae250ee595..789f0a00f41 100644 --- a/gcc/tree.c +++ b/gcc/tree.c @@ -10340,19 +10340,16 @@ build_common_tree_nodes (bool signed_char) TYPE_PRECISION (dfloat32_type_node) = DECIMAL32_TYPE_SIZE; SET_TYPE_MODE (dfloat32_type_node, SDmode); layout_type (dfloat32_type_node); - dfloat32_ptr_type_node = build_pointer_type (dfloat32_type_node); dfloat64_type_node = make_node (REAL_TYPE); TYPE_PRECISION (dfloat64_type_node) = DECIMAL64_TYPE_SIZE; SET_TYPE_MODE (dfloat64_type_node, DDmode); layout_type (dfloat64_type_node); - dfloat64_ptr_type_node = build_pointer_type (dfloat64_type_node); dfloat128_type_node = make_node (REAL_TYPE); TYPE_PRECISION (dfloat128_type_node) = DECIMAL128_TYPE_SIZE; SET_TYPE_MODE (dfloat128_type_node, TDmode); layout_type (dfloat128_type_node); - dfloat128_ptr_type_node = build_pointer_type (dfloat128_type_node); } complex_integer_type_node = build_complex_type (integer_type_node, true); diff --git a/gcc/tree.h b/gcc/tree.h index 60b6eae7b04..0f3cc5d7e5a 100644 --- a/gcc/tree.h +++ b/gcc/tree.h @@ -4098,9 +4098,6 @@ tree_strip_any_location_wrapper (tree exp) #define dfloat32_type_node global_trees[TI_DFLOAT32_TYPE] #define dfloat64_type_node global_trees[TI_DFLOAT64_TYPE] #define dfloat128_type_node global_trees[TI_DFLOAT128_TYPE] -#define dfloat32_ptr_type_node global_trees[TI_DFLOAT32_PTR_TYPE] -#define dfloat64_ptr_type_node global_trees[TI_DFLOAT64_PTR_TYPE] -#define dfloat128_ptr_type_node global_trees[TI_DFLOAT128_PTR_TYPE] /* The fixed-point types. */ #define sat_short_fract_type_node global_trees[TI_SAT_SFRACT_TYPE] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Fix decimal floating-point LTO streaming for offloading compilation 2019-11-28 18:25 ` Julian Brown @ 2019-11-28 19:22 ` Joseph Myers 0 siblings, 0 replies; 21+ messages in thread From: Joseph Myers @ 2019-11-28 19:22 UTC (permalink / raw) To: Julian Brown; +Cc: gcc-patches, Thomas Schwinge, Segher Boessenkool On Thu, 28 Nov 2019, Julian Brown wrote: > On Thu, 28 Nov 2019 15:04:05 +0000 > Joseph Myers <joseph@codesourcery.com> wrote: > > > On Thu, 28 Nov 2019, Julian Brown wrote: > > > > > Unlike e.g. the _FloatN types, when decimal floating-point types are > > > enabled, common tree nodes are created for each float type size > > > (e.g. dfloat32_type_node) and also a pointer to each type is created > > > (e.g. dfloat32_ptr_type_node). tree-streamer.c:record_common_node > > > emits these like: > > > > As far as I can tell, nothing actually uses those pointer nodes, or > > the corresponding BT_DFLOAT32_PTR etc. defined in builtin-types.def. > > I don't know if they ever were used, or if they were just added by > > analogy to e.g. float_ptr_type_node. > > > > So I'd suggest simply removing all references to those tree nodes and > > corresponding BT_*, from builtin-types.def, jit/jit-builtins.c > > (commented out), tree-core.h, tree.c, tree.h. Hopefully that will > > solve the offloading problem. > > Thanks for review. How about this (lightly retested so far), assuming > it passes full testing/bootstrap? This patch is OK. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Fix decimal floating-point LTO streaming for offloading compilation 2019-11-28 15:15 ` Joseph Myers 2019-11-28 15:45 ` Segher Boessenkool 2019-11-28 18:25 ` Julian Brown @ 2019-11-28 19:45 ` Richard Biener 2 siblings, 0 replies; 21+ messages in thread From: Richard Biener @ 2019-11-28 19:45 UTC (permalink / raw) To: Joseph Myers; +Cc: Julian Brown, GCC Patches, Thomas Schwinge On Thu, Nov 28, 2019 at 4:04 PM Joseph Myers <joseph@codesourcery.com> wrote: > > On Thu, 28 Nov 2019, Julian Brown wrote: > > > Unlike e.g. the _FloatN types, when decimal floating-point types are > > enabled, common tree nodes are created for each float type size (e.g. > > dfloat32_type_node) and also a pointer to each type is created > > (e.g. dfloat32_ptr_type_node). tree-streamer.c:record_common_node emits > > these like: > > As far as I can tell, nothing actually uses those pointer nodes, or the > corresponding BT_DFLOAT32_PTR etc. defined in builtin-types.def. I don't > know if they ever were used, or if they were just added by analogy to e.g. > float_ptr_type_node. > > So I'd suggest simply removing all references to those tree nodes and > corresponding BT_*, from builtin-types.def, jit/jit-builtins.c (commented > out), tree-core.h, tree.c, tree.h. Hopefully that will solve the > offloading problem. Indeed that seems to be the case and would be my suggestion as well. The issue with LTO streaming here is that pointers get streamed as two things but the error-mark replacement as one, that causes the mismatches. So please just remove those three global types. Richard. > -- > Joseph S. Myers > joseph@codesourcery.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Fix decimal floating-point LTO streaming for offloading compilation 2019-11-28 14:44 ` [PATCH] Fix decimal floating-point LTO streaming for offloading compilation Julian Brown 2019-11-28 15:15 ` Joseph Myers @ 2019-11-28 15:23 ` Thomas Schwinge 1 sibling, 0 replies; 21+ messages in thread From: Thomas Schwinge @ 2019-11-28 15:23 UTC (permalink / raw) To: Julian Brown Cc: gcc-patches, Joseph Myers, Richard Biener, Jakub Jelinek, Jeff Law, Kwok Cheung Yeung [-- Attachment #1: Type: text/plain, Size: 3647 bytes --] Hi Julian! On 2019-11-28T14:24:02+0000, Julian Brown <julian@codesourcery.com> wrote: > As mentioned in PR91985, offloading compilation is broken at present > because of an issue with LTO streaming. With thanks to Joseph for > hints, here's a solution. > > Unlike e.g. the _FloatN types, when decimal floating-point types are > enabled, common tree nodes are created for each float type size (e.g. > dfloat32_type_node) and also a pointer to each type is created > (e.g. dfloat32_ptr_type_node). tree-streamer.c:record_common_node emits > these like: > > <float:32> (dfloat32_type_node) > <float:64> (dfloat64_type_node) > <float:128> (dfloat128_type_node) > <float:32> * (dfloat32_ptr_type_node) > <float:32> > <float:64> * (dfloat64_ptr_type_node) > <float:64> > <float:128> * (dfloat128_ptr_type_node) > <float:128> > > I.e., with explicit emission of a copy of the pointed-to type following > the pointer itself. I also do see that, but I fail to understand why that duplication: the first '<float:32>' and the second one (after the '<float:32> *') are the same node, or aren't they? > When DFP is disabled, we instead get: > > <<< error >>> > <<< error >>> > <<< error >>> > <<< error >>> > <<< error >>> > <<< error >>> (With that expectedly being any 'NULL_TREE's converted to 'error_mark_node' in 'gcc/tree-streamer.c:record_common_node'.) > So, the number of nodes emitted during LTO write-out in the host/read-in > in the offload compiler do not match. ACK. > This patch restores the number of nodes emitted by creating > dfloatN_ptr_type_node as generic pointers rather than treating them as > flat error_type_nodes. I don't think there's an easy way of creating an > "error_type_node *", nor do I know if that would really be preferable. > > Tested with offloading to NVPTX & bootstrapped. OK to apply? > commit 17119773a8a45af098364b4faafe68f2e868479a > Author: Julian Brown <julian@codesourcery.com> > Date: Wed Nov 27 18:41:56 2019 -0800 > > Fix decimal floating-point LTO streaming for offloading compilation > > gcc/ > * tree.c (build_common_tree_nodes): Use pointer type for > dfloat32_ptr_type_node, dfloat64_ptr_type_node and > dfloat128_ptr_type_node when decimal floating point support is disabled. > > diff --git a/gcc/tree.c b/gcc/tree.c > index 5ae250ee595..db3f225ea7f 100644 > --- a/gcc/tree.c > +++ b/gcc/tree.c > @@ -10354,6 +10354,15 @@ build_common_tree_nodes (bool signed_char) > layout_type (dfloat128_type_node); > dfloat128_ptr_type_node = build_pointer_type (dfloat128_type_node); > } > + else > + { > + /* These must be pointers else tree-streamer.c:record_common_node will emit > + a different number of nodes depending on DFP availability, which breaks > + offloading compilation. */ > + dfloat32_ptr_type_node = ptr_type_node; > + dfloat64_ptr_type_node = ptr_type_node; > + dfloat128_ptr_type_node = ptr_type_node; > + } > > complex_integer_type_node = build_complex_type (integer_type_node, true); > complex_float_type_node = build_complex_type (float_type_node, true); (Maybe that's indeed better than my "hamfisted" patch.) ;-) But it still reads a bit like a workaround (explicitly setting only 'dfloat*_ptr_type_node' here, leaving the actual 'dfloat*_type_node' untouched (and then later on implicitly converted to 'error_mark_node' as mentioned). I guess we need somebody with more experience to review this. Grüße Thomas [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 658 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2020-01-16 14:44 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-22 16:47 Prevent all uses of DFP when unsupported (PR c/91985) Joseph Myers 2019-11-23 16:56 ` Jeff Law 2019-11-25 20:36 ` Rainer Orth 2019-11-26 1:05 ` Joseph Myers 2019-11-26 12:21 ` Jonathan Wakely 2019-11-27 12:18 ` Rainer Orth 2019-11-27 17:49 ` Joseph Myers 2019-11-27 18:01 ` Jakub Jelinek 2020-01-16 14:49 ` Szabolcs Nagy 2020-01-16 14:50 ` Jakub Jelinek 2019-11-26 14:02 ` Andreas Schwab 2019-11-27 21:55 ` Thomas Schwinge 2019-11-27 22:39 ` Joseph Myers 2019-11-28 14:22 ` Thomas Schwinge 2019-11-28 14:44 ` [PATCH] Fix decimal floating-point LTO streaming for offloading compilation Julian Brown 2019-11-28 15:15 ` Joseph Myers 2019-11-28 15:45 ` Segher Boessenkool 2019-11-28 18:25 ` Julian Brown 2019-11-28 19:22 ` Joseph Myers 2019-11-28 19:45 ` Richard Biener 2019-11-28 15:23 ` Thomas Schwinge
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).