linux-next: build warning after merge of Linus' tree

linux-next: build warning after merge of Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

Hi all,

After merging the origin tree, today's linux-next build (powerpc
allyesconfig) produced this warning:

sound/aoa/codecs/onyx.c: In function 'onyx_snd_single_bit_get':
sound/aoa/codecs/onyx.c:377:37: warning: 'c' may be used uninitialized in this function [-Wmaybe-uninitialized]
  ucontrol->value.integer.value[0] = !!(c & mask) ^ polarity;
                                     ^~~~~~~~~~~~

Introduced by commit

  f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa")

This warning has been around for a long time.  It could possibly be
suppressed by checking for errors returned by onyx_read_register().

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build warning after merge of Linus' tree

[Takashi Iwai]

On Mon, 29 Jul 2019 06:04:04 +0200,
Stephen Rothwell wrote:
> 
> Hi all,
> 
> After merging the origin tree, today's linux-next build (powerpc
> allyesconfig) produced this warning:
> 
> sound/aoa/codecs/onyx.c: In function 'onyx_snd_single_bit_get':
> sound/aoa/codecs/onyx.c:377:37: warning: 'c' may be used uninitialized in this function [-Wmaybe-uninitialized]
>   ucontrol->value.integer.value[0] = !!(c & mask) ^ polarity;
>                                      ^~~~~~~~~~~~
> 
> Introduced by commit
> 
>   f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa")
> 
> This warning has been around for a long time.  It could possibly be
> suppressed by checking for errors returned by onyx_read_register().

Yes, or simply zero-ing the variable in onyx_read_register().  The
current code ignores the read error and it's been OK over a decade :)


thanks,

Takashi

Re: linux-next: build warning after merge of Linus' tree

[Johannes Berg]

On Mon, 2019-07-29 at 08:58 +0200, Takashi Iwai wrote:
> On Mon, 29 Jul 2019 06:04:04 +0200,
> Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the origin tree, today's linux-next build (powerpc
> > allyesconfig) produced this warning:
> > 
> > sound/aoa/codecs/onyx.c: In function 'onyx_snd_single_bit_get':
> > sound/aoa/codecs/onyx.c:377:37: warning: 'c' may be used uninitialized in this function [-Wmaybe-uninitialized]
> >   ucontrol->value.integer.value[0] = !!(c & mask) ^ polarity;
> >                                      ^~~~~~~~~~~~
> > 
> > Introduced by commit
> > 
> >   f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa")
> > 
> > This warning has been around for a long time.  It could possibly be
> > suppressed by checking for errors returned by onyx_read_register().
> 
> Yes, or simply zero-ing the variable in onyx_read_register().  The
> current code ignores the read error and it's been OK over a decade :)

Yeah, it's pretty weird that it never showed up before. I was wondering
for a minute why I was CC'ed on a sound merge issue :-)

Do you want me to send a patch or just commit something to suppress
this?

johannes

Re: linux-next: build warning after merge of Linus' tree

[Takashi Iwai]

On Mon, 29 Jul 2019 09:03:14 +0200,
Johannes Berg wrote:
> 
> On Mon, 2019-07-29 at 08:58 +0200, Takashi Iwai wrote:
> > On Mon, 29 Jul 2019 06:04:04 +0200,
> > Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > After merging the origin tree, today's linux-next build (powerpc
> > > allyesconfig) produced this warning:
> > > 
> > > sound/aoa/codecs/onyx.c: In function 'onyx_snd_single_bit_get':
> > > sound/aoa/codecs/onyx.c:377:37: warning: 'c' may be used uninitialized in this function [-Wmaybe-uninitialized]
> > >   ucontrol->value.integer.value[0] = !!(c & mask) ^ polarity;
> > >                                      ^~~~~~~~~~~~
> > > 
> > > Introduced by commit
> > > 
> > >   f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa")
> > > 
> > > This warning has been around for a long time.  It could possibly be
> > > suppressed by checking for errors returned by onyx_read_register().
> > 
> > Yes, or simply zero-ing the variable in onyx_read_register().  The
> > current code ignores the read error and it's been OK over a decade :)
> 
> Yeah, it's pretty weird that it never showed up before. I was wondering
> for a minute why I was CC'ed on a sound merge issue :-)

Maybe switched to a new gcc version?

> Do you want me to send a patch or just commit something to suppress
> this?

