[hwloc-devel] Create success (hwloc git 1.10.1-9-g2eeb2bb)

[MPI Team]

Creating nightly hwloc snapshot git tarball was a success.

Snapshot:   hwloc 1.10.1-9-g2eeb2bb
Start time: Fri Feb 20 21:05:52 EST 2015
End time:   Fri Feb 20 21:07:19 EST 2015

Your friendly daemon,
Cyrador

[hwloc-devel] Create success (hwloc git 1.9.1-33-gd8b8ea9)

[MPI Team]

Creating nightly hwloc snapshot git tarball was a success.

Snapshot:   hwloc 1.9.1-33-gd8b8ea9
Start time: Fri Feb 20 21:04:30 EST 2015
End time:   Fri Feb 20 21:05:52 EST 2015

Your friendly daemon,
Cyrador

[hwloc-devel] Create success (hwloc git 1.8.1-22-g084f1ed)

[MPI Team]

Creating nightly hwloc snapshot git tarball was a success.

Snapshot:   hwloc 1.8.1-22-g084f1ed
Start time: Fri Feb 20 21:02:59 EST 2015
End time:   Fri Feb 20 21:04:29 EST 2015

Your friendly daemon,
Cyrador

[hwloc-devel] Create success (hwloc git dev-437-g4a1869c)

[MPI Team]

Creating nightly hwloc snapshot git tarball was a success.

Snapshot:   hwloc dev-437-g4a1869c
Start time: Fri Feb 20 21:01:02 EST 2015
End time:   Fri Feb 20 21:02:49 EST 2015

Your friendly daemon,
Cyrador

Re: [OMPI devel] Fortran issue

[Larry Baker]

Good grins.  Thanks Paul.

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov



On 20 Feb 2015, at 11:49 AM, Paul Hargrove wrote:

> 
>INTEGER JEFF(3)
>DATA JEFF/4HMR. ,4HFORT,3HRAN/
> 
> If you can understand that, you should probably pretend you can't :-)
> 
> -Paul [who has actually used Computed GO TO and Arithmetic IF]
> 
> On Fri, Feb 20, 2015 at 11:28 AM, Larry Baker  wrote:
> Excellent, Mr. Fortran.  Thank you.
> 
> By the way, I meant to write Branch ON Low Bit Set/Clear.
> 
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
> 
> 
> 
> On 20 Feb 2015, at 11:22 AM, Jeff Squyres (jsquyres) wrote:
> 
>> On Feb 20, 2015, at 2:12 PM, Larry Baker  wrote:
>>> 
>>> Beware, this has/may not always be the case.  This is due to C's historical 
>>> confusion/misuse of integers as boolean data types.  On VAX hardware, the 
>>> low bit was the only significant part of a Fortran LOGICAL data type, owing 
>>> to the architectural support (Branch of Low Bit Set/Clear) for the low bit 
>>> in a status word meaning success/failure.  I doubt anyone uses VAXes and 
>>> MPI, so this is not likely to cause users problems.
>> 
>> Note that this comment was referring to two things:
>> 
>> 1. 0/1 array index issues
>> 2. .true./.false. issues
>> 
>> We actually check for the value of .true. in configure, and use that 
>> everywhere.  I believe this particular portion of the code simply looks for 
>> .false.==(C int)0, and .true. is anything else.  That was deemed good enough 
>> because this portion of the code is simply *checking* for true/false.  Where 
>> we *assign* true/false in the Fortran boolean sense, we use the value 
>> determined by configure.
>> 
>> -- 
>> Jeff Squyres
>> jsquy...@cisco.com
>> For corporate legal information go to: 
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2015/02/17012.php
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/02/17013.php
> 
> 
> 
> -- 
> Paul H. Hargrove  phhargr...@lbl.gov
> Computer Languages & Systems Software (CLaSS) Group
> Computer Science Department   Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/02/17014.php

