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