Yes, that'd be appreciated.


Thanks!

Takashi

Re: linux-next: build warning after merge of Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

Hi all,

On Mon, 29 Jul 2019 09:07:10 +0200 Takashi Iwai <tiwai@suse.de> wrote:
>
> On Mon, 29 Jul 2019 09:03:14 +0200,
> Johannes Berg wrote:
> > 
> > On Mon, 2019-07-29 at 08:58 +0200, Takashi Iwai wrote:  
> > > > This warning has been around for a long time.  It could possibly be
> > > > suppressed by checking for errors returned by onyx_read_register().  
> > > 
> > > Yes, or simply zero-ing the variable in onyx_read_register().  The
> > > current code ignores the read error and it's been OK over a decade :)  
> > 
> > Yeah, it's pretty weird that it never showed up before. I was wondering
> > for a minute why I was CC'ed on a sound merge issue :-)  
> 
> Maybe switched to a new gcc version?

Or the number of warnings in a powerpc allyesconfig build got low
enough for me to finally take notice :-)

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build warning after merge of Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 338 bytes --]

Hi all,

Building Linus' tree, today's linux-next build (htmldocs) produced
this warning:

include/net/sock.h:533: warning: Function parameter or member 'sk_peer_lock' not described in 'sock'

Introduced by commit

  35306eb23814 ("af_unix: fix races in sk_peer_pid and sk_peer_cred accesses")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build warning after merge of Linus' tree

[Eric Dumazet]

On Fri, Oct 1, 2021 at 12:18 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Building Linus' tree, today's linux-next build (htmldocs) produced
> this warning:
>
> include/net/sock.h:533: warning: Function parameter or member 'sk_peer_lock' not described in 'sock'
>
> Introduced by commit
>
>   35306eb23814 ("af_unix: fix races in sk_peer_pid and sk_peer_cred accesses")


OK, I will fix this, thank you.

linux-next: build warning after merge of Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

Hi all,

In Linus' tree, today's linux-next build (htmldocs) produced this warning:

Documentation/filesystems/index.rst:18: WARNING: toctree contains reference to nonexisting document 'filesystems/mandatory-locking'

Introduced by commit

  f7e33bdbd6d1 ("fs: remove mandatory file locking support")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build warning after merge of Linus' tree

[Jeff Layton]

On Tue, 2021-10-05 at 20:18 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> In Linus' tree, today's linux-next build (htmldocs) produced this warning:
> 
> Documentation/filesystems/index.rst:18: WARNING: toctree contains reference to nonexisting document 'filesystems/mandatory-locking'
> 
> Introduced by commit
> 
>   f7e33bdbd6d1 ("fs: remove mandatory file locking support")
> 

Thanks Stephen.

I rolled up a patch to remove that line and put it in my locks-next
branch. It should end up in linux-next soon. I'll plan to send that on
to Linus for v5.16, unless anyone thinks it needs to go in sooner.
-- 
Jeff Layton <jlayton@kernel.org>

linux-next: build warning after merge of Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 362 bytes --]

Hi all,

Building Linus' tree, today's linux-next build (htmldocs) produced
this warning:

drivers/gpu/drm/amd/include/amd_shared.h:103: warning: Enum value 'AMD_IP_BLOCK_TYPE_NUM' not described in enum 'amd_ip_block_type'

Introduced by commit

  6ee27ee27ba8 ("drm/amd/pm: avoid duplicate powergate/ungate setting")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build warning after merge of Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

Hi all,

On Tue, 23 Nov 2021 16:29:38 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Building Linus' tree, today's linux-next build (htmldocs) produced
> this warning:
> 
> drivers/gpu/drm/amd/include/amd_shared.h:103: warning: Enum value 'AMD_IP_BLOCK_TYPE_NUM' not described in enum 'amd_ip_block_type'
> 
> Introduced by commit
> 
>   6ee27ee27ba8 ("drm/amd/pm: avoid duplicate powergate/ungate setting")

I am still seeing this warning.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build warning after merge of Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

Hi all,

While building Linus' tree, today's linux-next build (htmldocs)
produced this warning:

include/media/v4l2-subdev.h:1130: warning: Function parameter or member 'client_caps' not described in 'v4l2_subdev_fh'