Re: [OMPI devel] Fortran issue

[Paul Hargrove]

   INTEGER JEFF(3)
   DATA JEFF/4HMR. ,4HFORT,3HRAN/

If you can understand that, you should probably pretend you can't :-)

-Paul [who has actually used Computed GO TO and Arithmetic IF]

On Fri, Feb 20, 2015 at 11:28 AM, Larry Baker  wrote:

> Excellent, Mr. Fortran.  Thank you.
>
> By the way, I meant to write Branch ON Low Bit Set/Clear.
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
>
>
>
> On 20 Feb 2015, at 11:22 AM, Jeff Squyres (jsquyres) wrote:
>
> On Feb 20, 2015, at 2:12 PM, Larry Baker  wrote:
>
>
> Beware, this has/may not always be the case.  This is due to C's
> historical confusion/misuse of integers as boolean data types.  On VAX
> hardware, the low bit was the only significant part of a Fortran LOGICAL
> data type, owing to the architectural support (Branch of Low Bit Set/Clear)
> for the low bit in a status word meaning success/failure.  I doubt anyone
> uses VAXes and MPI, so this is not likely to cause users problems.
>
>
> Note that this comment was referring to two things:
>
> 1. 0/1 array index issues
> 2. .true./.false. issues
>
> We actually check for the value of .true. in configure, and use that
> everywhere.  I believe this particular portion of the code simply looks for
> .false.==(C int)0, and .true. is anything else.  That was deemed good
> enough because this portion of the code is simply *checking* for
> true/false.  Where we *assign* true/false in the Fortran boolean sense, we
> use the value determined by configure.
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/02/17012.php
>
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/02/17013.php
>



-- 
Paul H. Hargrove  phhargr...@lbl.gov
Computer Languages & Systems Software (CLaSS) Group
Computer Science Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] Fortran issue

[Jeff Squyres (jsquyres)]

On Feb 20, 2015, at 2:12 PM, Larry Baker  wrote:
> 
> Beware, this has/may not always be the case.  This is due to C's historical 
> confusion/misuse of integers as boolean data types.  On VAX hardware, the low 
> bit was the only significant part of a Fortran LOGICAL data type, owing to 
> the architectural support (Branch of Low Bit Set/Clear) for the low bit in a 
> status word meaning success/failure.  I doubt anyone uses VAXes and MPI, so 
> this is not likely to cause users problems.

Note that this comment was referring to two things:

1. 0/1 array index issues
2. .true./.false. issues

We actually check for the value of .true. in configure, and use that 
everywhere.  I believe this particular portion of the code simply looks for 
.false.==(C int)0, and .true. is anything else.  That was deemed good enough 
because this portion of the code is simply *checking* for true/false.  Where we 
*assign* true/false in the Fortran boolean sense, we use the value determined 
by configure.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] Fortran issue

[Larry Baker]

On 20 Feb 2015, at 3:09 AM, Gilles Gouaillardet wrote:

> George,
> 
> this is correctly handled in ompi_testany_f :
> 
> /* Increment index by one for fortran conventions.  Note that
>all Fortran compilers have FALSE==0; we just need to check
>for any nonzero value (because TRUE is not always 1) */
> 
> Cheers,
> 
> Gilles


Beware, this has/may not always be the case.  This is due to C's historical 
confusion/misuse of integers as boolean data types.  On VAX hardware, the low 
bit was the only significant part of a Fortran LOGICAL data type, owing to the 
architectural support (Branch of Low Bit Set/Clear) for the low bit in a status 
word meaning success/failure.  I doubt anyone uses VAXes and MPI, so this is 
not likely to cause users problems.

See http://h71000.www7.hp.com/doc/82final/6443/6443pro_026.html:

