All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: Arnd Bergmann <arnd@kernel.org>,
	Pratyush Yadav <pratyush@kernel.org>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Peter Foley <pefoley2@pefoley.com>,
	Pedro Falcato <pedro.falcato@gmail.com>,
	Michael Walle <michael@walle.cc>, Mark Brown <broonie@kernel.org>,
	Takahiro Kuwano <Takahiro.Kuwano@infineon.com>,
	Dhruva Gole <d-gole@ti.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-spi@vger.kernel.org
Subject: Re: [PATCH] mtd: spi-nor: avoid holes in struct spi_mem_op
Date: Thu, 20 Jul 2023 07:50:33 +0100	[thread overview]
Message-ID: <598bd9d8-249e-125c-bde3-7a63ba6dc5f7@linaro.org> (raw)
In-Reply-To: <20230719190045.4007391-1-arnd@kernel.org>



On 7/19/23 20:00, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> gcc gets confused when -ftrivial-auto-var-init=pattern is used on sparse
> bit fields such as 'struct spi_mem_op', which caused the previous false
> positive warning about an uninitialized variable:
> 
> drivers/mtd/spi-nor/spansion.c: error: 'op' is used uninitialized [-Werror=uninitialized]
> 
> In fact, the variable is fully initialized and gcc does not see it being
> used, so the warning is entirely bogus. The problem appears to be
> a misoptimization in the initialization of single bit fields when the
> rest of the bytes are not initialized.
> 
> A previous workaround added another initialization, which ended up
> shutting up the warning in spansion.c, though it apparently still happens
> in other files as reported by Peter Foley in the gcc bugzilla. The
> workaround of adding a fake initialization seems particularly bad
> because it would set values that can never be correct but prevent the
> compiler from warning about actually missing initializations.
> 
> Revert the broken workaround and instead pad the structure to only
> have bitfields that add up to full bytes, which should avoid this
> behavior in all drivers.
> 
> I also filed a new bug against gcc with what I found, so this can
> hopefully be addressed in future gcc releases. At the moment, only
> gcc-12 and gcc-13 are affected.
> 
> Cc: Peter Foley <pefoley2@pefoley.com>
> Cc: Pedro Falcato <pedro.falcato@gmail.com>
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110743
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108402
> Link: https://godbolt.org/z/efMMsG1Kx
> Fixes: 420c4495b5e56 ("mtd: spi-nor: spansion: make sure local struct does not contain garbage")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>

Miquel, would you please take this through mtd/fixes?

Cheers,
ta

WARNING: multiple messages have this Message-ID (diff)
From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: Arnd Bergmann <arnd@kernel.org>,
	Pratyush Yadav <pratyush@kernel.org>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Peter Foley <pefoley2@pefoley.com>,
	Pedro Falcato <pedro.falcato@gmail.com>,
	Michael Walle <michael@walle.cc>, Mark Brown <broonie@kernel.org>,
	Takahiro Kuwano <Takahiro.Kuwano@infineon.com>,
	Dhruva Gole <d-gole@ti.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-spi@vger.kernel.org
Subject: Re: [PATCH] mtd: spi-nor: avoid holes in struct spi_mem_op
Date: Thu, 20 Jul 2023 07:50:33 +0100	[thread overview]
Message-ID: <598bd9d8-249e-125c-bde3-7a63ba6dc5f7@linaro.org> (raw)
In-Reply-To: <20230719190045.4007391-1-arnd@kernel.org>



On 7/19/23 20:00, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> gcc gets confused when -ftrivial-auto-var-init=pattern is used on sparse
> bit fields such as 'struct spi_mem_op', which caused the previous false
> positive warning about an uninitialized variable:
> 
> drivers/mtd/spi-nor/spansion.c: error: 'op' is used uninitialized [-Werror=uninitialized]
> 
> In fact, the variable is fully initialized and gcc does not see it being
> used, so the warning is entirely bogus. The problem appears to be
> a misoptimization in the initialization of single bit fields when the
> rest of the bytes are not initialized.
> 
> A previous workaround added another initialization, which ended up
> shutting up the warning in spansion.c, though it apparently still happens
> in other files as reported by Peter Foley in the gcc bugzilla. The
> workaround of adding a fake initialization seems particularly bad
> because it would set values that can never be correct but prevent the
> compiler from warning about actually missing initializations.
> 
> Revert the broken workaround and instead pad the structure to only
> have bitfields that add up to full bytes, which should avoid this
> behavior in all drivers.
> 
> I also filed a new bug against gcc with what I found, so this can
> hopefully be addressed in future gcc releases. At the moment, only
> gcc-12 and gcc-13 are affected.
> 
> Cc: Peter Foley <pefoley2@pefoley.com>
> Cc: Pedro Falcato <pedro.falcato@gmail.com>
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110743
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108402
> Link: https://godbolt.org/z/efMMsG1Kx
> Fixes: 420c4495b5e56 ("mtd: spi-nor: spansion: make sure local struct does not contain garbage")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>

Miquel, would you please take this through mtd/fixes?

Cheers,
ta

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  parent reply	other threads:[~2023-07-20  6:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-19 19:00 [PATCH] mtd: spi-nor: avoid holes in struct spi_mem_op Arnd Bergmann
2023-07-19 19:00 ` Arnd Bergmann
2023-07-19 19:01 ` Mark Brown
2023-07-19 19:01   ` Mark Brown
2023-07-20  6:50 ` Tudor Ambarus [this message]
2023-07-20  6:50   ` Tudor Ambarus
2023-07-20  8:48   ` Miquel Raynal
2023-07-20  8:48     ` Miquel Raynal
2023-07-27 15:17 ` Miquel Raynal
2023-07-27 15:17   ` Miquel Raynal

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=598bd9d8-249e-125c-bde3-7a63ba6dc5f7@linaro.org \
    --to=tudor.ambarus@linaro.org \
    --cc=Takahiro.Kuwano@infineon.com \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=broonie@kernel.org \
    --cc=d-gole@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=pedro.falcato@gmail.com \
    --cc=pefoley2@pefoley.com \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.