Introduced by commit

  f57fa2959244 ("media: v4l2-subdev: Add new ioctl for client capabilities")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build warning after merge of Linus' tree

[Sakari Ailus]

Hi Stephen,

On Mon, May 08, 2023 at 02:44:26PM +1000, Stephen Rothwell wrote:
>   f57fa2959244 ("media: v4l2-subdev: Add new ioctl for client capabilities")

There's a fix for this but it hasn't been merged yet, will be soon.

<URL:https://lore.kernel.org/linux-media/20230418105924.126608-1-tomi.valkeinen@ideasonboard.com/>

-- 
Sakari Ailus

linux-next: build warning after merge of Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

Hi all,

After merging Linus' tree, today's linux-next build (htmldocs)
produced this warning:

block/blk-settings.c:281: warning: expecting prototype for queue_limits_commit_set(). Prototype was for queue_limits_set() instead

Introduced by commit

  bff4b74625fe ("Revert "dm: use queue_limits_set"")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build warning after merge of Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

Hi all,

After merging Linus' tree, today's linux-next build (htmldocs)
produced this warning:

include/linux/folio_queue.h:91: warning: expecting prototype for folioq_count(). Prototype was for folioq_full() instead

Introduced by commit

  28e8c5c095ec ("netfs: Add folio_queue API documentation")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build warning after merge of Linus' tree

[Christian Brauner]

On Tue, Oct 01, 2024 at 01:47:29PM GMT, Stephen Rothwell wrote:
> Hi all,
> 
> After merging Linus' tree, today's linux-next build (htmldocs)
> produced this warning:
> 
> include/linux/folio_queue.h:91: warning: expecting prototype for folioq_count(). Prototype was for folioq_full() instead
> 
> Introduced by commit
> 
>   28e8c5c095ec ("netfs: Add folio_queue API documentation")

Added a commit to fix this. Thanks!

linux-next: build warning after merge of Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

Hi all,

After merging Linus' tree, today's linux-next build (htmldocs)
produced this warning:

include/linux/pipe_fs_i.h:118: warning: Function parameter or struct member 'head_tail' not described in 'pipe_inode_info'

Introduced by commit

  3d252160b818 ("fs/pipe: Read pipe->{head,tail} atomically outside pipe->mutex")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build warning after merge of Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

Hi all,

After merging Linus' tree, today's linux-next builds (sparc64 and sparc
defconfig) produced this warning:

cc1: note: unrecognized command-line option '-Wno-unterminated-string-initialization' may have been intended to silence earlier diagnostics

Introduced by commit

  9d7a0577c9db ("gcc-15: disable '-Wunterminated-string-initialization' entirely for now")

These builds were done with a gcc 11.1.0 cross compiler.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build warning after merge of Linus' tree

[Linus Torvalds]

On Tue, 22 Apr 2025 at 03:47, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> These builds were done with a gcc 11.1.0 cross compiler.

That sounds like there might be some issue with the cross-compiler
logic somewhere, because the Makefile logic is using the standard

    KBUILD_CFLAGS += $(call cc-option, xyzzy)

pattern.  We literally have seven other occurrences of that same logic
just in that same Makefile above it (and many more in other
makefiles).

IOW, it's *supposed* to only actually use the flag if the compiler
supports it, so having the compiler then say "I don't recognize that
option" is kind of odd. We've explicitly tested that the compiler
supports it.

Does the warning happen for all files that get built, or just some
specific ones? I wonder if we have some issue where we end up using
two different compilers (I'd assume native and cross-built), and we
use KBUILD_CFLAGS for the wrong compiler (or we use cc-option with the
wrong compiler, but I'd expect that to affect *everything* - that
'cc-option' thing is not some kind of unusual pattern).

It may be that the other options we check for have been around for so
long that they just don't show the issue (ie the 'cc-option' for the
other cases may also be using the wrong compiler, but then it's hidden
by the fact that both compiler versions just happen to support all the
other options anyway).

                    Linus

Re: linux-next: build warning after merge of Linus' tree

[Thomas Weißschuh]

On 2025-04-22 08:59:00-0700, Linus Torvalds wrote:
> On Tue, 22 Apr 2025 at 03:47, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > These builds were done with a gcc 11.1.0 cross compiler.
> 
> That sounds like there might be some issue with the cross-compiler
> logic somewhere, because the Makefile logic is using the standard
> 
>     KBUILD_CFLAGS += $(call cc-option, xyzzy)
> 
> pattern.  We literally have seven other occurrences of that same logic
> just in that same Makefile above it (and many more in other
> makefiles).

