qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PULL 00/40] target/xtensa queue


From: Peter Maydell
Subject: Re: [Qemu-devel] [PULL 00/40] target/xtensa queue
Date: Thu, 28 Feb 2019 10:27:38 +0000

On Mon, 25 Feb 2019 at 20:32, Max Filippov <address@hidden> wrote:
>
> Hi Peter,
>
> please pull the following batch of target/xtensa updates:
>
> The following changes since commit 1c3d45df5e94042d5fb2bb31416072563ab30e49:
>
>   Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2019-02-04' into 
> staging (2019-02-05 12:46:18 +0000)
>
> are available in the git repository at:
>
>   git://github.com/OSLL/qemu-xtensa.git tags/20190225-xtensa
>
> for you to fetch changes up to 116f9089402081231ebc6d0012e4e029f21f63af:
>
>   tests/tcg/xtensa: add FPU2000 coprocessor tests (2019-02-18 22:09:10 -0800)
>
> ----------------------------------------------------------------
> target/xtensa: FLIX support, various fixes and test improvements
>
> - add FLIX (flexible length instructions extension) support;
> - make testsuite runnable on wider range of xtensa cores;
> - add floating point opcode tests;
> - don't add duplicate 'static' in import_core.sh script;
> - fix undefined opcodes detection in test_mmuhifi_c3 overlay.
>

Hi -- I'm afraid this fails to build on some clang compilers:

/Users/pm215/src/qemu-for-merges/target/xtensa/translate.c:967:14:
error: result of comparison of constant 256 with expression of type
'enum resource_type' is always true
[-Werror,-Wtautological-constant-out-of-range-compare]
    assert(r < 256 && g < 256 && n < 65536);
           ~ ^ ~~~
/usr/include/assert.h:93:25: note: expanded from macro 'assert'
    (__builtin_expect(!(e), 0) ? __assert_rtn(__func__, __FILE__,
__LINE__, #e) : (void)0)
                        ^

Here r is of type 'enum resource_type', so the compiler
is allowed to pick any type to represent it that will fit all
the values in the enum. In this case the compiler has picked
a char type. Asserting that r is either RES_REGFILE or RES_STATE
would probably work better.

thanks
-- PMM



reply via email to

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