[Bug other/107299] New: [13 regression]

[Bug other/107299] New: [13 regression]

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299

            Bug ID: 107299
           Summary: [13 regression]
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:8efc38347a7444dde3fb173f0f2c59a60b7db53d, r13-3307-g8efc38347a7444

I am seeing this only on a powerpc64 system that has IEE128 enabled in the
system compiler.

/home/seurer/gcc/git/build/gcc-trunk/./gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-trunk/./gcc/
-B/home/seurer/gcc/git/install/gcc-trunk/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-trunk/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-trunk/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-trunk/powerpc64le-unknown-linux-gnu/sys-include
   -g -O2 -O2  -g -O2 -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include  -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector  -fPIC -mlong-double-128
-mno-minimal-toc -I. -I. -I../.././gcc -I/home/seurer/gcc/git/gcc-trunk/libgcc
-I/home/seurer/gcc/git/gcc-trunk/libgcc/.
-I/home/seurer/gcc/git/gcc-trunk/libgcc/../gcc
-I/home/seurer/gcc/git/gcc-trunk/libgcc/../include
-I/home/seurer/gcc/git/gcc-trunk/libgcc/../libdecnumber/dpd
-I/home/seurer/gcc/git/gcc-trunk/libgcc/../libdecnumber -DHAVE_CC_TLS 
-Wno-type-limits -mvsx -mfloat128 -mno-float128-hardware -mno-gnu-attribute
-I/home/seurer/gcc/git/gcc-trunk/libgcc/soft-fp
-I/home/seurer/gcc/git/gcc-trunk/libgcc/config/rs6000 -DFLOAT128_HW_INSNS
-DFLOAT128_HW_INSNS_ISA3_1  -o _mulkc3.o -MT _mulkc3.o -MD -MP -MF _mulkc3.dep 
-c /home/seurer/gcc/git/gcc-trunk/libgcc/config/rs6000/_mulkc3.c
-fvisibility=hidden -DHIDE_EXPORTS
during GIMPLE pass: evrp
/home/seurer/gcc/git/gcc-trunk/libgcc/config/rs6000/_mulkc3.c: In function
'__mulkc3_sw':
/home/seurer/gcc/git/gcc-trunk/libgcc/config/rs6000/_mulkc3.c:97:1: internal
compiler error: in fold_stmt, at gimple-range-fold.cc:514
   97 | }
      | ^
0x11aeaf2f fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
        /home/seurer/gcc/git/gcc-trunk/gcc/gimple-range-fold.cc:514
0x11ad78f3 gimple_ranger::fold_range_internal(vrange&, gimple*, tree_node*)
        /home/seurer/gcc/git/gcc-trunk/gcc/gimple-range.cc:258
0x11ad78f3 gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
        /home/seurer/gcc/git/gcc-trunk/gcc/gimple-range.cc:319
0x1108419f range_query::value_of_stmt(gimple*, tree_node*)
        /home/seurer/gcc/git/gcc-trunk/gcc/value-query.cc:135
0x1102e3b7 rvrp_folder::value_of_stmt(gimple*, tree_node*)
        /home/seurer/gcc/git/gcc-trunk/gcc/tree-vrp.cc:4300
0x10eb64eb
substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
        /home/seurer/gcc/git/gcc-trunk/gcc/tree-ssa-propagate.cc:816
0x11a9138b dom_walker::walk(basic_block_def*)
        /home/seurer/gcc/git/gcc-trunk/gcc/domwalk.cc:311
0x10eb4c0f substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
        /home/seurer/gcc/git/gcc-trunk/gcc/tree-ssa-propagate.cc:987
0x1102065b execute_ranger_vrp(function*, bool)
        /home/seurer/gcc/git/gcc-trunk/gcc/tree-vrp.cc:4351

commit 8efc38347a7444dde3fb173f0f2c59a60b7db53d (HEAD)
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Thu Oct 13 17:51:29 2022 +0200

    Implement range-op entry for __builtin_copysign.

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299

--- Comment #1 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
I can't reproduce on gcc135.fsffrance.org with default parameters on a
bootstrap.

Is there a way to reproduce this on said machine?  Or could you provide a .i
file that could be used with a cross?

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |linkw at gcc dot gnu.org