I think -Wno-foo is special here. By default GCC does not emit
a warning if it does not recognize a disabled warning.
This breaks the logic inside $(cc-option).
-Wfoo in contrast does emit a warning.

The original report said:
"cc1: note: unrecognized command-line option '-Wno-unterminated-string-initialization' may have been intended to silence earlier diagnostics"

Note the "earlier diagnostics" wording. And indeed the real reported
issue is "warning: #warning syscall clone3 not implemented [-Wcpp]"

To disable warnings there is a dedicated macro.

$(call cc-disable-warning, unterminated-string-initialization)


Thomas

> IOW, it's *supposed* to only actually use the flag if the compiler
> supports it, so having the compiler then say "I don't recognize that
> option" is kind of odd. We've explicitly tested that the compiler
> supports it.
> 
> Does the warning happen for all files that get built, or just some
> specific ones? I wonder if we have some issue where we end up using
> two different compilers (I'd assume native and cross-built), and we
> use KBUILD_CFLAGS for the wrong compiler (or we use cc-option with the
> wrong compiler, but I'd expect that to affect *everything* - that
> 'cc-option' thing is not some kind of unusual pattern).
> 
> It may be that the other options we check for have been around for so
> long that they just don't show the issue (ie the 'cc-option' for the
> other cases may also be using the wrong compiler, but then it's hidden
> by the fact that both compiler versions just happen to support all the
> other options anyway).

Re: linux-next: build warning after merge of Linus' tree

[Linus Torvalds]

[ Adding Masahiro explicitly in case we can just fix cc-option. See below. ]

On Tue, 22 Apr 2025 at 10:51, Thomas Weißschuh <linux@weissschuh.net> wrote:
>
> To disable warnings there is a dedicated macro.
>
> $(call cc-disable-warning, unterminated-string-initialization)

Heh. We have several other cases of that "disable warning" pattern
that does *not* use that cc-disable-warning thing.

In fact, right next to the new unterminated-string-initialization case
(just a couple of lines above it), we have a

   $(call cc-option, -Wno-stringop-overflow)

thing, along with several cases in loongarch and riscv.

So they are presumably _also_ broken, but perhaps just happened to
silently work due to compiler versions (and that stringop-overflow
case is gated by a config option that might also have hidden it from
people).

And as you say:

> Note the "earlier diagnostics" wording. And indeed the real reported
> issue is "warning: #warning syscall clone3 not implemented [-Wcpp]"

so apparently it *also* requires other warnings to actually trigger
problems, which is presumably why Stephen only sees this issue on
sparc* targets.

And which is probably the main reason why the problems with other
cases of this same issue haven't been noted.

Now, the obvious fix is to just convert all these cases to
'cc-disable-warning', and I'll do that.

But exactly because we have at least nine cases of this, maybe we
could make cc-option actually work for this by forcing that "earlier
diagnostics" case in the cc-option test?

Right now cc-option uses -Werror to turn all the warnings into errors,
and thus causes a "unrecognized compiler option" warning to be fatal.

But what if we were to add an intentional warning to the cc-options
test-case, and use -Wno-error-XYZ to make just *that* warning be
harmless, and then 'cc-option' would work for the unrecognized
command-line options for the -Wno-xyz case too?

Because even after I fix all the nine cases we've now accumulated, I
bet we'll have more in the future - just because 'cc-option' is so
much more common (a quick grep shows 429 vs 40 occurrences).

               Linus

Re: linux-next: build warning after merge of Linus' tree

[Nathan Chancellor]

On Tue, Apr 22, 2025 at 11:20:21AM -0700, Linus Torvalds wrote:
> Heh. We have several other cases of that "disable warning" pattern
> that does *not* use that cc-disable-warning thing.
> 
> In fact, right next to the new unterminated-string-initialization case
> (just a couple of lines above it), we have a
> 
>    $(call cc-option, -Wno-stringop-overflow)
> 
> thing, along with several cases in loongarch and riscv.
> 
> So they are presumably _also_ broken, but perhaps just happened to
> silently work due to compiler versions (and that stringop-overflow
> case is gated by a config option that might also have hidden it from
> people).

