this is a followup on these issues

1) clang 5.0 issue

it seems clang 5.0 on trusty is busted.

The simple program below fails to compile

#include  <stdatomic.h>
#include  <stdint.h>

void  conftest() {
    _Atomicuint32_t  a;
    uint32_t  b;
    atomic_fetch_xor_explicit(&a, b, memory_order_relaxed);

with clang 5.0

|$ clang-5.0 -c conftest.c conftest.c:7:5: error: address argument to bitwise atomic operation must be a pointer to integer ('_Atomic(uint32_t) *' invalid) atomic_fetch_xor_explicit(&a, b, memory_order_relaxed); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/bin/../lib/gcc/i686-linux-gnu/4.9/include/stdatomic.h:224:6: note: expanded from macro 'atomic_fetch_xor_explicit' __atomic_fetch_xor ((PTR), (VAL), (MO)) ^ ~~~~~ 1 error generated. |

fwiw, clang 6.0 & 7 work just fine.

I added this test to Open MPI configury in
so C11 atomics are disabled if this test fails.

2) make distcheck issue.
This issue has always been there, but popped up when we choose to default to external hwloc.

The following makefile evidences what is going wrong


    @env | grep ^CPPFLAGS || echo no CPPFLAGS in the environment

$ make
no CPPFLAGS in the environment

but if we put already have CPPFLAGS in the environment, the environment is updated to use the value in the Makefile

$ CPPFLAGS=-Dfoo make

To me this is really counter intuitive, and could be a bug.
Anyway, I can see two possible options to workaround this feature/bug

- do not `export CPPFLAGS=...` but configure CPPFLAGS=... instead
- keep export CPPFLAGS=... *and* export DISTCHECK_CONFIGURE_FLAGS='CPPFLAGS=...' ...

Bottom line, this is not an Open MPI bug/regression but the root cause is how we use travis.



On 1/9/2019 11:45 AM, Gilles Gouaillardet wrote:
I do not know how/why travis was enabled.

That being said, the errors look legit to me, and there are two

1) with clang 5.0

  CC       opal_convertor_raw.lo
In file included from opal_convertor_raw.c:21:
In file included from ../../opal/datatype/opal_convertor_internal.h:21:
In file included from ../../opal/datatype/opal_convertor.h:35:
In file included from ../../opal/datatype/opal_datatype.h:43:
In file included from ../../opal/class/opal_object.h:126:
In file included from ../../opal/threads/thread_usage.h:30:
In file included from ../../opal/include/opal/sys/atomic.h:63:
../../opal/include/opal/sys/atomic_stdc.h:109:1: error: address argument to atomic operation must be a pointer to integer or pointer ('opal_atomic_int32_t *' (aka '_Atomic(int32_t) *') invalid)
../../opal/include/opal/sys/atomic_stdc.h:101:16: note: expanded from macro 'OPAL_ATOMIC_STDC_DEFINE_FETCH_OP'         return atomic_fetch_ ## op ## _explicit (addr, value, memory_order_relaxed); \
<scratch space>:33:1: note: expanded from here

(there are many kind of errors like this one, could be a clang 5 issue or something we failed to detect with this compiler)

2) with "make distcheck"

Here is how to reproduce the issue

export CPPFLAGS=-I$HOME/bogus/include

./configure --prefix=$HOME/bogus


make distcheck

the first configure reports

== Modular Component Architecture (MCA) setup
============================================================================ checking for subdir args...  '--prefix=/home/gilles/bogus' 'CPPFLAGS=-I/home/gilles/bogus/include'

but the second one (invoked indirectly by make distcheck) reports

== Modular Component Architecture (MCA) setup
============================================================================ checking for subdir args... '--prefix=/home/gilles/src/ompi-master/openmpi-gitclone/_inst' 'CPPFLAGS=-I. -I./orte/include -I/home/gilles/src/ompi-master/opal/mca/event/libevent2022/libevent -I/home/gilles/src/ompi-master/opal/mca/event/libevent2022/libevent/include -I/home/gilles/src/ompi-master/opal/mca/hwloc/hwloc201/hwloc/include -I/home/gilles/bogus/include  -I/usr/local/include -I/usr/local/include'

and we endup using the include files from the embedded hwloc of the first 'make' and linking with the system hwloc, which fails (no mangling and possibly version inconsistency)

I will run a bisect to search when this started.



On 1/9/2019 7:57 AM, Jeff Squyres (jsquyres) via devel wrote:
Did someone enable Travis CI on GitHub:open-mpi/ompi?

I thought we had specifically disabled Travis after we kept running into problems with it...?

I ask because it's failing on some PRs for reasons that seem to have nothing to do with the PR.  I don't know if our Travis setup has bit rotted, if there's a genuine problem, or if Travis is just acting wonky...

devel mailing list

Reply via email to