See the respective bullet point in the Caveats section of https://gcc.gnu.org/gcc-15/changes.html.
While I'm unaware of us currently relying on the pre-gcc15 behavior, let's still play safe and retain what unknowingly we may have been relying upon. According to my observations, on x86 generated code changes - somewhere deep in modify_bars(), presumably from the struct map_data initializer in apply_map() (a new MOVQ), - in vpci_process_pending(), apparently again from the struct map_data initializer (and again a new MOVQ), - near the top of find_cpio_data(), presumably from the struct cpio_data initializer (a MOVW changing to a MOVQ). Requested-by: Andrew Cooper <andrew.coop...@citrix.com> Signed-off-by: Jan Beulich <jbeul...@suse.com> --- apply_map() being inlined is kind of against our intentions, seeing that it's marked __init. Should we add noinline there? After all post-init this is effectively unreachable code, which Misra opposes to. --- a/xen/Makefile +++ b/xen/Makefile @@ -396,6 +396,7 @@ endif CFLAGS-$(CONFIG_CC_SPLIT_SECTIONS) += -ffunction-sections -fdata-sections CFLAGS += -nostdinc -fno-builtin -fno-common +$(call cc-option-add,CFLAGS,CC,-fzero-init-padding-bits=all) CFLAGS += -Werror -Wredundant-decls -Wwrite-strings -Wno-pointer-arith CFLAGS += -Wdeclaration-after-statement -Wuninitialized $(call cc-option-add,CFLAGS,CC,-Wvla)