Indeed, there were a couple of patches that flew by recently fixing some
of those instances for that reason but I guess Masahiro may have missed
them:

https://lore.kernel.org/10b1ebd8-5d32-41a2-9454-1b40e98d5187@suse.com/
https://lore.kernel.org/4b19fae4-ba5d-45b6-ae4a-8b59c178f529@suse.com/

Cheers,
Nathan

Re: linux-next: build warning after merge of Linus' tree

[Linus Torvalds]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

On Tue, 22 Apr 2025 at 11:20, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Heh. We have several other cases of that "disable warning" pattern
> that does *not* use that cc-disable-warning thing.

Bah. I did the obvious sed-script to fix this up, and the result just
feels oh-so-wrong.

It feels so wrong because the CC_NO_STRINGOP_OVERFLOW case in the main
Makefile goes from having

 ... += $(call cc-option, -Wno-stringop-overflow)

to having the (obviously fixed)

 ... += $(call cc-disable-warning, stringop-overflow)

and the patch is clearly *right*.

But the "feels wrong" part is because the very next  (unchanged) line
in the patch is then using

 ... += $(call cc-option, -Wstringop-overflow)

for the CC_STRINGOP_OVERFLOW case.

So that patch (full patch attached if somebody wants to see it) really
makes it obvious just how unbalanced that cc-option vs
cc-disable-warning thing is.

No wonder we had this pattern wrong in several places, in other words.

              Linus

[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 3068 bytes --]

 Makefile                       | 4 ++--
 arch/loongarch/kernel/Makefile | 8 ++++----
 arch/loongarch/kvm/Makefile    | 2 +-
 arch/riscv/kernel/Makefile     | 4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Makefile b/Makefile
index e94bbb2298c8..07f818186151 100644
--- a/Makefile
+++ b/Makefile
@@ -1053,11 +1053,11 @@ NOSTDINC_FLAGS += -nostdinc
 KBUILD_CFLAGS += $(call cc-option, -fstrict-flex-arrays=3)
 
 #Currently, disable -Wstringop-overflow for GCC 11, globally.
-KBUILD_CFLAGS-$(CONFIG_CC_NO_STRINGOP_OVERFLOW) += $(call cc-option, -Wno-stringop-overflow)
+KBUILD_CFLAGS-$(CONFIG_CC_NO_STRINGOP_OVERFLOW) += $(call cc-disable-warning, stringop-overflow)
 KBUILD_CFLAGS-$(CONFIG_CC_STRINGOP_OVERFLOW) += $(call cc-option, -Wstringop-overflow)
 
 #Currently, disable -Wunterminated-string-initialization as broken
-KBUILD_CFLAGS += $(call cc-option, -Wno-unterminated-string-initialization)
+KBUILD_CFLAGS += $(call cc-disable-warning, unterminated-string-initialization)
 
 # disable invalid "can't wrap" optimizations for signed / pointers
 KBUILD_CFLAGS	+= -fno-strict-overflow
diff --git a/arch/loongarch/kernel/Makefile b/arch/loongarch/kernel/Makefile
index 4853e8b04c6f..84b1d8b36a47 100644
--- a/arch/loongarch/kernel/Makefile
+++ b/arch/loongarch/kernel/Makefile
@@ -21,10 +21,10 @@ obj-$(CONFIG_CPU_HAS_LBT)	+= lbt.o
 
 obj-$(CONFIG_ARCH_STRICT_ALIGN)	+= unaligned.o
 
-CFLAGS_module.o		+= $(call cc-option,-Wno-override-init,)
-CFLAGS_syscall.o	+= $(call cc-option,-Wno-override-init,)
-CFLAGS_traps.o		+= $(call cc-option,-Wno-override-init,)
-CFLAGS_perf_event.o	+= $(call cc-option,-Wno-override-init,)
+CFLAGS_module.o		+= $(call cc-disable-warning,override-init,)
+CFLAGS_syscall.o	+= $(call cc-disable-warning,override-init,)
+CFLAGS_traps.o		+= $(call cc-disable-warning,override-init,)
+CFLAGS_perf_event.o	+= $(call cc-disable-warning,override-init,)
 
 ifdef CONFIG_FUNCTION_TRACER
   ifndef CONFIG_DYNAMIC_FTRACE
