Il dom 21 mar 2021, 18:34 Richard Henderson <richard.hender...@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~ > >
