[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
https://sourceware.org/bugzilla/show_bug.cgi?id=21011 --- Comment #15 from Mark Wielaard --- (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.
[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
https://sourceware.org/bugzilla/show_bug.cgi?id=21011 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #16 from Mark Wielaard --- commit 7114c513fbebcca8b76796b7f64b57447ba383e1 Author: Mark Wielaard 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 Pushed to master. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH v2] Add frame pointer unwinding for aarch64
On Thu, 2017-04-20 at 14:41 +0200, Ulf Hermann wrote: > diff --git a/tests/backtrace.aarch64.fp.core.bz2 > b/tests/backtrace.aarch64.fp.core.bz2 > new file mode 100644 > index 000..ef628af > Binary files /dev/null and b/tests/backtrace.aarch64.fp.core.bz2 differ > diff --git a/tests/backtrace.aarch64.fp.exec.bz2 > b/tests/backtrace.aarch64.fp.exec.bz2 > new file mode 100755 > index 000..69ba887 > Binary files /dev/null and b/tests/backtrace.aarch64.fp.exec.bz2 differ I got these separately. I assume they are as in the email you sent on Mon, 10 Apr 2017 14:48:06 +0200 (which didn't hit the list because it had the binaries attached...) I'll but them on my mjw/fp-unwind branch (which I am rewriting currently, not pushed yet). > diff --git a/tests/run-backtrace-fp-core-aarch64.sh > b/tests/run-backtrace-fp-core-aarch64.sh > +# The binary is generated by compiling backtrace-child without debug > +# information, but with -fno-omit-frame-pointer. > +# > +# gcc -static -O2 -fno-omit-frame-pointer -D_GNU_SOURCE \ > +# -pthread -o backtrace.aarch64.fp.exec backtrace-child.c \ > +# > +# Then strip the .eh_frame and .eh_frame_hdr sections from the binary: > +# > +# strip -R .eh_frame backtrace.aarch64.fp.exec > +# strip -R .eh_frame_hdr backtrace.aarch64.fp.exec > +# > +# The core is generated by calling the binary with --gencore This description doesn't seem to match anymore. Should this be: # The binary is generated by compiling with eh_frame CFI, but with frame # pointers. # # gcc -static -O2 -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \ # -D_GNU_SOURCE -pthread -o tests/backtrace.x86_64.fp.exec -I. -Ilib \ # tests/backtrace-child.c # # The core is generated by calling the binary with --gencore Thanks, Mark
[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
https://sourceware.org/bugzilla/show_bug.cgi?id=21011 --- Comment #17 from Luiz Angelo Daros de Luca --- > 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.
