On Wed, Dec 07, 2022 at 03:55:41PM +0800, Kewen.Lin wrote:
> Hi Mike,
>
> on 2022/12/7 14:44, Michael Meissner wrote:
> > On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote:
> >> Hi Mike,
> >>
> >> Thanks for fixing this!
> >>
> >> Could you help to elaborate why we need to disable it during libgcc
> >> building?
> >
> > When you are building libgcc, you are building the __mulkc3, __divkc3
> > functions. The mapping in the compiler interferes with those functions,
> > because at the moment, libgcc uses an alternate IEEE 128-bit type.
> >
>
> But I'm still confused. For __mulkc3 (__divkc3 is similar),
>
> 1) with -mabi=ieeelongdouble (TARGET_IEEEQUAD true, define
> __LONG_DOUBLE_IEEE128__),
> the used types are:
>
> typedef float TFtype __attribute__ ((mode (TF)));
> typedef __complex float TCtype __attribute__ ((mode (TC)));
>
> 2) with -mabi=ibmlongdouble (TARGET_IEEEQUAD false, not
> __LONG_DOUBLE_IEEE128__ defined),
> the used types are:
>
> typedef float TFtype __attribute__ ((mode (KF)));
> typedef __complex float TCtype __attribute__ ((mode (KC)));
>
> The proposed mapping in the current patch is:
>
> +
> + if (id == complex_multiply_builtin_code (KCmode))
> + newname = "__mulkc3";
> +
> + else if (id == complex_multiply_builtin_code (ICmode))
> + newname = "__multc3";
> +
> + else if (id == complex_multiply_builtin_code (TCmode))
> + newname = (TARGET_IEEEQUAD) ? "__mulkc3" : "__multc3";
>
> for 1), TCmode && TARGET_IEEEQUAD => "__mulkc3"
> for 2), KCmode => "__mulkc3"
>
> Both should be still with name "__mulkc3", do I miss anything?
>
> BR,
> Kewen
The reason is due to the different internal types, the value range propigation
pass throws an error when we are trying to build libgcc. This is due to the
underlying problem of different IEEE 128-bit types within the compiler.
The 128-bit IEEE support in libgcc was written before _Float128 was added to
GCC. One consequence is that you can't get to the complex variant of
__float128. So libgcc needs to use the attribute mode to get to that type.
But with the support for IEEE 128-bit long double changing things, it makes the
libgcc code use the wrong code.
/home/meissner/fsf-src/work102/libgcc/config/rs6000/_mulkc3.c: In function
‘__mulkc3_sw’:
/home/meissner/fsf-src/work102/libgcc/config/rs6000/_mulkc3.c:97:1: internal
compiler error: in fold_stmt, at gimple-range-fold.cc:522
97 | }
| ^
0x122784f3 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
/home/meissner/fsf-src/work102/gcc/gimple-range-fold.cc:522
0x1226477f gimple_ranger::fold_range_internal(vrange&, gimple*, tree_node*)
/home/meissner/fsf-src/work102/gcc/gimple-range.cc:257
0x12264b1f gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
/home/meissner/fsf-src/work102/gcc/gimple-range.cc:318
0x113bdd8b range_query::value_of_stmt(gimple*, tree_node*)
/home/meissner/fsf-src/work102/gcc/value-query.cc:134
0x1134838f rvrp_folder::value_of_stmt(gimple*, tree_node*)
/home/meissner/fsf-src/work102/gcc/tree-vrp.cc:1023
0x111344cf substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
/home/meissner/fsf-src/work102/gcc/tree-ssa-propagate.cc:819
0x121ecbd3 dom_walker::walk(basic_block_def*)
/home/meissner/fsf-src/work102/gcc/domwalk.cc:311
0x11134ee7 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
/home/meissner/fsf-src/work102/gcc/tree-ssa-propagate.cc:998
0x11346bb7 execute_ranger_vrp(function*, bool, bool)
/home/meissner/fsf-src/work102/gcc/tree-vrp.cc:1084
0x11347063 execute
/home/meissner/fsf-src/work102/gcc/tree-vrp.cc:1165
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[1]: *** [/home/meissner/fsf-src/work102/libgcc/shared-object.mk:14:
_mulkc3.o] Error 1
make[1]: Leaving directory
'/home/meissner/fsf-build-ppc64le/work102/powerpc64le-unknown-linux-gnu/libgcc'
make: *** [Makefile:20623: all-target-libgcc] Error 2
> > I have a patch for making libgcc use the 'right' type that I haven't
> > submitted
> > yet. This is because the more general fix that these 3 patches do impacts
> > other
> > functions (due to __float128 and _Float128 being different in the current
> > compiler when -mabi=ieeelongdouble).
> >
The patch is to use _Float128 and _Complex _Float128 in libgcc.h instead of
trying to use attribute((mode(TF))) and attribute((mode(TC))) in libgcc.
Now, this patch fixes the specific problem of not being able to build libgcc
(along with patch #1 of the series). But other things show the differences
from time time because we are using different internal types and the middle end
doesn't know that these types are really the same bits.
It is better long term (IMHO) if we have the two types (__float128 and
_Float128) use the same internal type (which is what is done in patches #2 and
#3). This fixes the other issues that show up, such as creating signaling NaNs
for one internal type, and converting it to the other internal type, loses that
the NaN is signalling.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
