https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299
--- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
It looks like the 0.0 with the wrong type is there quite early in the pipeline.
At least by einline (after SSA and CFG have been built) we have:
(gdb) p debug(gs)
c_92 = __builtin_copysignf128 (0.0, c_80(D));
c_92 has a type of TFtype:
(gdb) p debug_tree(lhs)
<ssa_name 0x7fffef2d23b8
type <real_type 0x7fffef5211b8 TFtype sizes-gimplified TF
size <integer_cst 0x7fffef221038 constant 128>
unit-size <integer_cst 0x7fffef221050 constant 16>
align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffef251500 precision:127 context <translation_unit_decl 0x7fffef510960
a.i>>
visited var <parm_decl 0x7ffff7f84f80 c>
def_stmt 163c_92 = __builtin_copysignf128 (0.0, c_80(D));
version:92>
$12 = void
Whereas 0.0 has a type of _Float128:
(gdb) p gimple_call_arg (gs, 0)
$13 = (tree_node *) 0x7fffef54d1a0
(gdb) p debug($13)
0.0
$14 = void
(gdb) p debug_tree($13)
<real_cst 0x7fffef54d1a0
type <real_type 0x7fffef2516f8 _Float128 TF
size <integer_cst 0x7fffef221038 constant 128>
unit-size <integer_cst 0x7fffef221050 constant 16>
align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffef2516f8 precision:128>
constant 0.0>
