All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Thomas Huth <thuth@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Markus Armbruster <armbru@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: Moving to C11? (was Re: Redefinition of typedefs (C11 feature))
Date: Mon, 14 Sep 2020 14:50:13 +0100	[thread overview]
Message-ID: <20200914135013.GM1252186@redhat.com> (raw)
In-Reply-To: <20200914134636.GZ1618070@habkost.net>

On Mon, Sep 14, 2020 at 09:46:36AM -0400, Eduardo Habkost wrote:
> On Mon, Sep 14, 2020 at 07:39:09AM +0200, Thomas Huth wrote:
> > On 13/09/2020 04.51, Eduardo Habkost wrote:
> > > On Sat, Sep 12, 2020 at 08:45:19AM +0200, Thomas Huth wrote:
> > >> On 11/09/2020 22.06, Eduardo Habkost wrote:
> > >>> On Fri, Sep 11, 2020 at 08:06:10PM +0100, Peter Maydell wrote:
> > >>>> On Fri, 11 Sep 2020 at 19:49, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > >>>>>
> > >>>>> I'm wondering: do our supported build host platforms all include
> > >>>>> compilers that are new enough to let us redefine typedefs?
> > >>>>>
> > >>>>> The ability to redefine typedefs is a C11 feature which would be
> > >>>>> very useful for simplifying our QOM boilerplate code.  The
> > >>>>> feature is supported by GCC since 2011 (v4.6.0)[1], and by clang
> > >>>>> since 2012 (v3.1)[2].
> > >>>>
> > >>>> In configure we mandate either GCC v4.8 or better, or
> > >>>> clang v3.4 or better, or XCode Clang v5.1 or better
> > >>>> (Apple uses a different version numbering setup to upstream).
> > >>>> So you should probably double-check that that xcode clang has
> > >>>> what you want, but it looks like we're good to go otherwise.
> > >>>
> > >>> Can anybody confirm if the following is accurate?
> > >>>
> > >>> https://gist.github.com/yamaya/2924292#file-xcode-clang-vers-L67
> > >>> # Xcode 5.1 (5B130a)
> > >>> Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
> > >>> Target: x86_64-apple-darwin13.1.0
> > >>> Thread model: posix
> > >>>
> > >>> If we know we have GCC 4.8+ or clang 3.4+, can we move to C11 and
> > >>> start using -std=gnu11?
> > >>
> > >> You don't have to switch to gnu11, redefintions of typedefs are already
> > >> fine in gnu99, they are a gnu extension there to the c99 standard.
> > >>
> > >> See also:
> > >> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=7be41675f7cb16b
> > >>
> > >> https://www.mail-archive.com/qemu-devel@nongnu.org/msg585581.html
> > > 
> > > They still trigger a warning with gnu99 on clang:
> > > 
> > > $ clang --version
> > > clang version 10.0.0 (Fedora 10.0.0-2.fc32)
> > > Target: x86_64-unknown-linux-gnu
> > > Thread model: posix
> > > InstalledDir: /usr/bin
> > > $ cat test.c
> > > typedef struct A A;
> > > typedef struct A A;
> > > $ clang -std=gnu11 -c test.c
> > > $ clang -std=gnu99 -c test.c
> > > test.c:2:18: warning: redefinition of typedef 'A' is a C11 feature [-Wtypedef-redefinition]
> > > typedef struct A A;
> > 
> > Ah, right, I forgot about that ... so for clang, we silence that warning
> > via CFLAGS in the configure script. See commit e6e90feedb706b1.
> 
> Nice, I hadn't seen that.  This means we don't need C11 for
> supporting redefinition of typedefs.
> 
> Now, do we have other reasons for not moving to C11?  It would be
> nice to make QEMU_GENERIC unnecessary and just use _Generic, for
> example.

When we set std=gnu99 in:


  commit 7be41675f7cb16be7c8d2554add7a63fa43781a8
  Author: Thomas Huth <thuth@redhat.com>
  Date:   Mon Jan 7 11:25:22 2019 +0100

    configure: Force the C standard to gnu99

we chose to not use gnu11, because this standard level is marked as
experimental in GCC 4.8 and thus we felt it wasn't a good idea to
rely on.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2020-09-14 13:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-11 18:49 Redefinition of typedefs (C11 feature) Eduardo Habkost
2020-09-11 19:06 ` Peter Maydell
2020-09-11 20:06   ` Moving to C11? (was Re: Redefinition of typedefs (C11 feature)) Eduardo Habkost
2020-09-11 20:10     ` Warner Losh
2020-09-12  8:16       ` Philippe Mathieu-Daudé
2020-09-12 15:04         ` Warner Losh
2020-09-12  6:45     ` Thomas Huth
2020-09-13  2:51       ` Eduardo Habkost
2020-09-14  5:39         ` Thomas Huth
2020-09-14 13:46           ` Eduardo Habkost
2020-09-14 13:50             ` Daniel P. Berrangé [this message]
2020-09-14 15:36             ` Thomas Huth
2020-09-14 16:53               ` Eduardo Habkost

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200914135013.GM1252186@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.