Created attachment 2066364 [details]
full build log

See also bug 2338348.

GCC 15 defaults to C23 by default, whereas older versions defaulted to C17; see https://gcc.gnu.org/gcc-15/porting_to.html#c23

The simplest workaround may be to add -std=gnu17 to your build flags, but ultimately this code probably should be ported to C23.

Note that FWIW bug 2338348 also showed a failure on aarch64 due to -Werror=unterminated-string-initialization.

(more specifically https://gcc.gnu.org/gcc-15/porting_to.html#c23-new-keywords )

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZTAABZJRPPJONAFNKJMH7NJGRH7PW55M/

Note, you might want to similarly change the va_start definition in include/linux/stdarg.h from
#define va_start(v, l)  __builtin_va_start(v, l)
to
#if __STDC_VERSION__ >= 202311L
#define va_start(...) __builtin_c23_va_start(__VA_ARGS__)
#else
#define va_start(v,l)   __builtin_va_start(v,l)
#endif
or so (perhaps with some guard not to use __builtin_c23_va_start in clang until it implements it).
The old GCC definition of va_start for C23 was
#define va_start(v, ...)        __builtin_va_start(v, 0)

https://lkml.org/lkml/2025/1/20/511

(In reply to Jakub Jelinek from comment #5)
> https://lkml.org/lkml/2025/1/20/511

Thx for this. 

TWIMC: I applied this to my daily builds and ran into a ton of warnings like 
"""
drivers/gpu/drm/i915/gvt/opregion.c: In function ‘intel_vgpu_init_opregion’:
drivers/gpu/drm/i915/gvt/opregion.c:35:28: error: initializer-string for array of ‘char’ is too long [-Werror=unterminated-string-initialization]
""" 
See https://download.copr.fedorainfracloud.org/results/@kernel-vanilla/fedora/fedora-rawhide-x86_64/08554599-mainline-fedora-rawhide/builder-live.log.gz

Disabling WERROR might make the build work, haven't looked closer yet.

That is a (semi-)new warning.
Short testcase
void bar (const char *);

void
foo (void)
{
  const char a[16] = "IntelGraphicsMem";
  bar (a);
}
This is invalid in C++:
111.c: In function ‘void foo()’:
111.c:6:22: error: initializer-string for ‘const char [16]’ is too long [-fpermissive]
    6 |   const char a[16] = "IntelGraphicsMem";
      |                      ^~~~~~~~~~~~~~~~~~
and in C it has been warned about in GCC 14 and older for years with explicit -Wc++-compat:
111.c: In function ‘foo’:
111.c:6:22: warning: initializer-string for array of ‘char’ is too long for C++ [-Wc++-compat]
    6 |   const char a[16] = "IntelGraphicsMem";
      |                      ^~~~~~~~~~~~~~~~~~
Now, in GCC 15 this became a separate warning (enabled by -Wextra or -Wc++-compat).
See https://gcc.gnu.org/r15-2026 for details.

So, depending on how often this happens and whether it is intentional (in this case it looks like that),
you could choose to disable the warning locally for such cases using
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunterminated-string-initialization"
  const char a[16] = "IntelGraphicsMem";
#pragma GCC diagnostic pop
or disable the warning for the whole kernel (add -Wno-unterminated-string-initialization somewhere).
Though, you won't get warnings for it even when it would be desirable.

(In reply to Jakub Jelinek from comment #7)
> That is a (semi-)new warning.
> Short testcase
> void bar (const char *);
> 
> void
> foo (void)
> {
>   const char a[16] = "IntelGraphicsMem";
>   bar (a);
> }
> Now, in GCC 15 this became a separate warning (enabled by -Wextra or
> -Wc++-compat).
> See https://gcc.gnu.org/r15-2026 for details.

I'm surprised this was committed with a commit message claiming this is rare. I don't think it is.

There already is -Wstringop-overread, enabled by default, that is likely to be triggered if such constants are used where strings are expected. It certainly makes sense to warn about discarded bytes before the terminating null byte, which GCC does (also by default). Curiously, this warning is not controlled by -Wunterminated-string-initialization for some reason.

Is there a way to suppress this warning in C by annotating the literal? Basically creating a literal without a terminating null byte? I think this is possible in C++, although I have not tried to implement it.

Damage from this is likely to be limited for now because it's under -Wextra.

Note, I wasn't aware of this change at all (and guess it should be documented in changes.html).
{ 'I', 'n', 't', 'e', 'l', 'G', 'r', 'a', 'p', 'h', 'i', 'c', 's', 'M', 'e', 'm' };
instead of "IntelGraphicsMem" certainly works around the warning and makes the non-'\0' initialization clear.

We do have the patch sent to lkml included in the fedora kernel, but yes, these errors do appear in at least 2 different drivers killing the builds on both x86 and aarch64. I don't know if they are in more drivers than that because the build is killed at the first occurrence.

So try building with additional -Wno-error=unterminated-string-initialization to see all these warnings on all the architectures.