[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

https://sourceware.org/bugzilla/show_bug.cgi?id=21011 --- Comment #14 from Luiz Angelo Daros de Luca --- 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.

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

https://sourceware.org/bugzilla/show_bug.cgi?id=21011 --- Comment #13 from Mark Wielaard --- (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 delibera

Re: dwfl_attach_state alternative taking Ebl?

On Tue, 2017-04-11 at 14:27 +0200, Ulf Hermann wrote: > The code would be cleaner if we could attach_state before starting to > parse. And there might be pathological cases where no valid elf file can > ever be found but we can still unwind by frame pointer. Another reason to try and get the fra

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

https://sourceware.org/bugzilla/show_bug.cgi?id=21011 --- Comment #12 from Luiz Angelo Daros de Luca --- Great! Thanks! How about libcpu/i386_disasm.c case? -- You are receiving this mail because: You are on the CC list for the bug.

Re: frame unwinding patches

On Tue, 2017-04-11 at 12:16 +0200, Ulf Hermann wrote: > > I do agree with Jan that frame pointer unwinding is notoriously > > untrustworthy. Even with some sanity checks it is hard to know whether > > you are doing a correct unwind. gdb gets away with it through pretty > > advanced frame sniffers,

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

https://sourceware.org/bugzilla/show_bug.cgi?id=21011 --- Comment #11 from Mark Wielaard --- So the flag that seem to trigger it is -Os (but only on 32bit systems?). Proposed the following: commit 7114c513fbebcca8b76796b7f64b57447ba383e1 Author: Mark Wielaard Date: Wed Apr 19 17:07:46 2017 +0

[PATCH] 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 func

[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized

https://sourceware.org/bugzilla/show_bug.cgi?id=21011 --- Comment #10 from Mark Wielaard --- 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?