From: Hans-Peter Nilsson <hp@bitrange.com>
To: Tsukasa OI <research_trasio@irq.a4lg.com>
Cc: Andrew Burgess <aburgess@redhat.com>,
Mike Frysinger <vapier@gentoo.org>,
Nick Clifton <nickc@redhat.com>,
binutils@sourceware.org
Subject: Re: [PATCH 04/40] cpu/cris: Initialize some variables on CRIS CPU
Date: Fri, 21 Oct 2022 21:59:57 -0400 (EDT) [thread overview]
Message-ID: <alpine.BSF.2.20.16.2210212153330.80122@arjuna.pair.com> (raw)
In-Reply-To: <65223c79fdfd7faf132275415cd9da9852c5bec3.1666257885.git.research_trasio@irq.a4lg.com>
On Thu, 20 Oct 2022, Tsukasa OI via Binutils wrote:
> GCC / Clang generate a warning if a variable may be used uninitialized on
> some cases (Clang: "-Wsometimes-uninitialized"). When the program is being
> built by Clang with the default configuration, it causes a build failure
> (unless "--disable-werror" is specified).
>
> Those error occur on sim/cris/semcrisv{10,32}f-switch.c but they are
> CGEN-generated files. The real cause of this problem is in cpu/cris.cpu
> which does not initialize certain variables.
I'd say the problem is an artefact of CGEN code generation, as
the conditions are exhaustive. In the generated code it's far
from obvious though...
> This commit ensures such variables are initialized to zero by default.
> Note that this commit itself does not regenerate CRIS CPU related files
> with CGEN because it still has several issues preventing regeneration.
> They are to be fixed in the later commits.
>
> cpu/ChangeLog:
>
> * cris.cpu: Initialize condres, newval and tmpres variables.
Ok with a comment saying something to the effect of "It's not
obvious in generated code that all cases are covered in the
conditional settings below, so initialize this to avoid compiler
warnings" (and referring to the previous comment for all but the
first).
Thanks!
brgds, H-P
next prev parent reply other threads:[~2022-10-22 1:59 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-20 9:25 [PATCH 00/40] sim+gdb: Suppress warnings if built with Clang (big batch 1) Tsukasa OI
2022-10-20 9:25 ` [PATCH 01/40] gdb/unittests: PR28413, suppress warnings generated by Gnulib Tsukasa OI
2022-10-20 9:25 ` [PATCH 02/40] sim: Check known getrusage declaration existence Tsukasa OI
2022-10-20 9:25 ` [PATCH 03/40] sim/aarch64: Remove unused functions Tsukasa OI
2022-10-20 9:25 ` [PATCH 04/40] cpu/cris: Initialize some variables on CRIS CPU Tsukasa OI
2022-10-22 1:59 ` Hans-Peter Nilsson [this message]
2022-10-20 9:25 ` [PATCH 05/40] cpu/cris: Add u-stall virtual unit to CRIS v32 Tsukasa OI
2022-10-22 1:44 ` Hans-Peter Nilsson
2022-10-20 9:25 ` [PATCH 06/40] sim/cris: Move declarations of f_specific_init Tsukasa OI
2022-10-22 1:46 ` Hans-Peter Nilsson
2022-10-20 9:25 ` [PATCH 07/40] sim/cris: Regenerate with CGEN Tsukasa OI
2022-10-22 2:02 ` Hans-Peter Nilsson
2022-10-20 9:25 ` [PATCH 08/40] sim/erc32: Insert void parameter Tsukasa OI
2022-10-20 9:25 ` [PATCH 09/40] sim/erc32: Use int32_t as event callback argument Tsukasa OI
2022-10-20 9:25 ` [PATCH 10/40] sim/erc32: Use int32_t as IRQ " Tsukasa OI
2022-10-20 9:25 ` [PATCH 11/40] cpu/frv: Initialize some variables Tsukasa OI
2022-10-20 9:25 ` [PATCH 12/40] sim/frv: Initialize nesr variable Tsukasa OI
2022-10-20 9:25 ` [PATCH 13/40] sim/frv: Initialize some variables Tsukasa OI
2022-10-20 9:26 ` [PATCH 14/40] sim/frv: Add explicit casts Tsukasa OI
2022-10-20 9:26 ` [PATCH 15/40] sim/h8300: Add "+ 0x0" to avoid self-assignments Tsukasa OI
2022-10-25 13:54 ` Jeff Law
2022-10-20 9:26 ` [PATCH 16/40] sim/lm32: fix some missing function declaration warnings Tsukasa OI
2022-10-20 9:26 ` [PATCH 17/40] sim/lm32: Add explicit casts Tsukasa OI
2022-10-20 9:32 ` [PATCH 00/40] sim+gdb: Suppress warnings if built with Clang (big batch 1) Tsukasa OI
2022-10-22 19:01 ` Mike Frysinger
2022-10-24 7:59 ` Tsukasa OI
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=alpine.BSF.2.20.16.2210212153330.80122@arjuna.pair.com \
--to=hp@bitrange.com \
--cc=aburgess@redhat.com \
--cc=binutils@sourceware.org \
--cc=nickc@redhat.com \
--cc=research_trasio@irq.a4lg.com \
--cc=vapier@gentoo.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).