diff --git a/arch/loongarch/kvm/Makefile b/arch/loongarch/kvm/Makefile
index f4c8e35c216a..e3f0225602ff 100644
--- a/arch/loongarch/kvm/Makefile
+++ b/arch/loongarch/kvm/Makefile
@@ -21,4 +21,4 @@ kvm-y += intc/eiointc.o
 kvm-y += intc/pch_pic.o
 kvm-y += irqfd.o
 
-CFLAGS_exit.o	+= $(call cc-option,-Wno-override-init,)
+CFLAGS_exit.o	+= $(call cc-disable-warning,override-init,)
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index 8d186bfced45..c6f9b419359c 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -9,8 +9,8 @@ CFLAGS_REMOVE_patch.o	= $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_sbi.o	= $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_return_address.o	= $(CC_FLAGS_FTRACE)
 endif
-CFLAGS_syscall_table.o	+= $(call cc-option,-Wno-override-init,)
-CFLAGS_compat_syscall_table.o += $(call cc-option,-Wno-override-init,)
+CFLAGS_syscall_table.o	+= $(call cc-disable-warning,override-init,)
+CFLAGS_compat_syscall_table.o += $(call cc-disable-warning,override-init,)
 
 ifdef CONFIG_KEXEC_CORE
 AFLAGS_kexec_relocate.o := -mcmodel=medany $(call cc-option,-mno-relax)

Re: linux-next: build warning after merge of Linus' tree

[David Laight]

On Tue, 22 Apr 2025 11:20:21 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

...
> Right now cc-option uses -Werror to turn all the warnings into errors,
> and thus causes a "unrecognized compiler option" warning to be fatal.

I think that gcc only warns for unknown -Wno-xxx if there are other
error messages.
So even with -Werror they don't cause a compilations failure.

	David

Re: linux-next: build warning after merge of Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 5626 bytes --]

Hi Linus,

On Tue, 22 Apr 2025 08:59:00 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Tue, 22 Apr 2025 at 03:47, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > These builds were done with a gcc 11.1.0 cross compiler.  
> 
> That sounds like there might be some issue with the cross-compiler
> logic somewhere, because the Makefile logic is using the standard
> 
>     KBUILD_CFLAGS += $(call cc-option, xyzzy)
> 
> pattern.  We literally have seven other occurrences of that same logic
> just in that same Makefile above it (and many more in other
> makefiles).
> 
> IOW, it's *supposed* to only actually use the flag if the compiler
> supports it, so having the compiler then say "I don't recognize that
> option" is kind of odd. We've explicitly tested that the compiler
> supports it.

Yeah, I thought it was strange.

> Does the warning happen for all files that get built, or just some
> specific ones? I wonder if we have some issue where we end up using
> two different compilers (I'd assume native and cross-built), and we
> use KBUILD_CFLAGS for the wrong compiler (or we use cc-option with the
> wrong compiler, but I'd expect that to affect *everything* - that
> 'cc-option' thing is not some kind of unusual pattern).

It happens only for a couple of files.  Here is the full sparc64 build
log:

------------------------------------------------------------------------
<stdin>:1519:2: warning: #warning syscall clone3 not implemented [-Wcpp]
cc1: note: unrecognized command-line option '-Wno-unterminated-string-initialization' may have been intended to silence earlier diagnostics
/home/sfr/next/next/arch/sparc/vdso/vclock_gettime.c:274:1: warning: no previous prototype for '__vdso_clock_gettime' [-Wmissing-prototypes]
  274 | __vdso_clock_gettime(clockid_t clock, struct __kernel_old_timespec *ts)
      | ^~~~~~~~~~~~~~~~~~~~
/home/sfr/next/next/arch/sparc/vdso/vclock_gettime.c:302:1: warning: no previous prototype for '__vdso_clock_gettime_stick' [-Wmissing-prototypes]
  302 | __vdso_clock_gettime_stick(clockid_t clock, struct __kernel_old_timespec *ts)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~
/home/sfr/next/next/arch/sparc/vdso/vclock_gettime.c:327:1: warning: no previous prototype for '__vdso_gettimeofday' [-Wmissing-prototypes]
  327 | __vdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz)
      | ^~~~~~~~~~~~~~~~~~~
