All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Randrianasulu <randrianasulu@gmail.com>
To: Thomas Huth <thuth@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Build error with git commit 8eb29f1bf5a974dc4c11d2d1f5e7c7f7a62be116 on x86_64
Date: Tue, 26 Feb 2019 12:46:41 +0300	[thread overview]
Message-ID: <201902261246.41653.randrianasulu@gmail.com> (raw)
In-Reply-To: <e9d2cf10-0c52-a1b6-2be9-e396bd76cf2f@redhat.com>

В сообщении от Tuesday 26 February 2019 12:05:02 Thomas Huth написал(а):
> On 26/02/2019 09.58, Andrew Randrianasulu wrote:
> > В сообщении от Tuesday 26 February 2019 11:54:12 вы написали:
> >> On 25/02/2019 18.29, Andrew Randrianasulu wrote:
> >>> В сообщении от Monday 25 February 2019 19:19:01 Philippe
> >>> Mathieu-Daudc3a9
> >>>
> >>> написал(а):
> >>>> Hi Andrew,
> >>>>
> >>>> On 2/23/19 1:35 AM, Andrew Randrianasulu wrote:
> >>>>> Hello!
> >>>>>
> >>>>> I just pulled latest git
> >>>>
> >>>> [...]
> >>>>
> >>>>> and default build with simple ./configure on slackware 14.2 x86-64
> >>>>> box failed like this:
> >>>>>
> >>>>> root@slax:~/src/qemu# LANG=C make -j 5
> >>>>>         CHK version_gen.h
> >>>>>   CC      qobject/block-qdict.o
> >>>>>   CC      util/thread-pool.o
> >>>>>   CC      util/main-loop.o
> >>>>>   CC      util/qemu-timer.o
> >>>>>   CC      util/iohandler.o
> >>>>>   CC      util/aio-posix.o
> >>>>> qobject/block-qdict.c: In function 'qdict_array_split':
> >>>>> qobject/block-qdict.c:259:9: error: 'subqdict' may be used
> >>>>> uninitialized in this function [-Werror=maybe-uninitialized]
> >>>>>          qlist_append_obj(*dst, subqobj ?: QOBJECT(subqdict));
> >>>>>          ^
> >>>>
> >>>> That's odd, I can not reproduce with a simple ./configure:
> >>>>
> >>>> $ cat /etc/slackware-version
> >>>> Slackware 14.2
> >>>>
> >>>> $ gcc --version
> >>>> gcc (GCC) 5.5.0
> >>>
> >>> Well, then may be this is false positive, right now another qemu
> >>> instance is busy inside same chroot, will try patch posted in earlier
> >>> mail (after removing CFLAG I added for compiling qemu at all after this
> >>> error).
> >>>
> >>> Thanks for trying to reproduce.
> >>
> >> Just to be sure: You don't compile with -O3 or -O1 or -O0 in the CFLAGS
> >> here, do you?
> >
> > This time  it was -O3, but I got some corruption in ppc64le guest's X, so
> > I plan to revert this -O3 back to default ....
>
> Ok, then that's the problem here: GCC often produces some additional
> "may be unused" warnings with -O3, and we normally only guarantee that
> QEMU compiles without warnings when using the standard -O2 optimization
> level.
> So if you want to compile with -O3, you also have to specify
> --disable-werror (or add -Wno-error=maybe-unitialized to the CFLAGS).
> But unless you have really an urgent need for O3, I'd rather recommend
> to compile with the well-tested O2 optimization level instead.

Ok, will do ....

I was hoping for some speed-up in (mt)tcg based machines, because compiling big 
programs inside qemu obviously not ultrafast.

3916 root      20   0 5442m 2.8g 3396 R  213 24.0   2758:40 qemu-system-ppc

from 'top' on host.

But then, soon-to-be 4.0 qemu should be faster in general due to all those tcg 
optimizations, so -O3 really will be dropped on my side.

Still, I have more funny observations, like this blue screen with qemu's -vga 
virtio/cirrus was present even on 2.12+, but this probably offb bug (assumes BE 
when compiled for power?) .

And 
root@slax:~/src/qemu# qemu-system-ppc64 -m 2G -display sdl,gl=on -smp 
3  -hda /mnt/alpine_disk.img -g 1120x832x24

somewhat resulted in 8-bit X display (xf86-video-fbdev over offb, i think. due 
to 'nomodeset' default in alpine kernel - another reason to recompile {first 
reason was es1370 audio device support} and alter some parameters..) 

:)

In some sense this is cool, because I can see same problem with not loading png 
images into Cinelerra-GG itself, even on 8-bit display (without GLX and 
composite), but may be it was not intended.

will look into offb's sources ...

also, -g 1186x864x32 resulted in funnuy diagonal corruption even at firmware 
screen level, and probably same happening with x86-64/kvm guest if I select 
some less comon, but exposed via xrandr mode. (this bit for -vga std, default)

>
>  Thomas

  reply	other threads:[~2019-02-26  9:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-23  0:35 [Qemu-devel] Build error with git commit 8eb29f1bf5a974dc4c11d2d1f5e7c7f7a62be116 on x86_64 Andrew Randrianasulu
2019-02-25 14:13 ` Eric Blake
2019-02-25 16:19 ` Philippe Mathieu-Daudé
2019-02-25 17:29   ` Andrew Randrianasulu
2019-02-26  8:54     ` Thomas Huth
2019-02-26  8:58       ` Andrew Randrianasulu
2019-02-26  9:05         ` Thomas Huth
2019-02-26  9:46           ` Andrew Randrianasulu [this message]
2019-02-26  9:58             ` Thomas Huth
2019-02-26 10:44               ` Andrew Randrianasulu
2019-02-26 11:05           ` Peter Maydell
2019-02-26 12:16             ` Thomas Huth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201902261246.41653.randrianasulu@gmail.com \
    --to=randrianasulu@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.