[{"id":3681749,"web_url":"http://patchwork.ozlabs.org/comment/3681749/","msgid":"<CA+yXCZA-7hd+0mH5xY3Kmt2iLiZSgK29qDvvuxDPOTJbUPVw7Q@mail.gmail.com>","list_archive_url":null,"date":"2026-04-24T02:56:34","subject":"Re: [PATCH] RISC-V: Use long jump for crossing section boundaries","submitter":{"id":61252,"url":"http://patchwork.ozlabs.org/api/people/61252/","name":"Kito Cheng","email":"kito.cheng@gmail.com"},"content":"This should be less controversial, also this patch has stabilized\nwithin our internal tree for several months, so I will commit ahead\nonce CI pass :)\n\nKito Cheng <kito.cheng@sifive.com> 於 2026年4月24日週五 上午10:55寫道：\n>\n> From: Monk Chiang <monk.chiang@sifive.com>\n>\n> When -freorder-blocks-and-partition is used, GCC places cold code in\n> .text.unlikely section.  Jumps from hot code (.text) to cold code\n> (.text.unlikely) may cross section boundaries.  Since the linker may\n> place these sections more than 1MB apart, the JAL instruction's ±1MB\n> range can be exceeded, causing linker errors like:\n>\n>   relocation truncated to fit: R_RISCV_JAL against `.text.unlikely'\n>\n> This patch fixes the issue by checking CROSSING_JUMP_P in the length\n> attribute calculation for jump instructions.  When a jump crosses\n> section boundaries, the length is set to 8 bytes (AUIPC+JALR) instead\n> of 4 bytes (JAL), ensuring the long form is used.\n>\n> This approach is consistent with other backends (NDS32, SH, ARC) that\n> also use CROSSING_JUMP_P to handle cross-section jumps.\n>\n> gcc/ChangeLog:\n>\n>         * config/riscv/riscv.md (length attribute): Check CROSSING_JUMP_P\n>         for jump instructions and use length 8 for crossing jumps.\n>         (jump): Update comment to explain when long form is used.\n>\n> gcc/testsuite/ChangeLog:\n>\n>         * gcc.target/riscv/pr-crossing-jump-1.c: New test.\n>         * gcc.target/riscv/pr-crossing-jump-2.c: New test.\n>         * gcc.target/riscv/pr-crossing-jump-3.c: New test.\n> ---\n>  gcc/config/riscv/riscv.md                     | 23 ++++++----\n>  .../gcc.target/riscv/pr-crossing-jump-1.c     | 41 +++++++++++++++++\n>  .../gcc.target/riscv/pr-crossing-jump-2.c     | 45 +++++++++++++++++++\n>  .../gcc.target/riscv/pr-crossing-jump-3.c     | 33 ++++++++++++++\n>  4 files changed, 134 insertions(+), 8 deletions(-)\n>  create mode 100644 gcc/testsuite/gcc.target/riscv/pr-crossing-jump-1.c\n>  create mode 100644 gcc/testsuite/gcc.target/riscv/pr-crossing-jump-2.c\n>  create mode 100644 gcc/testsuite/gcc.target/riscv/pr-crossing-jump-3.c\n>\n> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md\n> index 7ea6ee704c3..8803eec075e 100644\n> --- a/gcc/config/riscv/riscv.md\n> +++ b/gcc/config/riscv/riscv.md\n> @@ -630,13 +630,18 @@ (define_attr \"length\" \"\"\n>                                       (const_int 12)))\n>\n>           ;; Jumps further than +/- 1 MiB require two instructions.\n> +         ;; Also, jumps that cross section boundaries (e.g., from hot to cold\n> +         ;; section when -freorder-blocks-and-partition is used) require two\n> +         ;; instructions because the linker may place the sections far apart.\n>           (eq_attr \"type\" \"jump\")\n> -         (if_then_else (and (le (minus (match_dup 0) (pc))\n> -                                (const_int 1048568))\n> -                            (le (minus (pc) (match_dup 0))\n> -                                (const_int 1048572)))\n> -                       (const_int 4)\n> -                       (const_int 8))\n> +         (if_then_else (match_test \"CROSSING_JUMP_P (insn)\")\n> +                       (const_int 8)\n> +                       (if_then_else (and (le (minus (match_dup 0) (pc))\n> +                                              (const_int 1048568))\n> +                                          (le (minus (pc) (match_dup 0))\n> +                                              (const_int 1048572)))\n> +                                     (const_int 4)\n> +                                     (const_int 8)))\n>\n>           ;; Conservatively assume calls take two instructions (AUIPC + JALR).\n>           ;; The linker will opportunistically relax the sequence to JAL.\n> @@ -3822,8 +3827,10 @@ (define_insn \"jump\"\n>    [(set (pc) (label_ref (match_operand 0 \"\" \"\")))]\n>    \"\"\n>  {\n> -  /* Hopefully this does not happen often as this is going\n> -     to clobber $ra and muck up the return stack predictors.  */\n> +  /* Use the long form (AUIPC+JALR) if the jump distance exceeds 1 MiB,\n> +     or if the jump crosses section boundaries (e.g., from hot to cold\n> +     section when -freorder-blocks-and-partition is used).\n> +     Note: This clobbers $ra and mucks up the return stack predictors.  */\n>    if (get_attr_length (insn) == 8)\n>      return \"jump\\t%l0,ra\";\n>\n> diff --git a/gcc/testsuite/gcc.target/riscv/pr-crossing-jump-1.c b/gcc/testsuite/gcc.target/riscv/pr-crossing-jump-1.c\n> new file mode 100644\n> index 00000000000..88def7ce545\n> --- /dev/null\n> +++ b/gcc/testsuite/gcc.target/riscv/pr-crossing-jump-1.c\n> @@ -0,0 +1,41 @@\n> +/* Test that jumps crossing section boundaries use the long form (AUIPC+JALR).\n> +   When -freorder-blocks-and-partition is used, cold code is placed in\n> +   .text.unlikely section.  Jumps from hot code (.text) to cold code\n> +   (.text.unlikely) must use the long form because the linker may place\n> +   these sections more than 1MB apart, exceeding the JAL instruction's range.\n> +\n> +   This test verifies that CROSSING_JUMP_P is handled correctly in the\n> +   RISC-V backend.  */\n> +\n> +/* { dg-do compile } */\n> +/* { dg-require-effective-target freorder } */\n> +/* { dg-options \"-O2 -freorder-blocks-and-partition\" } */\n> +\n> +extern void abort (void);\n> +\n> +/* Force the error path to be cold.  */\n> +static void __attribute__((cold, noinline))\n> +handle_error (void)\n> +{\n> +  abort ();\n> +}\n> +\n> +/* Function with hot and cold paths.  */\n> +int\n> +check_positive (int x)\n> +{\n> +  if (__builtin_expect (x > 0, 1))\n> +    {\n> +      /* Hot path - stays in .text  */\n> +      return x;\n> +    }\n> +  /* Cold path - moved to .text.unlikely  */\n> +  handle_error ();\n> +  return -1;\n> +}\n> +\n> +/* The jump to the cold section should use \"jump\" (AUIPC+JALR) not \"j\" (JAL).\n> +   We check for \"jump\" instruction which is the long form.  */\n> +\n> +/* { dg-final { scan-assembler \"jump\\\\t\\\\.L\\[0-9\\]+,ra\" } } */\n> +\n> diff --git a/gcc/testsuite/gcc.target/riscv/pr-crossing-jump-2.c b/gcc/testsuite/gcc.target/riscv/pr-crossing-jump-2.c\n> new file mode 100644\n> index 00000000000..f2e7c55014d\n> --- /dev/null\n> +++ b/gcc/testsuite/gcc.target/riscv/pr-crossing-jump-2.c\n> @@ -0,0 +1,45 @@\n> +/* Test that multiple crossing jumps all use the long form.\n> +   This is a more comprehensive test for CROSSING_JUMP_P handling.  */\n> +\n> +/* { dg-do compile } */\n> +/* { dg-require-effective-target freorder } */\n> +/* { dg-options \"-O2 -freorder-blocks-and-partition\" } */\n> +\n> +extern void abort (void);\n> +\n> +static void __attribute__((cold, noinline))\n> +cold_path_1 (void)\n> +{\n> +  abort ();\n> +}\n> +\n> +static void __attribute__((cold, noinline))\n> +cold_path_2 (void)\n> +{\n> +  abort ();\n> +}\n> +\n> +/* Function with multiple cold paths.  */\n> +int\n> +validate (int a, int b)\n> +{\n> +  if (__builtin_expect (a > 0, 1))\n> +    {\n> +      if (__builtin_expect (b > 0, 1))\n> +       {\n> +         /* Hot path  */\n> +         return a + b;\n> +       }\n> +      /* Cold path 1  */\n> +      cold_path_1 ();\n> +    }\n> +  /* Cold path 2  */\n> +  cold_path_2 ();\n> +  return -1;\n> +}\n> +\n> +/* All jumps to cold sections should use \"jump\" (AUIPC+JALR).\n> +   We expect at least 2 crossing jumps.  */\n> +\n> +/* { dg-final { scan-assembler-times \"jump\\\\t\\\\.L\\[0-9\\]+,ra\" 2 } } */\n> +\n> diff --git a/gcc/testsuite/gcc.target/riscv/pr-crossing-jump-3.c b/gcc/testsuite/gcc.target/riscv/pr-crossing-jump-3.c\n> new file mode 100644\n> index 00000000000..d594488e222\n> --- /dev/null\n> +++ b/gcc/testsuite/gcc.target/riscv/pr-crossing-jump-3.c\n> @@ -0,0 +1,33 @@\n> +/* Test that jumps within the same section still use the short form (JAL).\n> +   This ensures that the CROSSING_JUMP_P fix doesn't pessimize normal jumps.  */\n> +\n> +/* { dg-do compile } */\n> +/* { dg-options \"-O2\" } */\n> +\n> +int global;\n> +\n> +/* Simple function with a loop - jumps stay within .text section.  */\n> +int\n> +sum_to_n (int n)\n> +{\n> +  int sum = 0;\n> +  for (int i = 1; i <= n; i++)\n> +    sum += i;\n> +  return sum;\n> +}\n> +\n> +/* Function with conditional - jumps stay within .text section.  */\n> +int\n> +abs_value (int x)\n> +{\n> +  if (x < 0)\n> +    return -x;\n> +  return x;\n> +}\n> +\n> +/* The backward jump in the loop should use \"j\" (JAL) not \"jump\" (AUIPC+JALR)\n> +   since it doesn't cross section boundaries.  We verify that \"jump\" is NOT\n> +   used for intra-section jumps.  */\n> +\n> +/* { dg-final { scan-assembler-not \"jump\\\\t\\\\.L\\[0-9\\]+,ra\" } } */\n> +\n> --\n> 2.52.0\n>","headers":{"Return-Path":"<gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org>","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=GVlSny+N;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=GVlSny+N","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","sourceware.org; spf=pass smtp.mailfrom=gmail.com","server2.sourceware.org;\n arc=pass smtp.remote-ip=209.85.218.48"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g1yL55xNnz1xvV\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 24 Apr 2026 12:57:17 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 01F694BA7987\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 24 Apr 2026 02:57:16 +0000 (GMT)","from mail-ej1-f48.google.com (mail-ej1-f48.google.com\n [209.85.218.48])\n by sourceware.org (Postfix) with ESMTPS id 0ED2D4BB1C20\n for <gcc-patches@gcc.gnu.org>; Fri, 24 Apr 2026 02:56:48 +0000 (GMT)","by mail-ej1-f48.google.com with SMTP id\n a640c23a62f3a-b9c3e2cf3c0so1309678466b.1\n for <gcc-patches@gcc.gnu.org>; Thu, 23 Apr 2026 19:56:47 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 01F694BA7987","OpenDKIM Filter v2.11.0 sourceware.org 0ED2D4BB1C20"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 0ED2D4BB1C20","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 0ED2D4BB1C20","ARC-Seal":["i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1776999408; cv=pass;\n b=QoDrkFktnqpo5uXhrndmcfFWKJW5wckmSk92YiZmmI/JnIg1ISPD2rUH12AUch08P+vPC/u1Uur8pV2nADUccE5hJtoa7ZoaBKB/hXcMXSpNG2nhERZwVd4xidlBGCNBP6wCOg8G6ZBP+QAglnMfwNgUh+Bg45J41/+RCLpOx6c=","i=1; a=rsa-sha256; t=1776999407; cv=none;\n d=google.com; s=arc-20240605;\n b=La+hfk2SYKTYTECjFYZID7+OAw0EL4eb2XOG13VJMDU41/2V6OCodRISggNjs+NuKB\n XSOC+5aHZo7CwLXz59ncJSomuBsjx5ER2gAyYi3xAyYUcH6lheNDW/dqsOLJ3tuH8FYk\n otcBetU/sOzNQ0ilCBmvPD6Nf6q6QzrW51MYrLk/QmtaKzpNL1gApenHewKFCRf9nHHr\n 0vThOP4EVJLpSDeGdrHqIuCSxUkSyF6HXB2ZrZtqwzXtp6jynFHgZJNtSXfuil7AUkFw\n mIPQaBKGI43ql27MZ6MgjnTOKAVXdGuVGFi4aYfbo3CQIgWdmI9tlYJo1eX43GoSvPqa\n 8ULQ=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776999408; c=relaxed/simple;\n bh=oqfuSmmo/Qyk84OPlmE66aLfo/u+CvR1znNW3YGvK5s=;\n h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;\n b=GFWvPYf2tx5M4jZvOm6tpcMdoNJoz6SvJ6BBhDJiq+H3Rv9PPw0SoVHtXSrzNyuM4RpNUEiG533+BMB9SgVv4kYFfURRqi6ST4lbLfHXGVsbu4fi4K42aHG+QKeiekA8/AfRwl5SC7SEY4l37WubxWGfDwnMy/i7Os3ZvWty9jk=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=YqrZxnyfPSLqyrVTvMECFWcaYpqEGQLVl3+CG+KNgKI=;\n fh=kHnuM9oqA89Yam2uOw/J3zZ1AW2rGoX9f5kgHtJYnh4=;\n b=iwyAW7yZLPb8fVX5kF73yltw1KBMZi7Dt+j7Ao8wHaziJPUdh6Q46+ZkWupEWBoNof\n eWEBqjVLOgZwwI8pnPaYwu6FMsg2KtCvmcQ1CVdW8bheJr8jJcfj9pubjHk1RoDYN2lS\n ww0McE4KXSJ47RB8hka7w5mlPSr9Uhx5+LpbXv80tebiSOFnb9sIdJ/KSbOPtrdnbcOt\n TxACOIyXxQgfeedh/6GJD2uiycwYZA0f+ogRsIgU/YjG7bSEkEmicO/n7KRHZWmp1EF3\n XJA33TJ4VfPojzCOdeeQJkEjfFcRV4GM9fdabYzyGklIl4Gani0aUMGc27pBKHSIIxYP\n WiZw==; darn=gcc.gnu.org"],"ARC-Authentication-Results":["i=2; server2.sourceware.org","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1776999407; x=1777604207; darn=gcc.gnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=YqrZxnyfPSLqyrVTvMECFWcaYpqEGQLVl3+CG+KNgKI=;\n b=GVlSny+Nmf+I14UGigFRqZVIffvLRLVh6qN/9lIThkyWt4iA4d5QxsbELqZ3SvQ402\n P6MdgOBzRtCmy3M/7RXgBzWFXKxdpEHcKHr8WtkYEBT7SxocpFygZXCU9CkDK6XwRB4v\n HvqVAq1ILPenSXrnPWgQT0F1fI3agxKh7xxD80fgidLcM9lEEt5FFHfz8BwMp1Z3WHVo\n GbT64oGcFJQSgG6FJhV2FDd1nZqKIsXjgHTyoOMynl13dhICJKGVrFD9hBEJ21FRsSfN\n GN4/Iy5FJUSHz+T0LH2V7yt/PsBlGJN0mmkBUW3sjaxK2x5LzLXqlm2a3c8/3DwuXdr8\n w9rg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776999407; x=1777604207;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=YqrZxnyfPSLqyrVTvMECFWcaYpqEGQLVl3+CG+KNgKI=;\n b=VyeVOUa/OIycrBn57kEmZgANO8qC/Gss+CPN3elCC/7rEHpJMMXoYrxZvMcVXeXMwB\n RvwCCdCoRFO9PkpuKb096mL7x3z4zpb9RXzYz7ZML1zcs3hG9//Jzve0BFLnxmKuFzKC\n BKEUUhevvqgeDPj261q1eTRPzhef3P37MLNw0XeBGbQoN46SfnRPn1RvAysuFW+HqcBz\n T0z9F7qHP26b+X5uiCgSs2uf0zHjGOwE2GK4eT9f8+Wd2TLEr6fD6CdMbjI9J1OJIkR1\n Cd/isNKOL/QXkDHPwz/aHjIOz2O/KQy9zSIjjBnAy6qY387k2BfSsWJeENo2Tmz3xU8B\n T1OA==","X-Gm-Message-State":"AOJu0Yw/puwpnRO8QpnVdt3dy5ojYslcUoZ0joxqZdvY+d2nHfI8mYNC\n COtDWbvvMIat0XXwrgOuxrnX0/Kzo+IPLi6jeecTF0Jr5g/6OcgKc95F9NzV/0Eo9iOMVUYiKmE\n sBuUP/46uZlI8NY6qu9NPncZHRPsR6CTXuQ==","X-Gm-Gg":"AeBDieuw31Abgyn1Bx28PjWMzEM+uINYjH1t6ONBz4AeM9v13iVhgF44X6tJBGmF9wj\n i/nv6crIAwciZKlyDU2aVL+Kk0ZxLou9i49SPtgWrnKf97fM8SizQnLzixXiv47ZCD3jxF+FA60\n bl58wm6XaK8VIG6/V6BgU6qV8oO3bjpLI++/OyjrHsMXiPfQKs778T35aO2T68BLkS9HJmfJQi3\n CD6hu38PARGsedogKsJLoet1oHa9YSTxiHQxu4gUHT+4ajD04hqaRQNkPH9gsQRc1e/xgvhFlfk\n 8dE73obBC+nQE1zh/o7aKrz749Sii+A=","X-Received":"by 2002:a17:907:7ba6:b0:b8f:f08a:4b80 with SMTP id\n a640c23a62f3a-ba41828cc02mr1448871566b.3.1776999406387; Thu, 23 Apr 2026\n 19:56:46 -0700 (PDT)","MIME-Version":"1.0","References":"<20260424025503.2589107-1-kito.cheng@sifive.com>","In-Reply-To":"<20260424025503.2589107-1-kito.cheng@sifive.com>","From":"Kito Cheng <kito.cheng@gmail.com>","Date":"Fri, 24 Apr 2026 10:56:34 +0800","X-Gm-Features":"AQROBzDX7pQmEOfYlUNr0cFvOgC135bKY8RdE02fTEIiGOFIFnL4HRKXL2umFBA","Message-ID":"\n <CA+yXCZA-7hd+0mH5xY3Kmt2iLiZSgK29qDvvuxDPOTJbUPVw7Q@mail.gmail.com>","Subject":"Re: [PATCH] RISC-V: Use long jump for crossing section boundaries","To":"Kito Cheng <kito.cheng@sifive.com>","Cc":"gcc-patches@gcc.gnu.org, jeffreyalaw@gmail.com,\n Monk Chiang <monk.chiang@sifive.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list <gcc-patches.gcc.gnu.org>","List-Unsubscribe":"<https://gcc.gnu.org/mailman/options/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>","List-Archive":"<https://gcc.gnu.org/pipermail/gcc-patches/>","List-Post":"<mailto:gcc-patches@gcc.gnu.org>","List-Help":"<mailto:gcc-patches-request@gcc.gnu.org?subject=help>","List-Subscribe":"<https://gcc.gnu.org/mailman/listinfo/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3682039,"web_url":"http://patchwork.ozlabs.org/comment/3682039/","msgid":"<f8032c3d-21b2-40a9-bf8f-ef0fac099980@oss.qualcomm.com>","list_archive_url":null,"date":"2026-04-24T13:45:31","subject":"Re: [PATCH] RISC-V: Use long jump for crossing section boundaries","submitter":{"id":92310,"url":"http://patchwork.ozlabs.org/api/people/92310/","name":"Jeffrey Law","email":"jeffrey.law@oss.qualcomm.com"},"content":"On 4/23/2026 8:56 PM, Kito Cheng wrote:\n> This should be less controversial, also this patch has stabilized\n> within our internal tree for several months, so I will commit ahead\n> once CI pass :)\nJust a note, the failures in the pre-commit CI system aren't related to \nyour patch; there's a glitch that was in the tree briefly which made the \nieee.exp tests unstable.\n\n\nJeff","headers":{"Return-Path":"<gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org>","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=qualcomm.com header.i=@qualcomm.com header.a=rsa-sha256\n header.s=qcppdkim1 header.b=dlQPCINI;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com\n header.a=rsa-sha256 header.s=google header.b=bKhnQmUk;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=qualcomm.com header.i=@qualcomm.com header.a=rsa-sha256\n header.s=qcppdkim1 header.b=dlQPCINI;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com\n header.a=rsa-sha256 header.s=google header.b=bKhnQmUk","sourceware.org; dmarc=none (p=none dis=none)\n header.from=oss.qualcomm.com","sourceware.org;\n spf=pass smtp.mailfrom=oss.qualcomm.com","server2.sourceware.org;\n arc=none smtp.remote-ip=205.220.168.131"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g2Dkk49rvz1yDD\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 24 Apr 2026 23:46:05 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 70B5C4BABF03\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 24 Apr 2026 13:46:03 +0000 (GMT)","from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com\n [205.220.168.131])\n by sourceware.org (Postfix) with ESMTPS id 3F5324B9DB7F\n for <gcc-patches@gcc.gnu.org>; Fri, 24 Apr 2026 13:45:36 +0000 (GMT)","from pps.filterd (m0279863.ppops.net [127.0.0.1])\n by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id\n 63OAhZXp1959801\n for <gcc-patches@gcc.gnu.org>; Fri, 24 Apr 2026 13:45:35 GMT","from mail-dl1-f72.google.com (mail-dl1-f72.google.com\n [74.125.82.72])\n by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4dr2nrj2e3-1\n (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)\n for <gcc-patches@gcc.gnu.org>; Fri, 24 Apr 2026 13:45:34 +0000 (GMT)","by mail-dl1-f72.google.com with SMTP id\n a92af1059eb24-12c66fdd4aeso11747081c88.0\n for <gcc-patches@gcc.gnu.org>; Fri, 24 Apr 2026 06:45:34 -0700 (PDT)","from [172.31.0.17] ([136.38.201.137])\n by smtp.gmail.com with ESMTPSA id\n a92af1059eb24-12c919266f6sm27121014c88.1.2026.04.24.06.45.32\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Fri, 24 Apr 2026 06:45:32 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 70B5C4BABF03","OpenDKIM Filter v2.11.0 sourceware.org 3F5324B9DB7F"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 3F5324B9DB7F","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 3F5324B9DB7F","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777038336; cv=none;\n b=I7bDgrmiZ7oQGlE1zlFNTjlLQlUtlHIdWAWRRe6+2ASgSHeax0UDPplNlGfIAZPBQM+g9if/23A1YXPW6ynYaLtWjDrJQvNn9tFyv7C3dwkWQu7NrGQ5OsmCENBBwKjWmTV9IW5sB0cAB97D5dvJ1JfWsPEXCKgq4dBZhzaPMMU=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777038336; c=relaxed/simple;\n bh=rstqAyQqUjEdFLGgFFySNkFBWbR2Q7E3atQNyS7fDg8=;\n h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version:\n Subject:To:From;\n b=Ho4jsa32u/Z4esRa8ymhzmGmX77HQ/5MHV4C7qI9y+aE9AgpFNtyCGOBCZy5jPXRXdH9yPdDaXtOVadjD8I5ro3jg0re/5QMkbzlRi84F6EKon+egRCW4DgdlmwgtkEkuJ7Hg2z17M7F6NbAG6tFhtaG/by2ST/sobczf35Onfw=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h=\n cc:content-transfer-encoding:content-type:date:from:in-reply-to\n :message-id:mime-version:references:subject:to; s=qcppdkim1; bh=\n zHkL2QqcQtTst0fQ5GJ4FXidX+l1htNwr6TlfSrPgj0=; b=dlQPCININEFl0b7O\n y5lkPdqKl6bO+HkcxVXDxi1eCYF9ZVaHIcWyrub//hHiDftBu2+fdzQPqkLMiOxR\n tb8c1Jc/Hzs+dYx4fam5trh1aig0R6B+TQMZVS/rHi2gLTWlawRxvn/Z3wQY5Av2\n 2mFrM0wVm7UlbOI4PSDKUT73oJKN4hlHNEar9QxX0/p9wZbyPdBISF51Knl6Dw+i\n ZfrNEJEMY2/BfW7oeQDSffL4qsno0X9Ai3uwNwqn4lALvfqB0Y6TWpZ4YOoUsiVS\n UvfemWza8RTywZ8Tu9zoTphbSUvuyUa36gUuWgXehKHHAQdzC7qS/qFYNTTsWmhV\n Vi1Jdg==","v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=oss.qualcomm.com; s=google; t=1777038334; x=1777643134; darn=gcc.gnu.org;\n h=content-transfer-encoding:in-reply-to:from:content-language\n :references:cc:to:subject:user-agent:mime-version:date:message-id\n :from:to:cc:subject:date:message-id:reply-to;\n bh=zHkL2QqcQtTst0fQ5GJ4FXidX+l1htNwr6TlfSrPgj0=;\n b=bKhnQmUkDbXx8cUUzNywca0btc4ei9CR1sSes1Hx5f8sWXOcQQQjLtS8oPlkHUrnqP\n c9il6vd7NkJh7ChCIHp7hsiP9He1PObiKDCaoRjGZh5OIAwL2ODlBWqy0LiBSuT/yBef\n EvcBxBg5X9Fqc+YYXRAAjxLVvwxBl97vqdRU1aDSHJVMrnM6eOrvtY0qvoEUqpceQq30\n TLgUAkFPXKcmygWjbGlY4SNXQtC19wyUHxX0nAfKvHH6vo6Nmd1w8NhCqz95J8y8GuUY\n UEBuuAA/MqiTg728FwzLW9+IrGZWvWetezf7BA9Lxf7Eo/MBHxILY9maO9bzmeGpHqfi\n PgxQ=="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1777038334; x=1777643134;\n h=content-transfer-encoding:in-reply-to:from:content-language\n :references:cc:to:subject:user-agent:mime-version:date:message-id\n :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=zHkL2QqcQtTst0fQ5GJ4FXidX+l1htNwr6TlfSrPgj0=;\n b=oCntgCH/SisF3k+UGuz06Ji1e0m/kcqoaL+rUS4JHhASiUaUVgB9yAaABJpxhAOexR\n QjP8KFvU1kU8ddgTD+6VHIcydAzlzCs9iktBj0vrBlDhul3qJKvWu0e68M5wpb6yjzE9\n Sy95SuHYrjtDpi4XaJZQKsXetynGmkMshR4bN5xGxqb/wvaJWUaFPlTefNVVWdNqBHY5\n JDwSo5RNsBc/2SJpplhuh/eJFGv0jtdABOhNBwGRGyV3Lv9v1Vy/SkFmdQnIi0gMmd76\n tTxT6mAs0cdAoa1vyRWq/71O5B5w70AHwfz0Ao/UBp9joxXf1vKZBz5xoX5kJi7vImv1\n lgfQ==","X-Gm-Message-State":"AOJu0YzrXOt6mdAN0albcPDS7g2lrvMYUAxXkFNawA/8ke68FeZpNWes\n zEYM4ukPzVK6MMJyQ2TltNPEY2YTs05QtciVXVMc+q4Ncp9LJytpOvHhrIegw8YhIeRmd0pms3+\n E7+0vOZLwPPUddtfTiJ7ezkQUxrO+fruUUF1zN3xxmudaQnWL/asUDAo5rXQH","X-Gm-Gg":"AeBDievO3kvkjplPMQGLacyIsQ3a6dwuXvVKOhrBJp75igpSzpV4Fz8EI/tBK41ikAh\n lwT3dZNjwLVzE4TXPCn+Sjdxe8HL/00DEI16mM/4bZbL0cIE6/GKt48UT3lo3HzcUScGq/gqVLG\n NEmgfx0oKR3mIUeWd3p5UGkGj/DnUemoMfaWwyVKS1JaRjotzXh0J/4NJfTNAYDZCAH9Glh+PvF\n It/UNwTCyIEPG/VK1aFYEGDWMrjuUePUxollU4Rbrv8mak4b6L6TykutgbzorI4/myyQOcmHI3t\n Ny+RCCin+hMiWEBSXz4KzfzZwGK0QnXaLdsLpC0M/rl2Jo4mhKbe0Y3rrJxdsNhhM973My8hjDG\n sFxufMbySt5AF+tK6Fn7fycYkl0bUobSbOzxiQBRB/bKRUCWvH3EorAxuXg97","X-Received":["by 2002:a05:7022:ec07:b0:128:cea1:7e3b with SMTP id\n a92af1059eb24-12c73f9b8c7mr14427888c88.23.1777038333882;\n Fri, 24 Apr 2026 06:45:33 -0700 (PDT)","by 2002:a05:7022:ec07:b0:128:cea1:7e3b with SMTP id\n a92af1059eb24-12c73f9b8c7mr14427866c88.23.1777038333146;\n Fri, 24 Apr 2026 06:45:33 -0700 (PDT)"],"Message-ID":"<f8032c3d-21b2-40a9-bf8f-ef0fac099980@oss.qualcomm.com>","Date":"Fri, 24 Apr 2026 07:45:31 -0600","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] RISC-V: Use long jump for crossing section boundaries","To":"Kito Cheng <kito.cheng@gmail.com>, Kito Cheng <kito.cheng@sifive.com>","Cc":"gcc-patches@gcc.gnu.org, jeffreyalaw@gmail.com,\n Monk Chiang <monk.chiang@sifive.com>","References":"<20260424025503.2589107-1-kito.cheng@sifive.com>\n <CA+yXCZA-7hd+0mH5xY3Kmt2iLiZSgK29qDvvuxDPOTJbUPVw7Q@mail.gmail.com>","Content-Language":"en-US","From":"Jeffrey Law <jeffrey.law@oss.qualcomm.com>","In-Reply-To":"\n <CA+yXCZA-7hd+0mH5xY3Kmt2iLiZSgK29qDvvuxDPOTJbUPVw7Q@mail.gmail.com>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNDI0MDEzMiBTYWx0ZWRfXwk4D16/T88lr\n zo8x1DZoaeJhKNo5O+lsYCuL40rY8B+oGctGoGOe8maSYXk5gjLFwr/8qardIRV1MjRDJ1162By\n M0a03mLh8WenM5Q4nXqthEspe9TRwTgPYO/BqTcvtEGJlLw7L/tTWU21RXHFtWWNRyGfJ+L6Kr3\n JWHDdmj47BBBBs75MvWiGJ8/9+2Ea4R3j0uZ8ZX92Jp+LhKhCLiCYK6NKlsG+9eu0hr5t+Gsvf+\n sqQmujYJfoCO5KIjKbasG2zMfEzg8RZp+lkl4vX5lpQwgFZNzk9dD19viJxDyNDAe8N4lFNvkQF\n M5hQMr39UeDucTPnR+NpXnu1Dlwj+mBjiop4AsZKrBEWhtZYRKawJ3IVRWuPjGckfh6ZG58Wqa0\n vG3gsPdoVjkGOkgzYNLATvRftPj6ckMOiqfpeMS4xkQ1TnTWFgIt6bEAbCLH8ywr0eHFFj1S/SL\n v/QN/WwB72uWQ1VB8Gw==","X-Authority-Analysis":"v=2.4 cv=UqpT8ewB c=1 sm=1 tr=0 ts=69eb73fe cx=c_pps\n a=bS7HVuBVfinNPG3f6cIo3Q==:117 a=asGLMfRmzhnGNxaIYohjRg==:17\n a=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10 a=s4-Qcg_JpJYA:10\n a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yOCtJkima9RkubShWh1s:22\n a=kXkyXb4Ux1iDidpbyyQA:9 a=QEXdDO2ut3YA:10 a=vBUdepa8ALXHeOFLBtFW:22","X-Proofpoint-ORIG-GUID":"Zt5mBsrEl91TBxl1Cqa98kmwhq0gPKqP","X-Proofpoint-GUID":"Zt5mBsrEl91TBxl1Cqa98kmwhq0gPKqP","X-Proofpoint-Virus-Version":"vendor=baseguard\n engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49\n definitions=2026-04-24_01,2026-04-21_02,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n suspectscore=0 priorityscore=1501 clxscore=1015 bulkscore=0\n lowpriorityscore=0 impostorscore=0 phishscore=0 adultscore=0 spamscore=0\n malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc=\n route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2604200000\n definitions=main-2604240132","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list <gcc-patches.gcc.gnu.org>","List-Unsubscribe":"<https://gcc.gnu.org/mailman/options/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>","List-Archive":"<https://gcc.gnu.org/pipermail/gcc-patches/>","List-Post":"<mailto:gcc-patches@gcc.gnu.org>","List-Help":"<mailto:gcc-patches-request@gcc.gnu.org?subject=help>","List-Subscribe":"<https://gcc.gnu.org/mailman/listinfo/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}}]