Re: [OMPI devel] Did someone enable Travis?

2019-01-15 Thread Gilles Gouaillardet

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  
#include  

void  conftest() {
_Atomicuint32_t  a;
uint32_t  b;
atomic_fetch_xor_explicit(, 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(, 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); \

^~~~
: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 

Re: [OMPI devel] Did someone enable Travis?

2019-01-08 Thread Gilles Gouaillardet

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); \

^~~~
: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

Re: [OMPI devel] Did someone enable Travis?

2019-01-08 Thread Jeff Squyres (jsquyres) via devel
It looks like Travis was enabled within the last day or so -- 
https://travis-ci.org/open-mpi/ompi/pull_requests shows 3 Travis builds on PRs, 
all submitted within the last 24 hours.  The last PR build before that was 2 
years ago.

I've taken the liberty of re-disabling Travis.

Does anyone know how it got re-enabled?  I.e., was it intentional / we should 
turn it back on / fix it?


> On Jan 8, 2019, at 5:57 PM, Jeff Squyres (jsquyres)  
> 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...
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> 


-- 
Jeff Squyres
jsquy...@cisco.com

___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel


[OMPI devel] Did someone enable Travis?

2019-01-08 Thread Jeff Squyres (jsquyres) via devel
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...

-- 
Jeff Squyres
jsquy...@cisco.com

___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel