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