* [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized
@ 2016-12-30 21:38 luizluca at gmail dot com
2016-12-30 23:14 ` [Bug general/21011] " luizluca at gmail dot com
` (16 more replies)
0 siblings, 17 replies; 18+ messages in thread
From: luizluca at gmail dot com @ 2016-12-30 21:38 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
Bug ID: 21011
Summary: "may be used uninitialized" error with
-Werror=maybe-uninitialized
Product: elfutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: general
Assignee: unassigned at sourceware dot org
Reporter: luizluca at gmail dot com
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
Hello,
I get this error when compiling with -Werror=maybe-uninitialized
elf_getarsym.c: In function 'elf_getarsym':
elf_getarsym.c:200:14: error: 'n' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
size_t ar_sym_len = (n + 1) * sizeof (Elf_Arsym);
I know that read_number_entries define its values unconditionally but it won't
hurt to simply use:
uint64_t n = 0;
Is it ok?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
@ 2016-12-30 23:14 ` luizluca at gmail dot com
2016-12-30 23:20 ` pmachata at gmail dot com
` (15 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: luizluca at gmail dot com @ 2016-12-30 23:14 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
--- Comment #1 from Luiz Angelo Daros de Luca <luizluca at gmail dot com> ---
Another case:
i386_disasm.c: In function 'i386_disasm':
/home/luizluca/prog-local/lede/trunk/staging_dir/toolchain-mipsel_24kc_gcc-5.4.0_musl-1.1.15/include/fortify/string.h:47:24:
error: 'str' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
(__s < __d && __s + __n > __d))
i386_disasm.c:709:17: note: 'str' was declared here
const char *str;
This is because of missing:
--- a/libcpu/i386_disasm.c
+++ b/libcpu/i386_disasm.c
@@ -822,6 +822,7 @@ i386_disasm (Ebl *ebl __attribute__((unu
/* Fallthrough */
default:
assert (! "INVALID not handled");
+ str = "";
}
}
else
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
2016-12-30 23:14 ` [Bug general/21011] " luizluca at gmail dot com
@ 2016-12-30 23:20 ` pmachata at gmail dot com
2016-12-31 15:54 ` mjw at redhat dot com
` (14 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: pmachata at gmail dot com @ 2016-12-30 23:20 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
--- Comment #2 from pmachata at gmail dot com ---
On Dec 31, 2016 00:14, "luizluca at gmail dot com" <
sourceware-bugzilla@sourceware.org> wrote:
--- a/libcpu/i386_disasm.c
+++ b/libcpu/i386_disasm.c
@@ -822,6 +822,7 @@ i386_disasm (Ebl *ebl __attribute__((unu
/* Fallthrough */
default:
assert (! "INVALID not handled");
+ str = "";
Or abort() instead? The point is that the assert always fails. Which it
does, unless you compile with -DNDEBUG. So just force it?
Thanks,
Petr
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
2016-12-30 23:14 ` [Bug general/21011] " luizluca at gmail dot com
2016-12-30 23:20 ` pmachata at gmail dot com
@ 2016-12-31 15:54 ` mjw at redhat dot com
2017-03-28 11:48 ` mark at klomp dot org
` (13 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: mjw at redhat dot com @ 2016-12-31 15:54 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
Mark Wielaard <mjw at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mjw at redhat dot com
--- Comment #3 from Mark Wielaard <mjw at redhat dot com> ---
If you are just compiling with non-standard build flags then just add
-Wno-error.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
` (2 preceding siblings ...)
2016-12-31 15:54 ` mjw at redhat dot com
@ 2017-03-28 11:48 ` mark at klomp dot org
2017-04-04 5:37 ` luizluca at gmail dot com
` (12 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: mark at klomp dot org @ 2017-03-28 11:48 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
Mark Wielaard <mark at klomp dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
CC| |mark at klomp dot org
Resolution|--- |INVALID
--- Comment #4 from Mark Wielaard <mark at klomp dot org> ---
Looks like if you compile with non-standard flags and -Wno-error this is fine.
Fell free to reopen if you believe this is not the solution.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
` (3 preceding siblings ...)
2017-03-28 11:48 ` mark at klomp dot org
@ 2017-04-04 5:37 ` luizluca at gmail dot com
2017-04-04 5:37 ` luizluca at gmail dot com
` (11 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: luizluca at gmail dot com @ 2017-04-04 5:37 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
--- Comment #6 from Luiz Angelo Daros de Luca <luizluca at gmail dot com> ---
Mark,
I know that both might be a compiler bug. However, the cost of solving them are
very low.
Yes, I might be compiling elfutils with non-standard options. However, the
non-standard might be the standard for some distribution like LEDE/OpenWRT.
The alternative for me is not to use -Wno-error but to patch the code (and
maintain the patch) until compiler gets it right. I was just hoping that fixing
this upstream will help any other elfutils users that need to compile with
those non-standard flags on.
I'll reopen only once more this bug. If you think that it should not be "fixed"
upstream, mark it again as resolved and I'll let it go.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
` (4 preceding siblings ...)
2017-04-04 5:37 ` luizluca at gmail dot com
@ 2017-04-04 5:37 ` luizluca at gmail dot com
2017-04-04 5:38 ` luizluca at gmail dot com
` (10 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: luizluca at gmail dot com @ 2017-04-04 5:37 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
--- Comment #5 from Luiz Angelo Daros de Luca <luizluca at gmail dot com> ---
Mark,
I know that both might be a compiler bug. However, the cost of solving them are
very low.
Yes, I might be compiling elfutils with non-standard options. However, the
non-standard might be the standard for some distribution like LEDE/OpenWRT.
The alternative for me is not to use -Wno-error but to patch the code (and
maintain the patch) until compiler gets it right. I was just hoping that fixing
this upstream will help any other elfutils users that need to compile with
those non-standard flags on.
I'll reopen only once more this bug. If you think that it should not be "fixed"
upstream, mark it again as resolved and I'll let it go.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
` (5 preceding siblings ...)
2017-04-04 5:37 ` luizluca at gmail dot com
@ 2017-04-04 5:38 ` luizluca at gmail dot com
2017-04-11 11:34 ` mark at klomp dot org
` (9 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: luizluca at gmail dot com @ 2017-04-04 5:38 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
Luiz Angelo Daros de Luca <luizluca at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |---
--- Comment #7 from Luiz Angelo Daros de Luca <luizluca at gmail dot com> ---
returning to unconfirmed.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
` (6 preceding siblings ...)
2017-04-04 5:38 ` luizluca at gmail dot com
@ 2017-04-11 11:34 ` mark at klomp dot org
2017-04-17 19:51 ` luizluca at gmail dot com
` (8 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: mark at klomp dot org @ 2017-04-11 11:34 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
--- Comment #8 from Mark Wielaard <mark at klomp dot org> ---
Please post how exactly you are configuring the build, compiler (version) and
flags used.
It would certainly help to have a concrete patch against current git.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
` (7 preceding siblings ...)
2017-04-11 11:34 ` mark at klomp dot org
@ 2017-04-17 19:51 ` luizluca at gmail dot com
2017-04-19 14:54 ` mark at klomp dot org
` (7 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: luizluca at gmail dot com @ 2017-04-17 19:51 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
--- Comment #9 from Luiz Angelo Daros de Luca <luizluca at gmail dot com> ---
./configure is called as:
AR="i486-openwrt-linux-musl-gcc-ar" AS="i486-openwrt-linux-musl-gcc -c -Os
-pipe -march=pentium4 -fno-caller-saves -fno-plt -fhonour-copts
-Wno-error=unused-but-set-variable -Wno-error=unused-result
-iremap/home/REDETRESC/luizluca/prog-local/lede/trunk/build_dir/target-i386_pentium4_musl/elfutils-0.168:elfutils-0.168
-Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1
-Wl,-z,now -Wl,-z,relro
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include
-D_GNU_SOURCE" LD=i486-openwrt-linux-musl-ld
NM="i486-openwrt-linux-musl-gcc-nm" CC="i486-openwrt-linux-musl-gcc"
GCC="i486-openwrt-linux-musl-gcc" CXX="i486-openwrt-linux-musl-g++"
RANLIB="i486-openwrt-linux-musl-gcc-ranlib" STRIP=i486-openwrt-linux-musl-strip
OBJCOPY=i486-openwrt-linux-musl-objcopy OBJDUMP=i486-openwrt-linux-musl-objdump
SIZE=i486-openwrt-linux-musl-size CFLAGS="-Os -pipe -march=pentium4
-fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable
-Wno-error=unused-result
-iremap/home/REDETRESC/luizluca/prog-local/lede/trunk/build_dir/target-i386_pentium4_musl/elfutils-0.168:elfutils-0.168
-Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1
-Wl,-z,now -Wl,-z,relro
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include
-D_GNU_SOURCE " CXXFLAGS="-Os -pipe -march=pentium4 -fno-caller-saves -fno-plt
-fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result
-iremap/home/REDETRESC/luizluca/prog-local/lede/trunk/build_dir/target-i386_pentium4_musl/elfutils-0.168:elfutils-0.168
-Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1
-Wl,-z,now -Wl,-z,relro
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include
-D_GNU_SOURCE "
CPPFLAGS="-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/usr/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/include/fortify
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include
"
LDFLAGS="-L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib
-L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/lib
-L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/usr/lib
-L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/lib
-znow -zrelro
-L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/lib
-Wl,-rpath-link=/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/lib
-L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/lib
-Wl,-rpath-link=/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/lib
" LIBS="-largp" ./configure --target=i486-openwrt-linux
--host=i486-openwrt-linux --build=x86_64-pc-linux-gnu --program-prefix=""
--program-suffix="" --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin
--sbindir=/usr/sbin --libexecdir=/usr/lib --sysconfdir=/etc
--datadir=/usr/share --localstatedir=/var --mandir=/usr/man --infodir=/usr/info
--disable-nls --without-lzma
My GCC is:
i486-openwrt-linux-musl-gcc --version
i486-openwrt-linux-musl-gcc (LEDE GCC 5.4.0 r3621-357efba9bb) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This is my gcc call that fails:
i486-openwrt-linux-musl-gcc -D_GNU_SOURCE -DHAVE_CONFIG_H
-DLOCALEDIR='"/usr/share/locale"' -I. -I.. -I. -I. -I../lib -I..
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/usr/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/include/fortify
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include
-std=gnu99 -Wall -Wshadow -Wformat=2 -Wold-style-definition
-Wstrict-prototypes -Wlogical-op -Werror -Wunused -Wextra
-Wstack-usage=262144 -Os -pipe -march=pentium4 -fno-caller-saves -fno-plt
-fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result
-iremap/home/REDETRESC/luizluca/prog-local/lede/trunk/build_dir/target-i386_pentium4_musl/elfutils-0.168:elfutils-0.168
-Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1
-Wl,-z,now -Wl,-z,relro
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include
-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include
-D_GNU_SOURCE -DBAD_FTS=1 -MT elf_getarsym.o -MD -MP -MF
.deps/elf_getarsym.Tpo -c -o elf_getarsym.o elf_getarsym.c
elf_getarsym.c: In function 'elf_getarsym':
elf_getarsym.c:206:11: error: 'n' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
size_t sz = n * w;
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
` (8 preceding siblings ...)
2017-04-17 19:51 ` luizluca at gmail dot com
@ 2017-04-19 14:54 ` mark at klomp dot org
2017-04-19 15:14 ` mark at klomp dot org
` (6 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: mark at klomp dot org @ 2017-04-19 14:54 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
--- Comment #10 from Mark Wielaard <mark at klomp dot org> ---
That is a pretty involved way to configure elfutils. You do add various
-Wno-error=unused-but-set-variable -Wno-error=unused-result options. Why not
just add -Wno-error=maybe-uninitialized in that case?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
` (9 preceding siblings ...)
2017-04-19 14:54 ` mark at klomp dot org
@ 2017-04-19 15:14 ` mark at klomp dot org
2017-04-19 19:50 ` luizluca at gmail dot com
` (5 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: mark at klomp dot org @ 2017-04-19 15:14 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
--- Comment #11 from Mark Wielaard <mark at klomp dot org> ---
So the flag that seem to trigger it is -Os (but only on 32bit systems?).
Proposed the following:
commit 7114c513fbebcca8b76796b7f64b57447ba383e1
Author: Mark Wielaard <mark@klomp.org>
Date: Wed Apr 19 17:07:46 2017 +0200
libelf: Initialize n to zero in elf_getarsym.
When building with gcc -Os it seems we can inline read_number_entries
but if that function fails then n will not be initialized. GCC seems not
to realize that in that case n won't be used at all. Explicitly initialize
n to zero to prevent a spurious error: 'n' may be used uninitialized in
this function [-Werror=maybe-uninitialized] in that case.
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
Signed-off-by: Mark Wielaard <mark@klomp.org>
https://sourceware.org/ml/elfutils-devel/2017-q2/msg00042.html
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
` (10 preceding siblings ...)
2017-04-19 15:14 ` mark at klomp dot org
@ 2017-04-19 19:50 ` luizluca at gmail dot com
2017-04-19 19:58 ` mark at klomp dot org
` (4 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: luizluca at gmail dot com @ 2017-04-19 19:50 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
--- Comment #12 from Luiz Angelo Daros de Luca <luizluca at gmail dot com> ---
Great! Thanks!
How about libcpu/i386_disasm.c case?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
` (11 preceding siblings ...)
2017-04-19 19:50 ` luizluca at gmail dot com
@ 2017-04-19 19:58 ` mark at klomp dot org
2017-04-19 20:07 ` luizluca at gmail dot com
` (3 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: mark at klomp dot org @ 2017-04-19 19:58 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
--- Comment #13 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Luiz Angelo Daros de Luca from comment #12)
> Great! Thanks!
>
> How about libcpu/i386_disasm.c case?
Don't use -DNDEBUG. assert is a noreturn function. The asserts in the code are
deliberately there. If they fail something is seriously wrong.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
` (12 preceding siblings ...)
2017-04-19 19:58 ` mark at klomp dot org
@ 2017-04-19 20:07 ` luizluca at gmail dot com
2017-04-25 3:38 ` mark at klomp dot org
` (2 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: luizluca at gmail dot com @ 2017-04-19 20:07 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
--- Comment #14 from Luiz Angelo Daros de Luca <luizluca at gmail dot com> ---
I do not set -DNDEBUG. All compiler flags are similar in this case. Maybe a gcc
bug?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
` (13 preceding siblings ...)
2017-04-19 20:07 ` luizluca at gmail dot com
@ 2017-04-25 3:38 ` mark at klomp dot org
2017-04-25 12:15 ` mark at klomp dot org
2017-04-25 12:49 ` luizluca at gmail dot com
16 siblings, 0 replies; 18+ messages in thread
From: mark at klomp dot org @ 2017-04-25 3:38 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
--- Comment #15 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Luiz Angelo Daros de Luca from comment #14)
> I do not set -DNDEBUG. All compiler flags are similar in this case. Maybe a
> gcc bug?
Or your alternative glibc headers don't provide enough information about assert
to the compiler?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
` (14 preceding siblings ...)
2017-04-25 3:38 ` mark at klomp dot org
@ 2017-04-25 12:15 ` mark at klomp dot org
2017-04-25 12:49 ` luizluca at gmail dot com
16 siblings, 0 replies; 18+ messages in thread
From: mark at klomp dot org @ 2017-04-25 12:15 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
Mark Wielaard <mark at klomp dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #16 from Mark Wielaard <mark at klomp dot org> ---
commit 7114c513fbebcca8b76796b7f64b57447ba383e1
Author: Mark Wielaard <mark@klomp.org>
Date: Wed Apr 19 17:07:46 2017 +0200
libelf: Initialize n to zero in elf_getarsym.
When building with gcc -Os it seems we can inline read_number_entries
but if that function fails then n will not be initialized. GCC seems not
to realize that in that case n won't be used at all. Explicitly initialize
n to zero to prevent a spurious error: 'n' may be used uninitialized in
this function [-Werror=maybe-uninitialized] in that case.
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
Signed-off-by: Mark Wielaard <mark@klomp.org>
Pushed to master.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
` (15 preceding siblings ...)
2017-04-25 12:15 ` mark at klomp dot org
@ 2017-04-25 12:49 ` luizluca at gmail dot com
16 siblings, 0 replies; 18+ messages in thread
From: luizluca at gmail dot com @ 2017-04-25 12:49 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=21011
--- Comment #17 from Luiz Angelo Daros de Luca <luizluca at gmail dot com> ---
> Or your alternative glibc headers don't provide enough information about
> assert to the compiler?
musl dropped the attribute noreturn, which got reverted sometime after.
http://www.openwall.com/lists/musl/2016/08/30/1
So, after using a recent musl, libcpu/i386_disasm.c is not an issue anymore.
Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2017-04-25 3:38 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-30 21:38 [Bug general/21011] New: "may be used uninitialized" error with -Werror=maybe-uninitialized luizluca at gmail dot com
2016-12-30 23:14 ` [Bug general/21011] " luizluca at gmail dot com
2016-12-30 23:20 ` pmachata at gmail dot com
2016-12-31 15:54 ` mjw at redhat dot com
2017-03-28 11:48 ` mark at klomp dot org
2017-04-04 5:37 ` luizluca at gmail dot com
2017-04-04 5:37 ` luizluca at gmail dot com
2017-04-04 5:38 ` luizluca at gmail dot com
2017-04-11 11:34 ` mark at klomp dot org
2017-04-17 19:51 ` luizluca at gmail dot com
2017-04-19 14:54 ` mark at klomp dot org
2017-04-19 15:14 ` mark at klomp dot org
2017-04-19 19:50 ` luizluca at gmail dot com
2017-04-19 19:58 ` mark at klomp dot org
2017-04-19 20:07 ` luizluca at gmail dot com
2017-04-25 3:38 ` mark at klomp dot org
2017-04-25 12:15 ` mark at klomp dot org
2017-04-25 12:49 ` luizluca at gmail dot com
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).