qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Build error with git commit 8eb29f1bf5a974dc4c11d2d1f5e


From: Andrew Randrianasulu
Subject: Re: [Qemu-devel] Build error with git commit 8eb29f1bf5a974dc4c11d2d1f5e7c7f7a62be116 on x86_64
Date: Tue, 26 Feb 2019 12:46:41 +0300
User-agent: KMail/1.9.10

В сообщении от 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:
> >>>>>
> >>>>> address@hidden:~/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 
address@hidden:~/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 via email to

[Prev in Thread] Current Thread [Next in Thread]