| Message ID | 20200205141545.180-1-yuzenghui@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] compiler.h: Don't use compile-time assert when __NO_INLINE__ is defined | expand |
On 2/5/20 6:15 AM, Zenghui Yu wrote: > Our robot reported the following compile-time warning while compiling > Qemu with -fno-inline cflags: > > In function 'load_memop', > inlined from 'load_helper' at /qemu/accel/tcg/cputlb.c:1578:20, > inlined from 'full_ldub_mmu' at /qemu/accel/tcg/cputlb.c:1624:12: > /qemu/accel/tcg/cputlb.c:1502:9: error: call to 'qemu_build_not_reached' declared with attribute error: code path is reachable > qemu_build_not_reached(); > ^~~~~~~~~~~~~~~~~~~~~~~~ > [...] > > It looks like a false-positive because only (MO_UB ^ MO_BSWAP) will > hit the default case in load_memop() while need_swap (size > 1) has > already ensured that MO_UB is not involved. > > So the thing is that compilers get confused by the -fno-inline and > just can't accurately evaluate memop_size(op) at compile time, and > then the qemu_build_not_reached() is wrongly triggered by (MO_UB ^ > MO_BSWAP). Let's carefully don't use the compile-time assert when > no functions will be inlined into their callers. > > Reported-by: Euler Robot <euler.robot@huawei.com> > Suggested-by: Richard Henderson <richard.henderson@linaro.org> > Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> > --- > > v2 is actually written by Richard Henderson. > > v1: https://lore.kernel.org/r/20200205081703.631-1-yuzenghui@huawei.com > > include/qemu/compiler.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Queued to tcg-next. r~
diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h index 85c02c16d3..c76281f354 100644 --- a/include/qemu/compiler.h +++ b/include/qemu/compiler.h @@ -236,7 +236,7 @@ * supports QEMU_ERROR, this will be reported at compile time; otherwise * this will be reported at link time due to the missing symbol. */ -#ifdef __OPTIMIZE__ +#if defined(__OPTIMIZE__) && !defined(__NO_INLINE__) extern void QEMU_NORETURN QEMU_ERROR("code path is reachable") qemu_build_not_reached(void); #else
Our robot reported the following compile-time warning while compiling Qemu with -fno-inline cflags: In function 'load_memop', inlined from 'load_helper' at /qemu/accel/tcg/cputlb.c:1578:20, inlined from 'full_ldub_mmu' at /qemu/accel/tcg/cputlb.c:1624:12: /qemu/accel/tcg/cputlb.c:1502:9: error: call to 'qemu_build_not_reached' declared with attribute error: code path is reachable qemu_build_not_reached(); ^~~~~~~~~~~~~~~~~~~~~~~~ [...] It looks like a false-positive because only (MO_UB ^ MO_BSWAP) will hit the default case in load_memop() while need_swap (size > 1) has already ensured that MO_UB is not involved. So the thing is that compilers get confused by the -fno-inline and just can't accurately evaluate memop_size(op) at compile time, and then the qemu_build_not_reached() is wrongly triggered by (MO_UB ^ MO_BSWAP). Let's carefully don't use the compile-time assert when no functions will be inlined into their callers. Reported-by: Euler Robot <euler.robot@huawei.com> Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> --- v2 is actually written by Richard Henderson. v1: https://lore.kernel.org/r/20200205081703.631-1-yuzenghui@huawei.com include/qemu/compiler.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)