On Tue, Feb 15, 2022 at 10:25 PM Philippe Mathieu-Daudé <f4...@amsat.org> wrote:
>
> On 15/2/22 14:06, Akihiko Odaki wrote:
> > On Tue, Feb 15, 2022 at 9:06 PM Philippe Mathieu-Daudé <f4...@amsat.org>
> > wrote:
> >>
> >> Few fixes to be able to use GCC extensions which are not
> >> available on Clang.
> >>
> >> Philippe Mathieu-Daudé (4):
> >> osdep: Avoid using Clang-specific __builtin_available()
> >> osdep: Un-inline qemu_thread_jit_execute/write
> >> audio: Rename coreaudio extension to use Objective-C compiler
> >> ui/cocoa: Ignore 'initializer overrides' warnings
> >>
> >> audio/{coreaudio.c => coreaudio.m} | 0
> >> audio/meson.build | 2 +-
> >> include/qemu/osdep.h | 21 ++-------------------
> >> ui/cocoa.m | 5 +++++
> >> util/osdep.c | 20 ++++++++++++++++++++
> >> 5 files changed, 28 insertions(+), 20 deletions(-)
> >> rename audio/{coreaudio.c => coreaudio.m} (100%)
> >>
> >> --
> >> 2.34.1
> >>
> >
> > Compiler portability is always nice to have. Making QEMU on macOS
> > compatible with GCC is good, but I don't think that would justify
> > abandoning compatibility with Clang.
>
> I am certainly not abandoning compatibility with Clang. What gives
> you this impression?
I read the description as it says it allows to introduce GCC
extensions which breaks builds with Clang.
