diff mbox series

[v2,02/13] qemu/atomic: Drop special case for unsupported compiler

Message ID 20201126112915.525285-3-marcandre.lureau@redhat.com
State New
Headers show
Series Remove GCC < 4.8 checks | expand

Commit Message

Marc-André Lureau Nov. 26, 2020, 11:29 a.m. UTC 
From: Philippe Mathieu-Daudé <philmd@redhat.com>

Since commit efc6c070aca ("configure: Add a test for the
minimum compiler version") the minimum compiler version
required for GCC is 4.8, which has the GCC BZ#36793 bug fixed.

We can safely remove the special case introduced in commit
a281ebc11a6 ("virtio: add missing mb() on notification").

With clang 3.8 (xenial amd64) __ATOMIC_RELAXED is defined, so the chunk
to remove (which is x86-specific), isn't reached.

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 include/qemu/atomic.h | 17 -----------------
 1 file changed, 17 deletions(-)

Comments

Peter Maydell Nov. 26, 2020, 11:49 a.m. UTC | #1 
On Thu, 26 Nov 2020 at 11:29, <marcandre.lureau@redhat.com> wrote:
>
> From: Philippe Mathieu-Daudé <philmd@redhat.com>
>
> Since commit efc6c070aca ("configure: Add a test for the
> minimum compiler version") the minimum compiler version
> required for GCC is 4.8, which has the GCC BZ#36793 bug fixed.
>
> We can safely remove the special case introduced in commit
> a281ebc11a6 ("virtio: add missing mb() on notification").
>
> With clang 3.8 (xenial amd64) __ATOMIC_RELAXED is defined, so the chunk
> to remove (which is x86-specific), isn't reached.

The minimum clang version enforced by configure is 3.4, not 3.8.
(Or Apple XCode clang 5.1 -- they use a different versioning scheme!)

thanks
-- PMM
Daniel P. Berrangé Nov. 26, 2020, 12:06 p.m. UTC | #2 
On Thu, Nov 26, 2020 at 11:49:28AM +0000, Peter Maydell wrote:
> On Thu, 26 Nov 2020 at 11:29, <marcandre.lureau@redhat.com> wrote:
> >
> > From: Philippe Mathieu-Daudé <philmd@redhat.com>
> >
> > Since commit efc6c070aca ("configure: Add a test for the
> > minimum compiler version") the minimum compiler version
> > required for GCC is 4.8, which has the GCC BZ#36793 bug fixed.
> >
> > We can safely remove the special case introduced in commit
> > a281ebc11a6 ("virtio: add missing mb() on notification").
> >
> > With clang 3.8 (xenial amd64) __ATOMIC_RELAXED is defined, so the chunk
> > to remove (which is x86-specific), isn't reached.
> 
> The minimum clang version enforced by configure is 3.4, not 3.8.
> (Or Apple XCode clang 5.1 -- they use a different versioning scheme!)

We picked clang 3.4 based on fact that is what ships in EPEL7, and
Debian Jessie 3.5.  We then picked the XCode version to match.

Based on our platform support matrix we no longer support Debian
Jessie, and IMHO we also don't really need to consider 3rd party
add-on repos shipping non-default toolschains. So IMHO we could
entirely ignore clang in EPEL7 when picking min versions.

IOW, we are likely justified in picking a new clang version if
someone wants to research what is a suitable min version across
our intended supported distros.

Regards,
Daniel
Peter Maydell Nov. 26, 2020, 12:13 p.m. UTC | #3 
On Thu, 26 Nov 2020 at 12:06, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Thu, Nov 26, 2020 at 11:49:28AM +0000, Peter Maydell wrote:
> > On Thu, 26 Nov 2020 at 11:29, <marcandre.lureau@redhat.com> wrote:
> > >
> > > From: Philippe Mathieu-Daudé <philmd@redhat.com>
> > >
> > > Since commit efc6c070aca ("configure: Add a test for the
> > > minimum compiler version") the minimum compiler version
> > > required for GCC is 4.8, which has the GCC BZ#36793 bug fixed.
> > >
> > > We can safely remove the special case introduced in commit
> > > a281ebc11a6 ("virtio: add missing mb() on notification").
> > >
> > > With clang 3.8 (xenial amd64) __ATOMIC_RELAXED is defined, so the chunk
> > > to remove (which is x86-specific), isn't reached.
> >
> > The minimum clang version enforced by configure is 3.4, not 3.8.
> > (Or Apple XCode clang 5.1 -- they use a different versioning scheme!)
>
> We picked clang 3.4 based on fact that is what ships in EPEL7, and
> Debian Jessie 3.5.  We then picked the XCode version to match.
>
> Based on our platform support matrix we no longer support Debian
> Jessie, and IMHO we also don't really need to consider 3rd party
> add-on repos shipping non-default toolschains. So IMHO we could
> entirely ignore clang in EPEL7 when picking min versions.
>
> IOW, we are likely justified in picking a new clang version if
> someone wants to research what is a suitable min version across
> our intended supported distros.

Sure, but if we do that then the series should start with the
"bump the minimum clang version" patch with accompanying
justification.

thanks
-- PMM
Marc-André Lureau Dec. 10, 2020, 1:17 p.m. UTC | #4 
Hi

On Thu, Nov 26, 2020 at 4:23 PM Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Thu, 26 Nov 2020 at 12:06, Daniel P. Berrangé <berrange@redhat.com>
> wrote:
> >
> > On Thu, Nov 26, 2020 at 11:49:28AM +0000, Peter Maydell wrote:
> > > On Thu, 26 Nov 2020 at 11:29, <marcandre.lureau@redhat.com> wrote:
> > > >
> > > > From: Philippe Mathieu-Daudé <philmd@redhat.com>
> > > >
> > > > Since commit efc6c070aca ("configure: Add a test for the
> > > > minimum compiler version") the minimum compiler version
> > > > required for GCC is 4.8, which has the GCC BZ#36793 bug fixed.
> > > >
> > > > We can safely remove the special case introduced in commit
> > > > a281ebc11a6 ("virtio: add missing mb() on notification").
> > > >
> > > > With clang 3.8 (xenial amd64) __ATOMIC_RELAXED is defined, so the
> chunk
> > > > to remove (which is x86-specific), isn't reached.
> > >
> > > The minimum clang version enforced by configure is 3.4, not 3.8.
> > > (Or Apple XCode clang 5.1 -- they use a different versioning scheme!)
> >
> > We picked clang 3.4 based on fact that is what ships in EPEL7, and
> > Debian Jessie 3.5.  We then picked the XCode version to match.
> >
> > Based on our platform support matrix we no longer support Debian
> > Jessie, and IMHO we also don't really need to consider 3rd party
> > add-on repos shipping non-default toolschains. So IMHO we could
> > entirely ignore clang in EPEL7 when picking min versions.
> >
> > IOW, we are likely justified in picking a new clang version if
> > someone wants to research what is a suitable min version across
> > our intended supported distros.
>
> Sure, but if we do that then the series should start with the
> "bump the minimum clang version" patch with accompanying
> justification.
>


With clang-3.4.2-9.el7.x86_64 (epel7), __ATOMIC_RELAXED is defined. I'll
update the commit message.

Some research on google suggests that it might be true also with XCode
clang 5.1, I could use some help to verify that:
clang -dM -E - < /dev/null | grep __ATOMIC_RELAXED
Daniel P. Berrangé Dec. 10, 2020, 1:42 p.m. UTC | #5 
On Thu, Dec 10, 2020 at 05:17:05PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Thu, Nov 26, 2020 at 4:23 PM Peter Maydell <peter.maydell@linaro.org>
> wrote:
> 
> > On Thu, 26 Nov 2020 at 12:06, Daniel P. Berrangé <berrange@redhat.com>
> > wrote:
> > >
> > > On Thu, Nov 26, 2020 at 11:49:28AM +0000, Peter Maydell wrote:
> > > > On Thu, 26 Nov 2020 at 11:29, <marcandre.lureau@redhat.com> wrote:
> > > > >
> > > > > From: Philippe Mathieu-Daudé <philmd@redhat.com>
> > > > >
> > > > > Since commit efc6c070aca ("configure: Add a test for the
> > > > > minimum compiler version") the minimum compiler version
> > > > > required for GCC is 4.8, which has the GCC BZ#36793 bug fixed.
> > > > >
> > > > > We can safely remove the special case introduced in commit
> > > > > a281ebc11a6 ("virtio: add missing mb() on notification").
> > > > >
> > > > > With clang 3.8 (xenial amd64) __ATOMIC_RELAXED is defined, so the
> > chunk
> > > > > to remove (which is x86-specific), isn't reached.
> > > >
> > > > The minimum clang version enforced by configure is 3.4, not 3.8.
> > > > (Or Apple XCode clang 5.1 -- they use a different versioning scheme!)
> > >
> > > We picked clang 3.4 based on fact that is what ships in EPEL7, and
> > > Debian Jessie 3.5.  We then picked the XCode version to match.
> > >
> > > Based on our platform support matrix we no longer support Debian
> > > Jessie, and IMHO we also don't really need to consider 3rd party
> > > add-on repos shipping non-default toolschains. So IMHO we could
> > > entirely ignore clang in EPEL7 when picking min versions.
> > >
> > > IOW, we are likely justified in picking a new clang version if
> > > someone wants to research what is a suitable min version across
> > > our intended supported distros.
> >
> > Sure, but if we do that then the series should start with the
> > "bump the minimum clang version" patch with accompanying
> > justification.
> >
> 
> 
> With clang-3.4.2-9.el7.x86_64 (epel7), __ATOMIC_RELAXED is defined. I'll
> update the commit message.
> 
> Some research on google suggests that it might be true also with XCode
> clang 5.1, I could use some help to verify that:
> clang -dM -E - < /dev/null | grep __ATOMIC_RELAXED

The oldest xcode that travis has support for is 7.3. I'd really just
suggest bumping min clang to something more modern, than trying to
find xcode 5.1
 

Regards,
Daniel
Daniel P. Berrangé Dec. 10, 2020, 1:50 p.m. UTC | #6 
On Thu, Dec 10, 2020 at 01:42:51PM +0000, Daniel P. Berrangé wrote:
> On Thu, Dec 10, 2020 at 05:17:05PM +0400, Marc-André Lureau wrote:
> > Hi
> > 
> > On Thu, Nov 26, 2020 at 4:23 PM Peter Maydell <peter.maydell@linaro.org>
> > wrote:
> > 
> > > On Thu, 26 Nov 2020 at 12:06, Daniel P. Berrangé <berrange@redhat.com>
> > > wrote:
> > > >
> > > > On Thu, Nov 26, 2020 at 11:49:28AM +0000, Peter Maydell wrote:
> > > > > On Thu, 26 Nov 2020 at 11:29, <marcandre.lureau@redhat.com> wrote:
> > > > > >
> > > > > > From: Philippe Mathieu-Daudé <philmd@redhat.com>
> > > > > >
> > > > > > Since commit efc6c070aca ("configure: Add a test for the
> > > > > > minimum compiler version") the minimum compiler version
> > > > > > required for GCC is 4.8, which has the GCC BZ#36793 bug fixed.
> > > > > >
> > > > > > We can safely remove the special case introduced in commit
> > > > > > a281ebc11a6 ("virtio: add missing mb() on notification").
> > > > > >
> > > > > > With clang 3.8 (xenial amd64) __ATOMIC_RELAXED is defined, so the
> > > chunk
> > > > > > to remove (which is x86-specific), isn't reached.
> > > > >
> > > > > The minimum clang version enforced by configure is 3.4, not 3.8.
> > > > > (Or Apple XCode clang 5.1 -- they use a different versioning scheme!)
> > > >
> > > > We picked clang 3.4 based on fact that is what ships in EPEL7, and
> > > > Debian Jessie 3.5.  We then picked the XCode version to match.
> > > >
> > > > Based on our platform support matrix we no longer support Debian
> > > > Jessie, and IMHO we also don't really need to consider 3rd party
> > > > add-on repos shipping non-default toolschains. So IMHO we could
> > > > entirely ignore clang in EPEL7 when picking min versions.
> > > >
> > > > IOW, we are likely justified in picking a new clang version if
> > > > someone wants to research what is a suitable min version across
> > > > our intended supported distros.
> > >
> > > Sure, but if we do that then the series should start with the
> > > "bump the minimum clang version" patch with accompanying
> > > justification.
> > >
> > 
> > 
> > With clang-3.4.2-9.el7.x86_64 (epel7), __ATOMIC_RELAXED is defined. I'll
> > update the commit message.
> > 
> > Some research on google suggests that it might be true also with XCode
> > clang 5.1, I could use some help to verify that:
> > clang -dM -E - < /dev/null | grep __ATOMIC_RELAXED
> 
> The oldest xcode that travis has support for is 7.3. I'd really just
> suggest bumping min clang to something more modern, than trying to
> find xcode 5.1

Actually, since you've validated main clang 3.4 code, you can assume
this applies equally to xcode 5.1, as that is using the clang 3.4 codebase.

Basically we can assume features match across the regular and xcode
clangs, with the mapped versions. IOW changing either is sufficient,
no need to check both IMHO.

  https://en.wikipedia.org/wiki/Xcode#Xcode_5.0_-_6.x_(since_arm64_support)_2

Regards,
Daniel
diff mbox series

Patch

diff --git a/include/qemu/atomic.h b/include/qemu/atomic.h
index c409257c11..8f4b3a80fb 100644
--- a/include/qemu/atomic.h
+++ b/include/qemu/atomic.h
@@ -241,23 +241,6 @@ 
 
 #else /* __ATOMIC_RELAXED */
 
-/*
- * We use GCC builtin if it's available, as that can use mfence on
- * 32-bit as well, e.g. if built with -march=pentium-m. However, on
- * i386 the spec is buggy, and the implementation followed it until
- * 4.3 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793).
- */
-#if defined(__i386__) || defined(__x86_64__)
-#if !G_GNUC_CHECK_VERSION(4, 4)
-#if defined __x86_64__
-#define smp_mb()    ({ asm volatile("mfence" ::: "memory"); (void)0; })
-#else
-#define smp_mb()    ({ asm volatile("lock; addl $0,0(%%esp) " ::: "memory"); (void)0; })
-#endif
-#endif
-#endif
-
-
 #ifdef __alpha__
 #define smp_read_barrier_depends()   asm volatile("mb":::"memory")
 #endif