As mentioned in https://gcc.gnu.org/pipermail/gcc-patches/2026-September/730781.html, issue_rate values on modern cores keep increasing, and the maximum issue_rate in the AArch64 backend has reached 10, causing an overflow in the calculation of max_lookahead_tries. Change its type to int64_t.
Bootstrapped and tested on aarch64-linux-gnu and x86_64-linux-gnu, no
regression.
gcc/ChangeLog:
* haifa-sched.cc (max_issue): Change max_lookahead_tries type to int64_t
---
gcc/haifa-sched.cc | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/haifa-sched.cc b/gcc/haifa-sched.cc
index 879749e9785..733a83034bf 100644
--- a/gcc/haifa-sched.cc
+++ b/gcc/haifa-sched.cc
@@ -5921,7 +5921,7 @@ int dfa_lookahead;
might be incomplete and such insn might occur. For such
descriptions, the complexity of algorithm (without the constraint)
could achieve DFA_LOOKAHEAD ** N , where N is the queue length. */
-static int max_lookahead_tries;
+static int64_t max_lookahead_tries;
/* The following function returns maximal (or close to maximal) number
of insns which can be issued on the same cycle and one of which
@@ -5941,8 +5941,9 @@ int
max_issue (struct ready_list *ready, int privileged_n, state_t state,
bool first_cycle_insn_p, int *index)
{
- int n, i, all, n_ready, best, delay, tries_num;
+ int n, i, all, n_ready, best, delay;
int more_issue;
+ int64_t tries_num;
struct choice_entry *top;
rtx_insn *insn;
--
2.43.0
0001-sched-Change-max_lookahead_tries-type-to-int64_t.patch
Description: 0001-sched-Change-max_lookahead_tries-type-to-int64_t.patch
