Bug 113720 - [14 Regression] internal compiler error: in extract_insn, at recog.cc:2812 targeting alpha-linux-gnu
Summary: [14 Regression] internal compiler error: in extract_insn, at recog.cc:2812 ta...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 14.0
: P4 normal
Target Milestone: 14.0
Assignee: Uroš Bizjak
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2024-02-02 13:18 UTC by Matthias Klose
Modified: 2024-03-03 19:44 UTC (History)
5 users (show)

See Also:
Host:
Target: alpha-linux-gnu
Build:
Known to work: 13.2.1
Known to fail: 14.0
Last reconfirmed: 2024-02-02 00:00:00


Attachments
preprocessed source (191.88 KB, application/x-xz)
2024-02-02 13:18 UTC, Matthias Klose
Details
Patch that introduces umul_highpart RTX (506 bytes, patch)
2024-02-02 14:01 UTC, Uroš Bizjak
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Klose 2024-02-02 13:18:42 UTC
Created attachment 57291 [details]
preprocessed source

[There is PR113615, but I was asked to file a separate issue]

works with 20240129, fails with 20240201 on alpha-linux-gnu

// gcc version 14.0.1 20240131 (experimental) [master r14-8680-g2f14c0dbb78] (Debian 14-20240201-3) 
// 
// ../../../../../src/libstdc++-v3/src/c++17/floating_to_chars.cc: In function 'std::to_chars_result std::__floating_to_chars_shortest(char*, char*, T, chars_format) [with T = double]':
// ../../../../../src/libstdc++-v3/src/c++17/floating_to_chars.cc:1306:3: error: unrecognizable insn:
//  1306 |   }
//       |   ^
// (insn 712 711 713 22 (set (reg:DI 686 [ highparttmp_857 ])
//         (truncate:DI (lshiftrt:TI (mult:TI (zero_extend:TI (subreg:DI (reg:TI 223 [ _319 ]) 0))
//                     (subreg:DI (reg:TI 225 [ _321 ]) 0))
//                 (const_int 64 [0x40])))) "../../../../../src/libstdc++-v3/src/c++17/ryu/d2s_intrinsics.h":254:27 -1
//      (nil))
// during RTL pass: vregs
// ../../../../../src/libstdc++-v3/src/c++17/floating_to_chars.cc:1306:3: internal compiler error: in extract_insn, at recog.cc:2812
// 0x7b030c _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
//      ../../src/gcc/rtl-error.cc:108
// 0x7b0328 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
//      ../../src/gcc/rtl-error.cc:116
// 0x7aed6e extract_insn(rtx_insn*)
//      ../../src/gcc/recog.cc:2812
// 0xe44cd5 instantiate_virtual_regs_in_insn
//      ../../src/gcc/function.cc:1611
// 0xe44cd5 instantiate_virtual_regs
//      ../../src/gcc/function.cc:1994
// 0xe44cd5 execute
//      ../../src/gcc/function.cc:2041
// Please submit a full bug report, with preprocessed source (by using -freport-bug).
// Please include the complete backtrace with any bug report.
Comment 1 Uroš Bizjak 2024-02-02 14:01:46 UTC
Created attachment 57292 [details]
Patch that introduces umul_highpart RTX

Please try the attached (untested) patch.
Comment 2 Joseph S. Myers 2024-02-02 14:55:13 UTC
Introduced by:

commit 2f14c0dbb789852947cb58fdf7d3162413f053fa
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Thu Feb 1 06:10:42 2024 +0000

    PR target/113560: Enhance is_widening_mult_rhs_p.
Comment 3 Roger Sayle 2024-02-02 18:38:51 UTC
Sorry for the inconvenience.  alpha.md's define_expand that creates RTL that contains a MULT with operands of different modes looks highly suspicious.  Uros' patch to use the (relatively recently added) UMUL_HIGHPART rtx_code is certainly a step in the right direction.
Comment 4 Matthias Klose 2024-02-03 09:28:49 UTC
Uros proposed patch lets the build succeed.
Comment 5 Uroš Bizjak 2024-02-03 09:54:42 UTC
(In reply to Matthias Klose from comment #4)
> Uros proposed patch lets the build succeed.

FTR, the problem was in umuldi3_highpart expander, which did:

   if (REG_P (operands[2]))
     operands[2] = gen_rtx_ZERO_EXTEND (TImode, operands[2]);

on register_operand predicate, which also allows SUBREG RTX. So, subregs were emitted without ZERO_EXTEND RTX.

But nowadays we have UMUL_HIGHPART that allows us to fix this issue while also simplifying the instruction RTX.

Matthias, can you please run the regression check - The fix is kind of obvious, but just to be sure.
Comment 6 Matthias Klose 2024-02-03 13:20:01 UTC
will do, but cannot do that before next week.
Comment 7 GCC Commits 2024-03-03 19:42:05 UTC
The master branch has been updated by Uros Bizjak <uros@gcc.gnu.org>:

https://gcc.gnu.org/g:318e0d44fe66ade59edb16a94565b3bfdc1883c6

commit r14-9282-g318e0d44fe66ade59edb16a94565b3bfdc1883c6
Author: Uros Bizjak <ubizjak@gmail.com>
Date:   Sun Mar 3 20:40:45 2024 +0100

    alpha: Introduce UMUL_HIGHPART rtx_code [PR113720]
    
    umuldi3_highpart expander does:
    
       if (REG_P (operands[2]))
         operands[2] = gen_rtx_ZERO_EXTEND (TImode, operands[2]);
    
    on register_operand predicate, which also allows SUBREG RTX. So,
    subregs were emitted without ZERO_EXTEND RTX.
    
    But nowadays we have UMUL_HIGHPART that allows us to fix this
    issue while also simplifying the instruction RTX.
    
            PR target/113720
    
    gcc/ChangeLog:
    
            * config/alpha/alpha.md (umuldi3_highpart): Remove expander.
            (*umuldi3_highpart_reg): Rename to umuldi3_highpart and
            simplify insn RTX using UMUL_HIGHPART rtx_code.
            (*umuldi3_highpart_const): Remove.
Comment 8 Uroš Bizjak 2024-03-03 19:44:38 UTC
Assuming fixed, please reopen if not.