> 8.3 Logical Data Representations
> 
> Logical data can be one, two, four, or eight bytes in length.
> 
> The default size used for a LOGICAL data declaration without a kind parameter 
> (or size specifier) is LOGICAL (KIND=4) (same as LOGICAL*4), unless you do 
> one of the following:
> 
>   • Explicitly declare the length of a LOGICAL declaration by using a 
> kind parameter, such as LOGICAL (KIND=4). HP Fortran provides intrinsic 
> LOGICAL kinds of 1, 2, 4, and 8. Each LOGICAL kind number corresponds to 
> number of bytes used by that intrinsic representation. 
> You can also use a size specifier, such as LOGICAL*4, but be aware this is an 
> extension to the Fortran 90 standard.
> 
>   • Use the FORTRAN command /INTEGER_SIZE=nn qualifier to control the 
> size of default (without a kind parameter or size specifier) LOGICAL and 
> INTEGER declarations (see Section 2.3.26).
> To improve performance, avoid using 2-byte or 1-byte logical declarations 
> (see Chapter 5).
> 
> Intrinsic LOGICAL*1 or LOGICAL (KIND=1) values are stored in a single byte.
> 
> Logical (intrinsic) values can also be stored in the following sizes of 
> contiguous bytes starting on an arbitrary byte boundary:
> 
>   • Two bytes (LOGICAL (KIND=2) or LOGICAL*2)
>   • Four bytes (LOGICAL (KIND=4) or LOGICAL*4)
>   • Eight bytes (LOGICAL (KIND=8) or LOGICAL*8)
> 
> The low-order bit determines whether the logical value is true or false. 
> Logical variables can also be interpreted as integer data (an extension to 
> the Fortran 90 standard). For example, in addition to having logical values 
> .TRUE. and .FALSE., LOGICAL*1 data can also have values in the range --128 to 
> 127.
> 
> LOGICAL*1, LOGICAL*2, LOGICAL*4, and LOGICAL*8 data representations appear in 
> Figure 8-5.

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov

Re: [OMPI devel] [OMPI commits] Git: open-mpi/ompi-tests branch master updated. dev-62-gff3dee2

[Jeff Squyres (jsquyres)]

Yeah, I did.  I saw it as I typed it, but it doesn't really matter -- as long 
as the section name doesn't begin with "MPI Install", it'll get skpied.  And 
it'll get skipped, too.  ;-)


> On Feb 20, 2015, at 10:59 AM, Dave Goodell (dgoodell)  
> wrote:
> 
> On Feb 20, 2015, at 6:46 AM, git...@crest.iu.edu wrote:
> 
>> This is an automated email from the git hooks/post-receive script. It was
>> generated because a ref change was pushed to the repository containing
>> the project "open-mpi/ompi-tests".
>> 
>> The branch, master has been updated
>>  via  ff3dee227f572c21fc6d35ed78cb359578a2661e (commit)
>> from  3ca024f4025d0582c5365e960af5b857a2cf8ca4 (commit)
>> 
>> Those revisions listed above that are new to this repository have
>> not appeared on any other notification email; so we list those
>> revisions in full, below.
>> 
>> - Log -
>> https://github.com/open-mpi/ompi-tests/commit/ff3dee227f572c21fc6d35ed78cb359578a2661e
>> 
>> commit ff3dee227f572c21fc6d35ed78cb359578a2661e
>> Author: Jeff Squyres 
>> Date:   Fri Feb 20 04:46:12 2015 -0800
>> 
>>   Cisco: stop testing the intel compiler
>> 
>> diff --git a/cisco/mtt/community/cisco-ompi-core-testing-master.ini 
>> b/cisco/mtt/community/cisco-ompi-core-testing-master.ini
>> index 942c152..465890f 100644
>> --- a/cisco/mtt/community/cisco-ompi-core-testing-master.ini
>> +++ b/cisco/mtt/community/cisco-ompi-core-testing-master.ini
>> @@ -105,7 +105,9 @@ ompi_configure_arguments = CC=clang CXX=clang++ 
>> --disable-mpi-fortran "CFLAGS=-g
>> 
>> #--
>> 
>> -[MPI install: Intel-12.1]
>> +# Intel compiler borked their 2015 update 2, which broke all my other
>> +# intel compiler installs. :-( :-( :-(
>> +[SKPI MPI install: Intel-12.1]
> 
> I think you mean "SKIP" :-)
> 
> -Dave
> 


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] [OMPI commits] Git: open-mpi/ompi-tests branch master updated. dev-62-gff3dee2

