From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>,
Rich Felker <dalias@libc.org>, Linus Walleij <linusw@kernel.org>,
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>,
linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel test robot <lkp@intel.com>
Subject: Re: [PATCH] sh: mach-rsk: rsk7203: avoid using inline compound literals
Date: Sun, 2 Aug 2026 23:07:09 -0700 [thread overview]
Message-ID: <anAvJM0u_TIgL4ck@google.com> (raw)
In-Reply-To: <32a0d810bfc56029453aa72cefa49cb40466f64e.camel@physik.fu-berlin.de>
On Mon, Aug 03, 2026 at 07:47:50AM +0200, John Paul Adrian Glaubitz wrote:
> Hello Dmitry,
>
> On Sun, 2026-08-02 at 16:18 -0700, Dmitry Torokhov wrote:
> > Using inline compound literals for property entries in software node
> > initializers causes older compilers (GCC < 14) to fail with "initializer
> > element is not constant".
> >
> > Under C11 (6.6/6.7.9), initializers for objects with static storage
> > duration must be constant expressions. Taking the address of an unnamed
> > compound literal nested inside an anonymous compound literal array is
> > not guaranteed by standard C to be a compile-time constant address,
> > causing older GCC versions to reject it.
> >
> > Fix this by declaring property entry arrays as named static const
> > variables, ensuring their symbols evaluate to unambiguous compile-time
> > address constants.
> >
> > Fixes: 6905cdac0e51 ("sh: mach-rsk: rsk7203: use static device properties for LEDs and GPIO buttons")
>
> Isn't that the patch that was forced into the kernel, overriding me
> as the maintainer of arch/sh because Linus Walleij got impatient and
> merged the patch into an immutable tree?
Yes, but incompatibility with older GCCs is not something that you'd
recognize on the spot, would you?
Also, you seem to be hung up on the notion of immutable branch. This is
simply a branch that creator promises not to rewind/rebase so that it
can be easily shared between different subsystems.
While we are at this, there are a few more patch series for SH that I
would like you to take a look at, pretty please...
Thanks.
--
Dmitry
next prev parent reply other threads:[~2026-08-03 6:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-02 23:18 [PATCH] sh: mach-rsk: rsk7203: avoid using inline compound literals Dmitry Torokhov
2026-08-03 5:47 ` John Paul Adrian Glaubitz
2026-08-03 6:07 ` Dmitry Torokhov [this message]
2026-08-03 6:20 ` John Paul Adrian Glaubitz
2026-08-03 6:23 ` Dmitry Torokhov
2026-08-06 22:05 ` Linus Walleij
2026-08-11 6:52 ` Linus Walleij
2026-08-11 6:59 ` John Paul Adrian Glaubitz
2026-08-11 7:51 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=anAvJM0u_TIgL4ck@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=dalias@libc.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linusw@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=lkp@intel.com \
--cc=ysato@users.sourceforge.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox