From: Marc-André Lureau <marcandre.lureau@redhat.com>

When --enable-debug is turned on, configure doesn't set -O level, and
uses default compiler -O0 level, which is slow.

Instead, use -Og if supported by the compiler (optimize debugging
experience), or -O1 (keeps code somewhat debuggable and works around
compiler bugs).

Unfortunately, gcc has many false-positive maybe-uninitialized
errors with Og and O1 (f27 gcc 7.2.1 20170915):

/home/elmarco/src/qemu/hw/ipmi/isa_ipmi_kcs.c: In function ‘ipmi_kcs_ioport_read’:
/home/elmarco/src/qemu/hw/ipmi/isa_ipmi_kcs.c:279:12: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
     return ret;
            ^~~
cc1: all warnings being treated as errors
make: *** [/home/elmarco/src/qemu/rules.mak:66: hw/ipmi/isa_ipmi_kcs.o] Error 1
make: *** Waiting for unfinished jobs....
/home/elmarco/src/qemu/hw/ide/ahci.c: In function ‘ahci_populate_sglist’:
/home/elmarco/src/qemu/hw/ide/ahci.c:903:58: error: ‘tbl_entry_size’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
         if ((off_idx == -1) || (off_pos < 0) || (off_pos > tbl_entry_size)) {
                                                 ~~~~~~~~~^~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [/home/elmarco/src/qemu/rules.mak:66: hw/ide/ahci.o] Error 1
/home/elmarco/src/qemu/hw/display/qxl.c: In function ‘qxl_add_memslot’:
/home/elmarco/src/qemu/hw/display/qxl.c:1397:52: error: ‘pci_start’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
     memslot.virt_end   = virt_start + (guest_end   - pci_start);
                                       ~~~~~~~~~~~~~^~~~~~~~~~~~
/home/elmarco/src/qemu/hw/display/qxl.c:1389:9: error: ‘pci_region’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
         qxl_set_guest_bug(d, "%s: pci_region = %d", __func__, pci_region);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

There seems to be a long list of related bugs in upstream GCC, some of
them are being fixed very recently:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639

For now, let's workaround it by using Wno-maybe-uninitialized (gcc-only).

Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20180104160523.22995-5-marcandre.lureau@redhat.com>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 configure | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index ac392d2..6f1b7cd 100755
--- a/configure
+++ b/configure
@@ -5194,8 +5194,19 @@ if test "$gcov" = "yes" ; then
   LDFLAGS="-fprofile-arcs -ftest-coverage $LDFLAGS"
 elif test "$fortify_source" = "yes" ; then
   CFLAGS="-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 $CFLAGS"
-elif test "$debug" = "no"; then
-  CFLAGS="-O2 $CFLAGS"
+elif test "$debug" = "yes"; then
+  if compile_prog "-Og" ""; then
+      CFLAGS="-Og $CFLAGS"
+  elif compile_prog "-O1" ""; then
+      CFLAGS="-O1 $CFLAGS"
+  fi
+  # Workaround GCC false-positive Wuninitialized bugs with Og or O1:
+  # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
+  if cc_has_warning_flag "-Wno-maybe-uninitialized"; then
+      CFLAGS="-Wno-maybe-uninitialized $CFLAGS"
+  fi
+else
+    CFLAGS="-O2 $CFLAGS"
 fi
 
 ##########################################
-- 
1.8.3.1

On 16 January 2018 at 14:16, Paolo Bonzini <pbonzini@redhat.com> wrote:
> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>
> When --enable-debug is turned on, configure doesn't set -O level, and
> uses default compiler -O0 level, which is slow.
>
> Instead, use -Og if supported by the compiler (optimize debugging
> experience), or -O1 (keeps code somewhat debuggable and works around
> compiler bugs).

This gives me a noticeably worse debug experience (using -Og),
because gdb shows a lot more "<optimised out>" variables and
function arguments. (I've been mildly irritated by this for
the last few weeks and only just figured out why this was
happening.)

Can we go back to the previous behaviour, please ? I don't
care if the build is slow if I'm debugging, but I really do
care that I don't have my variables and arguments all
optimised away by the compiler so I can't tell what's going on.

thanks
-- PMM

Peter Maydell <peter.maydell@linaro.org> writes:

> On 16 January 2018 at 14:16, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>>
>> When --enable-debug is turned on, configure doesn't set -O level, and
>> uses default compiler -O0 level, which is slow.
>>
>> Instead, use -Og if supported by the compiler (optimize debugging
>> experience), or -O1 (keeps code somewhat debuggable and works around
>> compiler bugs).
>
> This gives me a noticeably worse debug experience (using -Og),
> because gdb shows a lot more "<optimised out>" variables and
> function arguments. (I've been mildly irritated by this for
> the last few weeks and only just figured out why this was
> happening.)

I was wondering why my:

   ./configure --enable-debug --enable-debug-tcg --extra-cflags="-O0 -g3" --target-list=aarch64-linux-user

builds where showing that.

> Can we go back to the previous behaviour, please ? I don't
> care if the build is slow if I'm debugging, but I really do
> care that I don't have my variables and arguments all
> optimised away by the compiler so I can't tell what's going on.

+1

There is a lot of other stuff enabled when debugging which slows stuff
down anyway.

--
Alex Bennée

On 02/03/2018 19:48, Peter Maydell wrote:
> On 16 January 2018 at 14:16, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>>
>> When --enable-debug is turned on, configure doesn't set -O level, and
>> uses default compiler -O0 level, which is slow.
>>
>> Instead, use -Og if supported by the compiler (optimize debugging
>> experience), or -O1 (keeps code somewhat debuggable and works around
>> compiler bugs).
> 
> This gives me a noticeably worse debug experience (using -Og),
> because gdb shows a lot more "<optimised out>" variables and
> function arguments. (I've been mildly irritated by this for
> the last few weeks and only just figured out why this was
> happening.)
> 
> Can we go back to the previous behaviour, please ? I don't
> care if the build is slow if I'm debugging, but I really do
> care that I don't have my variables and arguments all
> optimised away by the compiler so I can't tell what's going on.

Ok, will do.

Thanks,

Paolo