--- Comment #2 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #1)
> I can't reproduce on gcc135.fsffrance.org with default parameters on a
> bootstrap.
> 
> Is there a way to reproduce this on said machine?  Or could you provide a .i
> file that could be used with a cross?

I guessed you need configuration option --with-long-double-128 and
--with-long-double-format=ieee, since comment #0 mentioned IEE(E)128 (long
double) enabled.

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |amacleod at redhat dot com
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-10-18

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
We are failing while trying to fold:

c_92 = __builtin_copysignf128 (0.0, c_80(D));

The problem is that c_92 is TFtype but 0.0 is _Float128.  TFtype has a
precision of 127 whereas _Float128 has a precision of 128.  This causes the
assert in fold_using_range::fold_stmt to fail because range_compatible_p is
false.

Are both operands of copysign allowed to have different types / precisions?

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299

--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #3)
> We are failing while trying to fold:
> 
> c_92 = __builtin_copysignf128 (0.0, c_80(D));
> 
> The problem is that c_92 is TFtype but 0.0 is _Float128.  TFtype has a
> precision of 127 whereas _Float128 has a precision of 128.  This causes the
> assert in fold_using_range::fold_stmt to fail because range_compatible_p is
> false.
> 
> Are both operands of copysign allowed to have different types / precisions?

