[lkml]   [2022]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] s390: disable -Warray-bounds
On Wed, Jun 08, 2022 at 01:07:05PM -0700, Linus Torvalds wrote:
> Coming back to this, because my rc2 week tends to be quiet as people
> take a breather, and as such a good time for me to do system upgrades.
> And gcc-12 dropped in Fedora 36, and shows problems on x86 too.
> So I suspect we'll have to disable -Warray-bounds globally on gcc-12,
> not just on s390.
> Unless Kees has patches ready to go already.

I and others have been working through a bunch of them, though yes,
they're not all fixed yet. I've been trying to track it here[1], but
many of those fixes are only in -next.

> Some of the warnings look potentially simple, ie
> struct mbus_dram_target_info;
> in <linux/mbus.h> has the comment
> * [..] Peripherals are
> * required to support at least 4 decode windows.
> and then as a result has
> int num_cs;
> struct mbus_dram_window {
> [..]
> } cs[4];
> and that "cs[4]" looks just bogus - it can be a much larger array, the
> '4' is just a minimum. The real limit is that 'num_cs' one.
> But there's a *lot* of warnings, and many of them are due to this, and
> while some are obvious, others aren't.

When I did a count in -next 2 weeks ago, there were 182 warnings (x86
allmodconfig) from GCC 12 where 153 were from -Warray-bounds. Today
we're now down to 80 total (61 from -Warray-bounds), so we've solved
over half of them.

> There are other things too in gcc-12 that seem half-baked. I was
> interested to see the new '-Wdangling-pointer' thing, but then when I
> looked at it, the two cases I looked at were just bogus, so ..

Yes, GCC 12 is very odd in places. Besides the literal-as-pointer issue
that still causes problems for s390[2], there seem to be at least a
few other bugs associated with the internal diagnostics infrastructure
that informs -Warray-bounds, -Wstringop-overflow, etc. I narrowed down
one recently with UBSAN_BOUNDS[3] (which therefore impacts all*config
builds), but there is no GCC fix yet. :(

So, it's unclear to me if we want to try to get back to 0 warnings
(where we were with v5.18 and GCC 11) in the next couple weeks, or if we
need to just disable it for GCC 12 until everything is fixed again.



Kees Cook

 \ /
  Last update: 2022-09-17 16:25    [W:0.264 / U:1.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site