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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).