We need and arch directory that ./configure can pull from for those things that are not platform specific but are core core specific. ./configure then needs different rules to accommodate the above cases, presumable the different rules can be pulled depending on something common like $ARCH similar to the linux compile.
On 23 December 2014 at 10:28, Mike Holmes <[email protected]> wrote: > how will this work, Octeon does not care about __atomic_fetch_add(&v, > 1, __ATOMIC_RELAXED); and yet you will fail configure I assume > > static inline uint32_t odp_atomic_fetch_inc_u32(odp_atomic_u32_t *atom) > { > #if defined __OCTEON__ > >-------uint32_t ret; > >-------__asm__ __volatile__ ("syncws"); > >-------__asm__ __volatile__ ("lai %0,(%2)" : "=r" (ret), "+m" (atom) : > >------->------->------- "r" (atom)); > >-------return ret; > #else > >-------return __atomic_fetch_add(&atom->v, 1, __ATOMIC_RELAXED); > #endif > } > > > On 23 December 2014 at 10:26, Ola Liljedahl <[email protected]> > wrote: > >> On 23 December 2014 at 16:16, Maxim Uvarov <[email protected]> >> wrote: >> > On 12/23/2014 04:26 PM, Ola Liljedahl wrote: >> >> >> >> On 23 December 2014 at 10:13, Maxim Uvarov <[email protected]> >> >> wrote: >> >>> >> >>> Odp atomic operations based on compiler build-ins. Make >> >>> sure that compiler supports such operation at configure >> >>> stage. >> >>> >> >>> Signed-off-by: Maxim Uvarov <[email protected]> >> >>> --- >> >>> v3: make atomic checks platfrom specific >> >>> >> >>> configure.ac | 4 +++- >> >>> platform/linux-generic/m4/configure.m4 | 18 ++++++++++++++++++ >> >>> 2 files changed, 21 insertions(+), 1 deletion(-) >> >>> create mode 100644 platform/linux-generic/m4/configure.m4 >> >>> >> >>> diff --git a/configure.ac b/configure.ac >> >>> index 377e8be..f55beca 100644 >> >>> --- a/configure.ac >> >>> +++ b/configure.ac >> >>> @@ -47,7 +47,9 @@ AC_ARG_WITH([platform], >> >>> [AS_HELP_STRING([--with-platform=prefix], >> >>> [Select platform to be used, default linux-generic])], >> >>> [], >> >>> - [with_platform=linux-generic]) >> >>> + [with_platform=linux-generic >> >>> + m4_include([./platform/linux-generic/m4/configure.m4]) >> >>> + ]) >> >>> >> >>> AC_SUBST([with_platform]) >> >>> >> >>> diff --git a/platform/linux-generic/m4/configure.m4 >> >>> b/platform/linux-generic/m4/configure.m4 >> >>> new file mode 100644 >> >>> index 0000000..bfb1fb0 >> >>> --- /dev/null >> >>> +++ b/platform/linux-generic/m4/configure.m4 >> >>> @@ -0,0 +1,18 @@ >> >>> +AC_MSG_CHECKING(for GCC atomic builtins) >> >>> +AC_LINK_IFELSE( >> >>> + [AC_LANG_SOURCE( >> >>> + [[#include <stdint.h> >> >>> + int main() { >> >>> + uint32_t v = 1; >> You don't need to use a uint32_t, a plain "int" should suffice. Thus >> no need to include <stdint.h> either which should be more robust. >> >> >>> + __atomic_fetch_add(&v, 1, __ATOMIC_RELAXED); >> >>> + __atomic_fetch_sub(&v, 1, __ATOMIC_RELAXED); >> >>> + __atomic_store_n(&v, 1, __ATOMIC_RELAXED); >> >>> + __atomic_load_n(&v, __ATOMIC_RELAXED); >> >>> + return 0; >> >>> + } >> >>> + ]])], >> >>> + AC_MSG_RESULT(yes), >> >>> + AC_MSG_RESULT(no) >> >>> + echo "Atomic operation are not supported by your compiller." >> "compiller" speling erorr. >> >> I think the message should be more detailed. >> echo "GCC-style __atomic builtins not supported by the compiler" >> >> >> >>> + echo "Use newer version. For gcc > 4.7.3" >> >> >> >> Why >4.7.3? Minor releases do not introduce major new features. >> >> __atomic support was introduced on GCC 4.7.0. >> > >> > I have ubuntu 12.04 and there is 4.7.3. And it definatelly works there. >> So I >> > just set tested value. >> > I'm ok to change it to 4.7.0. >> Good. >> >> > >> > Maxim. >> > >> >> >> >>> + exit -1) >> >>> -- >> >>> 1.8.5.1.163.gd7aced9 >> >>> >> >>> >> >>> _______________________________________________ >> >>> lng-odp mailing list >> >>> [email protected] >> >>> http://lists.linaro.org/mailman/listinfo/lng-odp >> > >> > >> >> _______________________________________________ >> lng-odp mailing list >> [email protected] >> http://lists.linaro.org/mailman/listinfo/lng-odp >> > > > > -- > *Mike Holmes* > Linaro Sr Technical Manager > LNG - ODP > -- *Mike Holmes* Linaro Sr Technical Manager LNG - ODP
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