/home/sfr/next/next/arch/sparc/vdso/vclock_gettime.c:363:1: warning: no previous prototype for '__vdso_gettimeofday_stick' [-Wmissing-prototypes]
  363 | __vdso_gettimeofday_stick(struct __kernel_old_timeval *tv, struct timezone *tz)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~
cc1: note: unrecognized command-line option '-Wno-unterminated-string-initialization' may have been intended to silence earlier diagnostics
In file included from /home/sfr/next/next/arch/sparc/vdso/vdso32/vclock_gettime.c:22:
/home/sfr/next/next/arch/sparc/vdso/vdso32/../vclock_gettime.c:274:1: warning: no previous prototype for '__vdso_clock_gettime' [-Wmissing-prototypes]
  274 | __vdso_clock_gettime(clockid_t clock, struct __kernel_old_timespec *ts)
      | ^~~~~~~~~~~~~~~~~~~~
/home/sfr/next/next/arch/sparc/vdso/vdso32/../vclock_gettime.c:302:1: warning: no previous prototype for '__vdso_clock_gettime_stick' [-Wmissing-prototypes]
  302 | __vdso_clock_gettime_stick(clockid_t clock, struct __kernel_old_timespec *ts)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~
/home/sfr/next/next/arch/sparc/vdso/vdso32/../vclock_gettime.c:327:1: warning: no previous prototype for '__vdso_gettimeofday' [-Wmissing-prototypes]
  327 | __vdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz)
      | ^~~~~~~~~~~~~~~~~~~
/home/sfr/next/next/arch/sparc/vdso/vdso32/../vclock_gettime.c:363:1: warning: no previous prototype for '__vdso_gettimeofday_stick' [-Wmissing-prototypes]
  363 | __vdso_gettimeofday_stick(struct __kernel_old_timeval *tv, struct timezone *tz)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~
cc1: note: unrecognized command-line option '-Wno-unterminated-string-initialization' may have been intended to silence earlier diagnostics
/home/sfr/next/next/kernel/fork.c: In function '__do_sys_clone3':
/home/sfr/next/next/kernel/fork.c:3150:2: warning: #warning clone3() entry point is missing, please fix [-Wcpp]
 3150 | #warning clone3() entry point is missing, please fix
      |  ^~~~~~~
/home/sfr/next/next/kernel/fork.c: At top level:
cc1: note: unrecognized command-line option '-Wno-unterminated-string-initialization' may have been intended to silence earlier diagnostics
/home/sfr/next/next/kernel/fork.c:3150:2: warning: #warning clone3() entry point is missing, please fix [-Wcpp]
 3150 | #warning clone3() entry point is missing, please fix
      |  ^~~~~~~
cc1: note: unrecognized command-line option '-Wno-unterminated-string-initialization' may have been intended to silence earlier diagnostics
WARNING: modpost: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned.
Is "_mcount" prototyped in <asm/asm-prototypes.h>?
------------------------------------------------------------------------

However:

$ /opt/cross/gcc-11.1.0-nolibc/sparc64-linux/bin/sparc64-linux-gcc -Werror -Wno-unterminated-string-initialization -c -x c /dev/null
$ echo $?
0
$ /opt/cross/gcc-11.1.0-nolibc/sparc64-linux/bin/sparc64-linux-gcc -Werror -Wunterminated-string-initialization -c -x c /dev/null
sparc64-linux-gcc: error: unrecognized command-line option '-Wunterminated-string-initialization'
$ echo $?
1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build warning after merge of Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 433 bytes --]

Hi all,

After merging Linus' tree, today's linux-next build (htmldocs)
produced this warning:

WARNING: include/linux/sched/mm.h:332 function parameter 'flags' not described in 'memalloc_flags_save'

Introduced by commit

  3f6d5e6a468d ("mm: introduce memalloc_flags_{save,restore}")

This has been exposed recently after a bug was fixed that caused some
warnings to not be reported.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build warning after merge of Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

Hi all,

On Thu, 27 Nov 2025 13:10:50 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging Linus' tree, today's linux-next build (htmldocs)
> produced this warning:
> 
> WARNING: include/linux/sched/mm.h:332 function parameter 'flags' not described in 'memalloc_flags_save'
> 
> Introduced by commit
> 
>   3f6d5e6a468d ("mm: introduce memalloc_flags_{save,restore}")
> 
> This has been exposed recently after a bug was fixed that caused some
> warnings to not be reported.

I am still seeing this warning.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]