[Dave Goodell (dgoodell)]

On Feb 20, 2015, at 6:46 AM, git...@crest.iu.edu wrote:

> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref change was pushed to the repository containing
> the project "open-mpi/ompi-tests".
> 
> The branch, master has been updated
>   via  ff3dee227f572c21fc6d35ed78cb359578a2661e (commit)
>  from  3ca024f4025d0582c5365e960af5b857a2cf8ca4 (commit)
> 
> Those revisions listed above that are new to this repository have
> not appeared on any other notification email; so we list those
> revisions in full, below.
> 
> - Log -
> https://github.com/open-mpi/ompi-tests/commit/ff3dee227f572c21fc6d35ed78cb359578a2661e
> 
> commit ff3dee227f572c21fc6d35ed78cb359578a2661e
> Author: Jeff Squyres 
> Date:   Fri Feb 20 04:46:12 2015 -0800
> 
>Cisco: stop testing the intel compiler
> 
> diff --git a/cisco/mtt/community/cisco-ompi-core-testing-master.ini 
> b/cisco/mtt/community/cisco-ompi-core-testing-master.ini
> index 942c152..465890f 100644
> --- a/cisco/mtt/community/cisco-ompi-core-testing-master.ini
> +++ b/cisco/mtt/community/cisco-ompi-core-testing-master.ini
> @@ -105,7 +105,9 @@ ompi_configure_arguments = CC=clang CXX=clang++ 
> --disable-mpi-fortran "CFLAGS=-g
> 
> #--
> 
> -[MPI install: Intel-12.1]
> +# Intel compiler borked their 2015 update 2, which broke all my other
> +# intel compiler installs. :-( :-( :-(
> +[SKPI MPI install: Intel-12.1]

I think you mean "SKIP" :-)

-Dave

Re: [OMPI devel] Fortran issue

[Jeff Squyres (jsquyres)]

On Feb 20, 2015, at 10:01 AM, George Bosilca  wrote:
> 
> Great. Using grep I couldn't find how this is handled anywhere in the source 
> directory. But it seems to me that the Fortran layer is now way more 
> complicated than I initially thought.

Fortran is your friend.
(repeat until you believe it)

FWIW, that increment has been there since the very beginning.  So this 
particular aspect is nothing new.

But there are other aspects of the Fortran layer that are more complicated than 
I wish they were.  Honestly, if I could dedicate a week, I would love to re-do 
the Fortran layer from scratch and generate (almost) all the Fortran code based 
on the results of compiler tests from configure.  I.e., we already have a fixed 
set of the Fortran API prototypes; we already generate all the relevant Fortran 
header files from it.  It would be great to generate (almost) all the relevant 
Fortran function definitions from it, too.  That would eliminate a LOT of the 
complexity in our Fortran bindings implementation.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] Fortran issue

[George Bosilca]

Great. Using grep I couldn't find how this is handled anywhere in the
source directory. But it seems to me that the Fortran layer is now way more
complicated than I initially thought.

  George.


On Fri, Feb 20, 2015 at 8:27 AM, Jeff Squyres (jsquyres)  wrote:

