From: Hans-Peter Nilsson <h...@bitrange.com>

The change of default value for MAX_FIXED_MODE_SIZE was
approved contingent on not changing it for BPF, since it
could not be trivially ruled out to change the ABI for a
target.  See thread at
"https://gcc.gnu.org/pipermail/gcc-patches/2025-July/690288.html";.

Since this change to set it to the (current) default is
obvious, by default I'll commit it in about a week as such,
but giving target maintainers a chance to chime in now.

To check, set it to 128 for BPF, which I believe will give a
better target experience.  If you agree that'll be better
and you don't see any ABI effects, just tell, and I'll *not*
commit this patch.  If post-commit, then revert it, though
preferably not using git revert but with an explanatory
comment.  I deliberately chose not to add any comment next to
the define: if you prefer one, please tell what you want there.

Tested together with the above quoted patch for bpf-unknown-none 
and --enable-languages=c observing no change in libgcc code or 
test-results (those I can get without a simulator).  A separate 
build without this patch shows the expected improvements in 
test-results but still no change in libgcc code.

There might be a delay if you have any questions.
-- >8 --
When the default is changed, the BPF target would be
affected, so this is the "no functional change" safe change,
defining as exactly the current default.  Naive observations
of compiled code in libgcc that uses int128 types shows that
the default may be a better choice.

        * config/bpf/bpf.h (MAX_FIXED_MODE_SIZE): Define.
---
 gcc/config/bpf/bpf.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/config/bpf/bpf.h b/gcc/config/bpf/bpf.h
index 8fb55b08f03f..babf99f94094 100644
--- a/gcc/config/bpf/bpf.h
+++ b/gcc/config/bpf/bpf.h
@@ -83,6 +83,8 @@
    `allocate_stack' pattern.  */
 #define STACK_SIZE_MODE Pmode
 
+#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (DImode)
+
 /**** Layout of Source Language Data Types.  */
 
 #define INT_TYPE_SIZE         32
-- 
2.39.2

Reply via email to