All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	"Daniel P. Berrange" <berrange@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 12:53:06 -0400	[thread overview]
Message-ID: <20200914165306.GA8079@habkost.net> (raw)
In-Reply-To: <dfa5fff5-af96-d207-2d0c-66b5f265efa7@redhat.com>

On Mon, Sep 14, 2020 at 05:36:30PM +0200, Thomas Huth wrote:
> On 14/09/2020 15.46, 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.
> 
> See https://www.mail-archive.com/qemu-devel@nongnu.org/msg585581.html
> ... c11 is still "experimental" in GCC 4.8, so I think we likely have to
> wait 'till summer next year - then we do not have to support
> RHEL7/CentOS7 anymore according our support policy, and thus we can bump
> the minimum required compiler versions.

Thanks Thomas and Daniel for the pointers.  Staying with gnu99
for a little longer sounds reasonable, now that we typedef
redefinitions are allowed.

-- 
Eduardo



      reply	other threads:[~2020-09-14 16:55 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é
2020-09-14 15:36             ` Thomas Huth
2020-09-14 16:53               ` Eduardo Habkost [this message]

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=20200914165306.GA8079@habkost.net \
    --to=ehabkost@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@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.