* [PATCH] gdb: fix -Wmaybe-uninitialized warning in value.c
@ 2023-03-02 20:26 Simon Marchi
2023-03-02 21:00 ` Tom Tromey
0 siblings, 1 reply; 3+ messages in thread
From: Simon Marchi @ 2023-03-02 20:26 UTC (permalink / raw)
To: gdb-patches; +Cc: Simon Marchi
Since commit 11470e70ea0d ("gdb: store internalvars in an std::map"), bulding
with -O2, with g++ 11.3.0 on Ubuntu 22.04, I see:
CXX value.o
In constructor ‘internalvar::internalvar(internalvar&&)’,
inlined from ‘constexpr std::pair<_T1, _T2>::pair(_U1&&, _U2&&) [with _U1 = const char*&; _U2 = internalvar; typename std::enable_if<(std::_PCC<true, _T1, _T2>::_MoveConstructiblePair<_U1, _U2>() && std::_PCC<true, _T1, _T2>::_ImplicitlyMoveConvertiblePair<_U1, _U2>()), bool>::type <anonymous> = true; _T1 = const char*; _T2 = internalvar]’ at /usr/include/c++/11/bits/stl_pair.h:353:35,
inlined from ‘constexpr std::pair<typename std::__strip_reference_wrapper<typename std::decay<_Tp>::type>::__type, typename std::__strip_reference_wrapper<typename std::decay<_Tp2>::type>::__type> std::make_pair(_T1&&, _T2&&) [with _T1 = const char*&; _T2 = internalvar]’ at /usr/include/c++/11/bits/stl_pair.h:572:72,
inlined from ‘internalvar* create_internalvar(const char*)’ at /home/smarchi/src/binutils-gdb/gdb/value.c:1933:52:
/home/smarchi/src/binutils-gdb/gdb/value.c:1831:8: warning: ‘<unnamed>.internalvar::u’ may be used uninitialized [-Wmaybe-uninitialized]
1831 | struct internalvar
| ^~~~~~~~~~~
/home/smarchi/src/binutils-gdb/gdb/value.c: In function ‘internalvar* create_internalvar(const char*)’:
/home/smarchi/src/binutils-gdb/gdb/value.c:1933:76: note: ‘<anonymous>’ declared here
1933 | auto pair = internalvars.emplace (std::make_pair (name, internalvar (name)));
| ^
This is because the union field internalvar::u is not initialized when
constructing the temporary internalvar object above. That object is then used
for move-construction, and the (implicit) move constructor copies the
uninitialized bytes of field u over from the temporary object to the new
internalvar object. The compiler therefore complains that we use uninitialized
bytes. I don't think it's really a problem, because the internalvar object is
in the `kind == INTERNALVAR_VOID` state, in which the contents of the union is
irrelevant. Still, mute the warning by default-initializing the union.
Change-Id: I70c392842f35255f50d8e63f4099cb6685366fb7
---
gdb/value.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gdb/value.c b/gdb/value.c
index 10a7ce033fda..7b4df3383048 100644
--- a/gdb/value.c
+++ b/gdb/value.c
@@ -1853,7 +1853,7 @@ struct internalvar
enum internalvar_kind kind = INTERNALVAR_VOID;
- union internalvar_data u;
+ union internalvar_data u {};
};
/* Use std::map, a sorted container, to make the order of iteration (and
--
2.39.2
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] gdb: fix -Wmaybe-uninitialized warning in value.c
2023-03-02 20:26 [PATCH] gdb: fix -Wmaybe-uninitialized warning in value.c Simon Marchi
@ 2023-03-02 21:00 ` Tom Tromey
2023-03-02 21:03 ` Simon Marchi
0 siblings, 1 reply; 3+ messages in thread
From: Tom Tromey @ 2023-03-02 21:00 UTC (permalink / raw)
To: Simon Marchi via Gdb-patches; +Cc: Simon Marchi
>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
Simon> This is because the union field internalvar::u is not initialized when
Simon> constructing the temporary internalvar object above. That object is then used
Simon> for move-construction, and the (implicit) move constructor copies the
Simon> uninitialized bytes of field u over from the temporary object to the new
Simon> internalvar object. The compiler therefore complains that we use uninitialized
Simon> bytes. I don't think it's really a problem, because the internalvar object is
Simon> in the `kind == INTERNALVAR_VOID` state, in which the contents of the union is
Simon> irrelevant. Still, mute the warning by default-initializing the union.
Seems fine to me.
Reviewed-By: Tom Tromey <tom@tromey.com>
Tom
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] gdb: fix -Wmaybe-uninitialized warning in value.c
2023-03-02 21:00 ` Tom Tromey
@ 2023-03-02 21:03 ` Simon Marchi
0 siblings, 0 replies; 3+ messages in thread
From: Simon Marchi @ 2023-03-02 21:03 UTC (permalink / raw)
To: Tom Tromey, Simon Marchi via Gdb-patches
On 3/2/23 16:00, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
>
> Simon> This is because the union field internalvar::u is not initialized when
> Simon> constructing the temporary internalvar object above. That object is then used
> Simon> for move-construction, and the (implicit) move constructor copies the
> Simon> uninitialized bytes of field u over from the temporary object to the new
> Simon> internalvar object. The compiler therefore complains that we use uninitialized
> Simon> bytes. I don't think it's really a problem, because the internalvar object is
> Simon> in the `kind == INTERNALVAR_VOID` state, in which the contents of the union is
> Simon> irrelevant. Still, mute the warning by default-initializing the union.
>
> Seems fine to me.
> Reviewed-By: Tom Tromey <tom@tromey.com>
>
> Tom
Pushed, thanks.
Simon
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-03-02 21:03 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-02 20:26 [PATCH] gdb: fix -Wmaybe-uninitialized warning in value.c Simon Marchi
2023-03-02 21:00 ` Tom Tromey
2023-03-02 21:03 ` Simon Marchi
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).