Re: [PATCH] configure: Improve alias attribute check

[Paolo Bonzini]

HRM, what about biting the bullet and making exec-vary.c a C++ source?... Then instead of making it conditional an attribute((alias)), we make it conditional on having a C++ compiler.

Making cpu-all.h compile as C++ would be complex, but we can isolate all the required declarations in a separate header file that does not need either osdep.h or glib-compat.h, and basically just have a global constructor in exec-vary.cc that forwards to a function in exec.c.

Paolo

Il dom 21 mar 2021, 18:43 Paolo Bonzini <pbonzini@redhat.com> ha scritto:

Il dom 21 mar 2021, 18:34 Richard Henderson <richard.henderson@linaro.org> ha scritto:

On 3/21/21 10:50 AM, Paolo Bonzini wrote:
>     Another workaround may be to avoid compiling exec-vary.c with -flto.  I'm not
>     sure that my meson fu is up to that.  Paolo?
>
> You would have to define a static library.

Ok.  With an extra -fno-lto flag, or can I somehow remove -flto from the
library's cflags?  Or unset the meson b_lto variable?

-fno-lto should work, yes. b_lto tries to cater to other compilers, but we don't support anything but gcc-like drivers.

>     I have filed a gcc bug report:
>
>     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99696
>
>     Hopefully someone can address that before gcc 11 gets released.  At which
>     point we need do nothing in qemu.  Aldy?

So, I've reproduced the testcase failure with gcc 9.3 (ubuntu 20.04) as well.
Which means that there are at least two releases for which this has not worked.

I think Gavin's runtime test is unnecessary.  We don't have to check the
runtime results, we can just [ "$lto" = true ], and we fairly well know it'll fail.

Yeah, if anything the test can be used to re-enable attribute((alias)) once we know there are some fixed compilers. (Though it's quite ugly to have worse compilation when cross-compiling).

Paolo

r~