Sorry, what I meant to say is that c_92 is TFtype, whereas
__builtin_copysignf128 is assuming to return the type of the first operand
(0.0, which is _Float128).  Is this correct?

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #4)
> (In reply to Aldy Hernandez from comment #3)
> > We are failing while trying to fold:
> > 
> > c_92 = __builtin_copysignf128 (0.0, c_80(D));
> > 
> > The problem is that c_92 is TFtype but 0.0 is _Float128.  TFtype has a
> > precision of 127 whereas _Float128 has a precision of 128.  This causes the
> > assert in fold_using_range::fold_stmt to fail because range_compatible_p is
> > false.
> > 
> > Are both operands of copysign allowed to have different types / precisions?
> 
> Sorry, what I meant to say is that c_92 is TFtype, whereas
> __builtin_copysignf128 is assuming to return the type of the first operand
> (0.0, which is _Float128).  Is this correct?

It looks like 0.0 has the wrong type here.  Maybe the copysign is the
result of folding that left us with unconverted 0.0 here?

Reduced preprocessed source would be nice, but you can see if
-fdump-tree-all-folding shows a bogus match.pd pattern (but the issue might be
in fold-const.cc as well).

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build, ice-on-valid-code
                 CC|                            |rguenth at gcc dot gnu.org
   Target Milestone|---                         |13.0

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 53718
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53718&action=edit
preprocessed testcase

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

[aldyh at gcc dot gnu.org]

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>

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299

--- Comment #8 from seurer at gcc dot gnu.org ---
*** Bug 107420 has been marked as a duplicate of this bug. ***

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Michael Meissner <meissner@gcc.gnu.org>:

https://gcc.gnu.org/g:306c7b1ac3e4413288e6930b00a3cab2133c4e57

commit r13-6507-g306c7b1ac3e4413288e6930b00a3cab2133c4e57
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Mon Mar 6 17:38:33 2023 -0500

    PR target/107299: Fix build issue when long double is IEEE 128-bit

    This patch updates the IEEE 128-bit types used in libgcc.

    At the moment, we cannot build GCC when the target uses IEEE 128-bit long
    doubles, such as building the compiler for a native Fedora 36 system.  The
    build dies when it is trying to build the _mulkc3.c and _divkc3 modules.

    This patch changes libgcc to use long double for the IEEE 128-bit base type
if
    long double is IEEE 128-bit, and it uses _Float128 otherwise.  The built-in
    functions are adjusted to be the correct version based on the IEEE 128-bit
base
    type used.

    While it is desirable to ultimately have __float128 and _Float128 use the
same
    internal type and mode within GCC, at present if you use the option
    -mabi=ieeelongdouble, the __float128 type will use the long double type and
not
    the _Float128 type.  We get an internal compiler error if we combine the
    signbitf128 built-in with a long double type.

    I've gone through several iterations of trying to fix this within GCC, and
    there are various problems that have come up.  I developed this alternative
    patch that changes libgcc so that it does not tickle the issue.  I hope we
can
    fix the compiler at some point, but right now, this is preventing people on
    Fedora 36 systems from building compilers where the default long double is
IEEE
    128-bit.

    2023-03-06   Michael Meissner  <meissner@linux.ibm.com>

    libgcc/

            PR target/107299
            * config/rs6000/_divkc3.c (COPYSIGN): Use the correct built-in
based on
            whether long double is IBM or IEEE.
            (INFINITY): Likewise.
            (FABS): Likewise.
            * config/rs6000/_mulkc3.c (COPYSIGN): Likewise.
            (INFINITY): Likewise.
            * config/rs6000/quad-float128.h (TF): Remove definition.
            (TFtype): Define to be long double or _Float128.
            (TCtype): Define to be _Complex long double or _Complex _Float128.
            * libgcc2.h (TFtype): Allow machine config files to override this.
            (TCtype): Likewise.
            * soft-fp/quad.h (TFtype): Likewise.

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I can build trunk without --enable-checking=release now, but I get some FAILs
in the libstdc++ testsuite:

during GIMPLE pass: threadfull
/home/test/src/gcc/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc:
In function 'void test(std::chars_format)':
/home/test/src/gcc/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc:34:
internal compiler error: in fold_stmt, at gimple-range-fold.cc:522
0x11ed1b03 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
        /home/test/src/gcc/gcc/gimple-range-fold.cc:522
0x11ebd503 gimple_ranger::fold_range_internal(vrange&, gimple*, tree_node*)
        /home/test/src/gcc/gcc/gimple-range.cc:257
0x11ebd503 gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
        /home/test/src/gcc/gcc/gimple-range.cc:318
0x11ebb64f gimple_ranger::range_on_entry(vrange&, basic_block_def*, tree_node*)
        /home/test/src/gcc/gcc/gimple-range.cc:153
0x112368c3 path_range_query::range_on_path_entry(vrange&, tree_node*)
        /home/test/src/gcc/gcc/gimple-range-path.cc:160
0x11238063 path_range_query::internal_range_of_expr(vrange&, tree_node*,
gimple*)
        /home/test/src/gcc/gcc/gimple-range-path.cc:176
0x112382b7 path_range_query::range_of_expr(vrange&, tree_node*, gimple*)
        /home/test/src/gcc/gcc/gimple-range-path.cc:202
0x11ecb723 fur_stmt::get_operand(vrange&, tree_node*)
        /home/test/src/gcc/gcc/gimple-range-fold.cc:157
0x11ecf48f fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
        /home/test/src/gcc/gcc/gimple-range-fold.cc:577
0x11ed1a03 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
        /home/test/src/gcc/gcc/gimple-range-fold.cc:489
0x11237733 path_range_query::range_of_stmt(vrange&, gimple*, tree_node*)
        /home/test/src/gcc/gcc/gimple-range-path.cc:721
0x112f0db3 back_threader::find_taken_edge_cond(vec<basic_block_def*, va_heap,
vl_ptr> const&, gcond*)
        /home/test/src/gcc/gcc/tree-ssa-threadbackward.cc:325
0x112f1087 back_threader::maybe_register_path(back_threader_profitability&)
        /home/test/src/gcc/gcc/tree-ssa-threadbackward.cc:248
0x112f1503 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
        /home/test/src/gcc/gcc/tree-ssa-threadbackward.cc:371
0x112f1b27 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
        /home/test/src/gcc/gcc/tree-ssa-threadbackward.cc:479
0x112f282b back_threader::maybe_thread_block(basic_block_def*)
        /home/test/src/gcc/gcc/tree-ssa-threadbackward.cc:551
0x112f2a73 back_threader::thread_blocks()
        /home/test/src/gcc/gcc/tree-ssa-threadbackward.cc:975
0x112f2b83 execute
        /home/test/src/gcc/gcc/tree-ssa-threadbackward.cc:1105
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.
compiler exited with status 1
FAIL: 20_util/to_chars/float128_c++23.cc (test for excess errors)

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the build issue is fixed.  If there's another issue please open a new
bugreport for it.