From: Borislav Petkov <bp@alien8.de>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Yazen Ghannam <yazen.ghannam@amd.com>, Tom Rix <trix@redhat.com>,
tony.luck@intel.com, james.morse@arm.com, mchehab@kernel.org,
rric@kernel.org, linux-edac@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] EDAC/amd64: Shut up an -Werror,-Wsometimes-uninitialized clang false positive
Date: Tue, 14 Feb 2023 17:38:51 +0100 [thread overview]
Message-ID: <Y+u5GytbjF1be9sw@zn.tnic> (raw)
In-Reply-To: <Y+ubhHlWFv4ifmGn@dev-arch.thelio-3990X>
On Tue, Feb 14, 2023 at 07:32:36AM -0700, Nathan Chancellor wrote:
> So I disagree with the characterization that clang is "overeager to
> report false positives" and I think the opinionated parts of the commit
> message could be replaced with some of the technical analysis that Tom
> and I did to show why this is a false positive but not one clang can
> reason about with the way the code is structured (since the warning does
> not perform interprocedural analysis).
I'm sure you can create all kinds of cases like this one if
interprocedural analysis or aggressive inlining doesn't happen. So I'm
rather surprised that this is the first false positive to happen. But
whateva.
And since we're disagreeing with things: I don't mind if this is a false
positive - I don't care. What I don't agree with is having -Werror fail
the build because of it and forcing us to "wag the dog", so to speak.
And you can imagine that this has been happening for a while now. And it
can explain my reaction to yet another compiler fix.
But ok, we've wasted enough time on this, lemme tone down the commit
message and commit it.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
prev parent reply other threads:[~2023-02-14 16:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 19:15 [PATCH] EDAC/amd64: remove unneeded call to reserve_mc_sibling_devs() Tom Rix
2023-02-13 20:12 ` Yazen Ghannam
2023-02-13 20:23 ` Borislav Petkov
2023-02-13 20:28 ` Nathan Chancellor
2023-02-13 21:17 ` Tom Rix
2023-02-13 22:11 ` Yazen Ghannam
2023-02-13 22:16 ` Nathan Chancellor
2023-02-14 9:55 ` [PATCH] EDAC/amd64: Shut up an -Werror,-Wsometimes-uninitialized clang false positive Borislav Petkov
2023-02-14 14:32 ` Nathan Chancellor
2023-02-14 15:04 ` Yazen Ghannam
2023-02-14 16:27 ` Nathan Chancellor
2023-02-14 16:38 ` Borislav Petkov [this message]
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=Y+u5GytbjF1be9sw@zn.tnic \
--to=bp@alien8.de \
--cc=james.morse@arm.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=nathan@kernel.org \
--cc=rric@kernel.org \
--cc=tony.luck@intel.com \
--cc=trix@redhat.com \
--cc=yazen.ghannam@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox