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
next prev parent 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.