> Gilles is correct.  The same kind of increment happens in all the
> test/wait Fortran code that returns indexes.
>
> "Mr. Fortran"?  Ouch.  :-)
>
>
> > On Feb 20, 2015, at 6:09 AM, Gilles Gouaillardet <
> gilles.gouaillar...@iferc.org> wrote:
> >
> > George,
> >
> > this is correctly handled in ompi_testany_f :
> >
> > /* Increment index by one for fortran conventions.  Note that
> >all Fortran compilers have FALSE==0; we just need to check
> >for any nonzero value (because TRUE is not always 1) */
> >
> > Cheers,
> >
> > Gilles
> >
> > On 2015/02/20 1:15, George Bosilca wrote:
> >> While looking the MPI_Testany issue, I came across a very unsettling
> >> sentence in the MPI standard (3.0 page 58 line 36).
> >>
> >>
> >>> The array is indexed from zero in C, and from one in Fortran.
> >>>
> >> This sentence seems to indicate that the index returned by the TestAny
> and
> >> TestSome (as well as the corresponding Wait functions) should be indexed
> >> starting from 1 in Fortran, but from 0 in C. Our C code returns all
> indexes
> >> starting from 0 (C), but I failed to find where we handle this case in
> >> Fortran? Or maybe I am interpreting too much the MPI standard?
> >>
> >>   George.
> >>
> >>
> >>
> >>
> >> ___
> >> devel mailing list
> >>
> >> de...@open-mpi.org
> >>
> >> Subscription:
> >> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >>
> >> Link to this post:
> >> http://www.open-mpi.org/community/lists/devel/2015/02/16994.php
> >
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/02/17005.php
>
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/02/17006.php
>

Re: [OMPI devel] Fortran issue

[Jeff Squyres (jsquyres)]

Gilles is correct.  The same kind of increment happens in all the test/wait 
Fortran code that returns indexes.

"Mr. Fortran"?  Ouch.  :-)


> On Feb 20, 2015, at 6:09 AM, Gilles Gouaillardet 
>  wrote:
> 
> George,
> 
> this is correctly handled in ompi_testany_f :
> 
> /* Increment index by one for fortran conventions.  Note that
>all Fortran compilers have FALSE==0; we just need to check
>for any nonzero value (because TRUE is not always 1) */
> 
> Cheers,
> 
> Gilles
> 
> On 2015/02/20 1:15, George Bosilca wrote:
>> While looking the MPI_Testany issue, I came across a very unsettling
>> sentence in the MPI standard (3.0 page 58 line 36).
>> 
>> 
>>> The array is indexed from zero in C, and from one in Fortran.
>>> 
>> This sentence seems to indicate that the index returned by the TestAny and
>> TestSome (as well as the corresponding Wait functions) should be indexed
>> starting from 1 in Fortran, but from 0 in C. Our C code returns all indexes
>> starting from 0 (C), but I failed to find where we handle this case in
>> Fortran? Or maybe I am interpreting too much the MPI standard?
>> 
>>   George.
>> 
>> 
>> 
>> 
>> ___
>> devel mailing list
>> 
>> de...@open-mpi.org
>> 
>> Subscription: 
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> 
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2015/02/16994.php
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/02/17005.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] Fortran issue

[Gilles Gouaillardet]

George,

this is correctly handled in ompi_testany_f :

/* Increment index by one for fortran conventions.  Note that
   all Fortran compilers have FALSE==0; we just need to check
   for any nonzero value (because TRUE is not always 1) */

Cheers,

Gilles

On 2015/02/20 1:15, George Bosilca wrote:
> While looking the MPI_Testany issue, I came across a very unsettling
> sentence in the MPI standard (3.0 page 58 line 36).
>
>> The array is indexed from zero in C, and from one in Fortran.
> This sentence seems to indicate that the index returned by the TestAny and
> TestSome (as well as the corresponding Wait functions) should be indexed
> starting from 1 in Fortran, but from 0 in C. Our C code returns all indexes
> starting from 0 (C), but I failed to find where we handle this case in
> Fortran? Or maybe I am interpreting too much the MPI standard?
>
>   George.
>
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/02/16994.php