From: "Ser, Simon" <simon.ser@intel.com> To: "guillaume.tucker@collabora.com" <guillaume.tucker@collabora.com> Cc: "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>, "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org> Subject: Re: [PATCH i-g-t v3 1/4] meson: add libatomic dependency Date: Tue, 18 Jun 2019 14:37:00 +0000 [thread overview] Message-ID: <3500e46eef3a29c9bb80da69231b85270964abcd.camel@intel.com> (raw) In-Reply-To: <e429449a-da1b-80d3-d07f-b17b5c348cbf@collabora.com> On Tue, 2019-06-18 at 14:59 +0100, Guillaume Tucker wrote: > On 18/06/2019 14:20, Ser, Simon wrote: > > On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote: > > > Add conditional dependency on libatomic in order to be able to use the > > > __atomic_* functions instead of the older __sync_* ones. The > > > libatomic library is only needed when there aren't any native support > > > on the current architecture, so a linker test is used for this > > > purpose. This enables atomic operations to be on a wider number of > > > architectures including MIPS. > > > > > > Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com> > > > --- > > > > > > Notes: > > > v2: add linker test for libatomic > > > v3: use null_dep > > > > > > meson.build | 14 ++++++++++++++ > > > 1 file changed, 14 insertions(+) > > > > > > diff --git a/meson.build b/meson.build > > > index 6268c58d3634..118ad667ffb5 100644 > > > --- a/meson.build > > > +++ b/meson.build > > > @@ -180,6 +180,20 @@ realtime = cc.find_library('rt') > > > dlsym = cc.find_library('dl') > > > zlib = cc.find_library('z') > > > > > > +if cc.links(''' > > > +#include <stdint.h> > > > +int main(void) { > > > + uint32_t x32 = 0; > > > + uint64_t x64 = 0; > > > + __atomic_load_n(&x32, __ATOMIC_SEQ_CST); > > > + __atomic_load_n(&x64, __ATOMIC_SEQ_CST); > > > > See my reply for v2. I've looked into this a little bit more and it > > looks like __atomic_* functions are a GCC implementation detail. OIn > > other words, the C11 standard [1] defines only atomic_* functions, and > > GCC implements them with __atomic_* builtins when the platform supports > > it, but other compilers might not expose those builtins and still > > support atomic_* functions without them. This also seems to be what [2] > > explains: > > > > > The first set of library functions are named __atomic_*. This set has > > > been “standardized” by GCC, and is described below. (See also GCC’s > > > documentation) > > > > (Notice the quotes around “standardized”, meaning they are a GCC > > extension) > > Quite, and while the stdatomic.h API is part of the C11 standard, > libatomic is part of GCC. So this test is to determine whether > linking against GCC's libatomic.so is needed for its __atomic_* > fallback implementation. > > It raises the question of what to do with other compilers, but > igt has other build errors with clang on mips at the moment. > With a quick search, it looks like its __atomic_* functions are > part of libclang.so for clang. I don't see anything in `readelf -s /usr/lib/libclang.so.8`. > Maybe this test should only be used when the compiler name is > gcc? In practice it does work with both gcc and clang though, as > they both use the same naming convention for atomic built-ins. Hmm. I'm still not quite sure I understand why checking with __atomic_* is preferred. - If the compiler has __atomic_* builtins: this won't link with libatomic - If the compiler doesn't have __atomic_* builtins: this will link with libatomic even if stdatomic.h works without it What we're really interested in is stdatomic.h support, not __atomic_*. So I still think checking for atomic_* is better than __atomic_*. Am I missing something? > Guillaume > > > [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf > > [2]: https://llvm.org/docs/Atomics.html > > > > > + return 0; > > > +}''', name : 'built-in atomics') > > > + libatomic = null_dep > > > +else > > > + libatomic = cc.find_library('atomic') > > > +endif > > > + > > > if cc.has_header('linux/kd.h') > > > config.set('HAVE_LINUX_KD_H', 1) > > > endif _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: "Ser, Simon" <simon.ser@intel.com> To: "guillaume.tucker@collabora.com" <guillaume.tucker@collabora.com> Cc: "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>, "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>, "Latvala, Petri" <petri.latvala@intel.com> Subject: Re: [igt-dev] [PATCH i-g-t v3 1/4] meson: add libatomic dependency Date: Tue, 18 Jun 2019 14:37:00 +0000 [thread overview] Message-ID: <3500e46eef3a29c9bb80da69231b85270964abcd.camel@intel.com> (raw) In-Reply-To: <e429449a-da1b-80d3-d07f-b17b5c348cbf@collabora.com> On Tue, 2019-06-18 at 14:59 +0100, Guillaume Tucker wrote: > On 18/06/2019 14:20, Ser, Simon wrote: > > On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote: > > > Add conditional dependency on libatomic in order to be able to use the > > > __atomic_* functions instead of the older __sync_* ones. The > > > libatomic library is only needed when there aren't any native support > > > on the current architecture, so a linker test is used for this > > > purpose. This enables atomic operations to be on a wider number of > > > architectures including MIPS. > > > > > > Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com> > > > --- > > > > > > Notes: > > > v2: add linker test for libatomic > > > v3: use null_dep > > > > > > meson.build | 14 ++++++++++++++ > > > 1 file changed, 14 insertions(+) > > > > > > diff --git a/meson.build b/meson.build > > > index 6268c58d3634..118ad667ffb5 100644 > > > --- a/meson.build > > > +++ b/meson.build > > > @@ -180,6 +180,20 @@ realtime = cc.find_library('rt') > > > dlsym = cc.find_library('dl') > > > zlib = cc.find_library('z') > > > > > > +if cc.links(''' > > > +#include <stdint.h> > > > +int main(void) { > > > + uint32_t x32 = 0; > > > + uint64_t x64 = 0; > > > + __atomic_load_n(&x32, __ATOMIC_SEQ_CST); > > > + __atomic_load_n(&x64, __ATOMIC_SEQ_CST); > > > > See my reply for v2. I've looked into this a little bit more and it > > looks like __atomic_* functions are a GCC implementation detail. OIn > > other words, the C11 standard [1] defines only atomic_* functions, and > > GCC implements them with __atomic_* builtins when the platform supports > > it, but other compilers might not expose those builtins and still > > support atomic_* functions without them. This also seems to be what [2] > > explains: > > > > > The first set of library functions are named __atomic_*. This set has > > > been “standardized” by GCC, and is described below. (See also GCC’s > > > documentation) > > > > (Notice the quotes around “standardized”, meaning they are a GCC > > extension) > > Quite, and while the stdatomic.h API is part of the C11 standard, > libatomic is part of GCC. So this test is to determine whether > linking against GCC's libatomic.so is needed for its __atomic_* > fallback implementation. > > It raises the question of what to do with other compilers, but > igt has other build errors with clang on mips at the moment. > With a quick search, it looks like its __atomic_* functions are > part of libclang.so for clang. I don't see anything in `readelf -s /usr/lib/libclang.so.8`. > Maybe this test should only be used when the compiler name is > gcc? In practice it does work with both gcc and clang though, as > they both use the same naming convention for atomic built-ins. Hmm. I'm still not quite sure I understand why checking with __atomic_* is preferred. - If the compiler has __atomic_* builtins: this won't link with libatomic - If the compiler doesn't have __atomic_* builtins: this will link with libatomic even if stdatomic.h works without it What we're really interested in is stdatomic.h support, not __atomic_*. So I still think checking for atomic_* is better than __atomic_*. Am I missing something? > Guillaume > > > [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf > > [2]: https://llvm.org/docs/Atomics.html > > > > > + return 0; > > > +}''', name : 'built-in atomics') > > > + libatomic = null_dep > > > +else > > > + libatomic = cc.find_library('atomic') > > > +endif > > > + > > > if cc.has_header('linux/kd.h') > > > config.set('HAVE_LINUX_KD_H', 1) > > > endif _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2019-06-18 14:37 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-18 12:27 [PATCH i-g-t v3 0/4] Use C11 atomics Guillaume Tucker 2019-06-18 12:27 ` [igt-dev] " Guillaume Tucker 2019-06-18 12:27 ` [PATCH i-g-t v3 1/4] meson: add libatomic dependency Guillaume Tucker 2019-06-18 12:27 ` [Intel-gfx] " Guillaume Tucker 2019-06-18 13:20 ` Ser, Simon 2019-06-18 13:20 ` [igt-dev] " Ser, Simon 2019-06-18 13:59 ` Guillaume Tucker 2019-06-18 13:59 ` [igt-dev] " Guillaume Tucker 2019-06-18 14:37 ` Ser, Simon [this message] 2019-06-18 14:37 ` Ser, Simon 2019-06-18 16:03 ` Guillaume Tucker 2019-06-18 16:03 ` [igt-dev] " Guillaume Tucker 2019-06-19 6:42 ` Ser, Simon 2019-06-19 6:42 ` [igt-dev] " Ser, Simon 2019-06-19 7:24 ` Guillaume Tucker 2019-06-19 7:24 ` [igt-dev] " Guillaume Tucker 2019-06-18 12:27 ` [PATCH i-g-t v3 2/4] gitlab-ci: add libatomic to docker images Guillaume Tucker 2019-06-18 12:27 ` [igt-dev] " Guillaume Tucker 2019-06-19 6:50 ` Ser, Simon 2019-06-19 6:50 ` [igt-dev] " Ser, Simon 2019-06-19 8:09 ` Guillaume Tucker 2019-06-19 8:09 ` [igt-dev] " Guillaume Tucker 2019-06-18 12:27 ` [PATCH i-g-t v3 3/4] i915/gem_create: use atomic_* instead of __sync_* Guillaume Tucker 2019-06-18 12:27 ` [igt-dev] " Guillaume Tucker 2019-06-18 12:27 ` [PATCH i-g-t v3 4/4] tests/sw_sync: " Guillaume Tucker 2019-06-18 12:27 ` [Intel-gfx] " Guillaume Tucker 2019-06-18 13:31 ` [igt-dev] ✗ Fi.CI.BAT: failure for Use C11 atomics (rev2) Patchwork 2019-06-19 6:52 ` Ser, Simon 2019-06-19 7:02 ` Saarinen, Jani 2019-06-19 7:32 ` Peres, Martin 2019-06-19 7:46 ` Guillaume Tucker 2019-06-19 8:05 ` [igt-dev] ✓ Fi.CI.BAT: success for Use C11 atomics (rev3) Patchwork 2019-06-19 21:21 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
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=3500e46eef3a29c9bb80da69231b85270964abcd.camel@intel.com \ --to=simon.ser@intel.com \ --cc=guillaume.tucker@collabora.com \ --cc=igt-dev@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ /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: linkBe 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.