[Bug libgcc/104253] libgcc missing __floatdiif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253 Michael Meissner changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org --- Comment #5 from Michael Meissner --- The other issue that I mentioned in note #2 is likely a different issue when -mabi=ibmlongdouble is used. I didn't have the patch to automatically use IEEE 128-bit if the compiler used to build stage1 also used IEEE 128-bit.
[Bug libgcc/104253] libgcc missing __floatdiif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253 --- Comment #4 from Michael Meissner --- Created attachment 52306 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52306=edit Patch to use the correct names for __ibm128 converts if long double is IEEE 128-bit The problem was internally there are 3 types for 128-bit floating point: TFmode -- mode for the type long double IFmode -- mode for __ibm128 if long double is IEEE 128-bit KFmode -- mode for __float128 There was not a conversion function specified to convert between IFmode and other modes, so the machine independent portion of the compiler created a name with 'if' in it. This patch specifies the names for the conversion functions to use the traditional TF modes.
[Bug libgcc/104253] libgcc missing __floatdiif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Agreed.
[Bug libgcc/104253] libgcc missing __floatdiif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253
--- Comment #2 from joseph at codesourcery dot com ---
I wouldn't expect any *if libgcc function names to be used, because "tf"
libgcc names are supposed to refer to the ibm128 format and "kf" names are
supposed to refer to the IEEE binary128 format, regardless of which format
is actually TFmode inside the compiler.
Probably much the same issue as this bug: building
_Complex double ic __attribute__ ((mode (IC)));
void test_ic (void) { ic /= ic; ic *= ic; }
with -mabi=ieeelongdouble produces spurious __divic3 and __mulic3
references (should be __divtc3 and __multc3).
[Bug libgcc/104253] libgcc missing __floatdiif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253
Michael Meissner changed:
What|Removed |Added
Last reconfirmed||2022-01-26
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Michael Meissner ---
In addition to __floatdiif not being in libgcc, if you build a recent trunk, it
exposes a second issue:
-ltcden3-lp5-> /home/meissner/fsf-install-ppc64le/trunk/bin/gcc -O2 pr-104253.c
during RTL pass: expand
pr-104253.c: In function ‘main’:
pr-104253.c:8:9: internal compiler error: in copy_to_mode_reg, at explow.cc:652
8 | printf("%a
%a\n",__builtin_unpack_ibm128(i,0),__builtin_unpack_ibm128(i,1));
|
^~~
0x10408cab copy_to_mode_reg(machine_mode, rtx_def*)
/home/meissner/fsf-src/trunk/gcc/explow.cc:652
0x10f28837 rs6000_expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode,
int)
/home/meissner/fsf-src/trunk/gcc/config/rs6000/rs6000-call.cc:5834
0x1043811f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/meissner/fsf-src/trunk/gcc/expr.cc:11536
0x10446e7b store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/meissner/fsf-src/trunk/gcc/expr.cc:6087
0x1044af77 expand_assignment(tree_node*, tree_node*, bool)
/home/meissner/fsf-src/trunk/gcc/expr.cc:5819
0x10285cbb expand_call_stmt
/home/meissner/fsf-src/trunk/gcc/cfgexpand.cc:2829
0x10285cbb expand_gimple_stmt_1
/home/meissner/fsf-src/trunk/gcc/cfgexpand.cc:3864
0x10285cbb expand_gimple_stmt
/home/meissner/fsf-src/trunk/gcc/cfgexpand.cc:4028
0x1028dd93 expand_gimple_basic_block
/home/meissner/fsf-src/trunk/gcc/cfgexpand.cc:6069
0x1028ff27 execute
/home/meissner/fsf-src/trunk/gcc/cfgexpand.cc:6795
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
