Folks,
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
https://github.com/open-mpi/ompi/pull/6272
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
CPPFLAGS = -Dbar
all:
@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
CPPFLAGS=-Dbar
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.
Cheers,
Gilles
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_ATOMIC_STDC_DEFINE_FETCH_OP(add, 32, int32_t, +)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../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
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.
Cheers,
Gilles
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
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel
