Re: [OMPI devel] RFC: use ISO C99 style struct initialization
The tarball got mucked up last night due to a minor ROMIO file permission
problem; let's see what happens tonight.
On Jan 19, 2011, at 8:36 PM, Terry Dontje wrote:
> Hopefully we'll find out tomorrow but I think I vaguely remember an issue
> with the Studio compilers and this type of initialization style.
>
> --td
>
> On 01/19/2011 05:22 PM, Nathan Hjelm wrote:
>> Done. I added the module orte/mca/debugger/dummy and I will remove it
>> tomorrow.
>>
>> -Nathan
>> HPC-3, LANL
>>
>> On Wed, 19 Jan 2011, Jeff Squyres wrote:
>>
>>> +1 on Ralph and George's comments.
>>>
>>> Want to make a dummy component somewhere that uses this kind of
>>> initialization and see what happens? Put a test for the C99 initialization
>>> style in configure.m4 to see if it works or not; MTT will then check this
>>> for all the compilers that we care about.
>>>
>>>
>>> On Jan 19, 2011, at 3:58 PM, Ralph Castain wrote:
>>>
I believe the majority of structs used in OMPI are actually declared to be
opal objects of some flavor, so I'm not sure how much this will actually
accomplish. Other than that, I have no real objection - either way works
fine for me.
On Jan 19, 2011, at 12:29 PM, George Bosilca wrote:
> I'm with you on that. Let's create a fake module using the ISO C99 naming
> scheme, and leave it to MTT to figure out where is breaks!
>
> george.
>
> On Jan 19, 2011, at 14:23 , Nathan Hjelm wrote:
>
>> I don't know if this has been discussed before or if this will break
>> Windows (or some obscure platform) support but I would like to start
>> using the ISO C99 style for struct initialization (see section 6.7.8,
>> example 10 in
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf).
>> Using this style would make mca code much easier to read. Any thoughts?
>> Would this break something?
>>
>> Example:
>> struct module_foo {
>> char *bar;
>> int baz;
>> };
>>
>> struct foo foobar = {
>> .bar = "foobar",
>> .baz = 1
>> };
>>
>> -Nathan
>> HPC-3, LANL
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>
>>>
>>> --
>>> 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
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> --
>
> Terry D. Dontje | Principal Software Engineer
> Developer Tools Engineering | +1.781.442.2631
> Oracle - Performance Technologies
> 95 Network Drive, Burlington, MA 01803
> Email terry.don...@oracle.com
>
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] Building Open MPI components outside of the sourcetree
On Jan 19, 2011, at 19:39 , Jeff Squyres (jsquyres) wrote: > I'd rather not setup another SVN repo. Where should it go in the current OMPI > SVN? contrib? george. > > Sent from my PDA. No type good. > > On Jan 19, 2011, at 5:01 PM, "George Bosilca" wrote: > >> >> On Jan 19, 2011, at 16:44 , Jeff Squyres wrote: >> >>> Where should it be on the main web site? >> >> The Documentation section look like a good place to me. >> >>> It needs to be in a repo somewhere; it may change over time. >> >> The source code can be hosted at Indiana in the same way ompi-tests and >> ompi-docs are hosted. However, I don't expect this code to drastically >> change every other day, so providing a tar on a webpage should be good >> enough. To be more precise on this point, as we only allow big modification >> of the build system between major releases I expect to only maintain 3 >> template (stable, unstable and trunk). >> >> george. >> >>> >>> >>> On Jan 19, 2011, at 4:38 PM, George Bosilca wrote: >>> This stuff should be directly on the main Open MPI website. Not as a link to bitbucket, but as a webpage and 3 tars. george. On Jan 19, 2011, at 15:43 , Jeff Squyres wrote: > Over the years, a few parties have wanted to be able to build Open MPI > components outside of the official source tree (e.g., they are developing > their own components outside of OMPI's SVN). We've typically said "use > --with-devel-headers", but a) never really provided a full example of how > to do this, and b) never acknowledged that using --with-devel-headers is > somewhat of a pain. > > That ends now. :-) > > I am publishing a bitbucket repo of three example "tcp2" BTL components. > They are almost exact copies of the real TCP BTL component, but have had > their configury updated to enable them to be built outside of the Open > MPI source tree: > > 1. A component for the v1.4 Open MPI tree > 2. A component for the v1.5/v1.6 Open MPI tree > 3. A component for the trunk/v1.7 (as of r24265) Open MPI tree > > Each of these example components support the --with-devel-headers method > as well as a new method: --with-openmpi-source=DIR (i.e., where you > specify the corresponding Open MPI source directory, and the component > builds against that). > > There are three different components because the configury between each > of them are a bit different. Look at the configure.ac in the version > that you care about to see examples of how to get the relevant CPPFLAGS / > CFLAGS that you need to build your component. > > Here's the bitbucket repo: > > https://bitbucket.org/jsquyres/build-ompi-components-outside-of-source-tree > > There's a top-level README.txt file in the repo that explains a bit more. > > Enjoy! > > -- > 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 > http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> >>> >>> -- >>> 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 >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> >> ___ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] Building Open MPI components outside of the sourcetree
This may be a good candidate for: svn-root/tmp-public/ On Jan 20, 2011, at 12:42 PM, George Bosilca wrote: > > On Jan 19, 2011, at 19:39 , Jeff Squyres (jsquyres) wrote: > >> I'd rather not setup another SVN repo. Where should it go in the current >> OMPI SVN? > > contrib? > > george. > >> >> Sent from my PDA. No type good. >> >> On Jan 19, 2011, at 5:01 PM, "George Bosilca" wrote: >> >>> >>> On Jan 19, 2011, at 16:44 , Jeff Squyres wrote: >>> Where should it be on the main web site? >>> >>> The Documentation section look like a good place to me. >>> It needs to be in a repo somewhere; it may change over time. >>> >>> The source code can be hosted at Indiana in the same way ompi-tests and >>> ompi-docs are hosted. However, I don't expect this code to drastically >>> change every other day, so providing a tar on a webpage should be good >>> enough. To be more precise on this point, as we only allow big modification >>> of the build system between major releases I expect to only maintain 3 >>> template (stable, unstable and trunk). >>> >>> george. >>> On Jan 19, 2011, at 4:38 PM, George Bosilca wrote: > This stuff should be directly on the main Open MPI website. Not as a link > to bitbucket, but as a webpage and 3 tars. > > george. > > On Jan 19, 2011, at 15:43 , Jeff Squyres wrote: > >> Over the years, a few parties have wanted to be able to build Open MPI >> components outside of the official source tree (e.g., they are >> developing their own components outside of OMPI's SVN). We've typically >> said "use --with-devel-headers", but a) never really provided a full >> example of how to do this, and b) never acknowledged that using >> --with-devel-headers is somewhat of a pain. >> >> That ends now. :-) >> >> I am publishing a bitbucket repo of three example "tcp2" BTL components. >> They are almost exact copies of the real TCP BTL component, but have >> had their configury updated to enable them to be built outside of the >> Open MPI source tree: >> >> 1. A component for the v1.4 Open MPI tree >> 2. A component for the v1.5/v1.6 Open MPI tree >> 3. A component for the trunk/v1.7 (as of r24265) Open MPI tree >> >> Each of these example components support the --with-devel-headers method >> as well as a new method: --with-openmpi-source=DIR (i.e., where you >> specify the corresponding Open MPI source directory, and the component >> builds against that). >> >> There are three different components because the configury between each >> of them are a bit different. Look at the configure.ac in the version >> that you care about to see examples of how to get the relevant CPPFLAGS >> / CFLAGS that you need to build your component. >> >> Here's the bitbucket repo: >> >> https://bitbucket.org/jsquyres/build-ompi-components-outside-of-source-tree >> >> There's a top-level README.txt file in the repo that explains a bit more. >> >> Enjoy! >> >> -- >> 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 >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- 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 http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> >>> >>> ___ >>> devel mailing list >>> de...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> ___ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey
Re: [OMPI devel] Building Open MPI components outside of the sourcetree
Hmm. I'm not sure I like either suggestion. :-\ 1. contrib: the problem with this is that there are 3 modules in here: trunk, v1.4, and v1.5. Should I put this in the contrib on each branch? Hmm. But then again, it won't be distributed as part of Open MPI, so technically it wouldn't violate the "no new features" rule for v1.4. Hmm. 2. /tmp-public: the "tmp" in the name has always implied to me that what was there was supposed to be temporary. It hasn't really worked out that way (people have left really old kruft in there), but still -- it "feels" wrong to put them in a "tmp" space. 3. ompi/mca/btl/tcp2 (on each branch): this doesn't feel right, either, because the whole point is that these components are supposed to be *outside* the main OMPI source tree. 4. /vendor: this has possibilities, but /vendor really is intended for the SVN 3rd party import mechanism. 5. /some-other-top-level-directory: also has possibilities, but we already have a good number of TLDs. Should I create another one? - the usual SVN trunk, tags, branches - vendor - tmp (private) - tmp-public I wrestled with these ideas yesterday before giving up and saying, "heck with it -- I'll just put it in a bitbucket." If the community wants this stuff at www.open-mpi.org, #1 probably has the best potential, IMNSHO. Thoughts? On Jan 20, 2011, at 12:56 PM, Joshua Hursey wrote: > This may be a good candidate for: svn-root/tmp-public/ > > On Jan 20, 2011, at 12:42 PM, George Bosilca wrote: > >> >> On Jan 19, 2011, at 19:39 , Jeff Squyres (jsquyres) wrote: >> >>> I'd rather not setup another SVN repo. Where should it go in the current >>> OMPI SVN? >> >> contrib? >> >> george. >> >>> >>> Sent from my PDA. No type good. >>> >>> On Jan 19, 2011, at 5:01 PM, "George Bosilca" wrote: >>> On Jan 19, 2011, at 16:44 , Jeff Squyres wrote: > Where should it be on the main web site? The Documentation section look like a good place to me. > It needs to be in a repo somewhere; it may change over time. The source code can be hosted at Indiana in the same way ompi-tests and ompi-docs are hosted. However, I don't expect this code to drastically change every other day, so providing a tar on a webpage should be good enough. To be more precise on this point, as we only allow big modification of the build system between major releases I expect to only maintain 3 template (stable, unstable and trunk). george. > > > On Jan 19, 2011, at 4:38 PM, George Bosilca wrote: > >> This stuff should be directly on the main Open MPI website. Not as a >> link to bitbucket, but as a webpage and 3 tars. >> >> george. >> >> On Jan 19, 2011, at 15:43 , Jeff Squyres wrote: >> >>> Over the years, a few parties have wanted to be able to build Open MPI >>> components outside of the official source tree (e.g., they are >>> developing their own components outside of OMPI's SVN). We've >>> typically said "use --with-devel-headers", but a) never really provided >>> a full example of how to do this, and b) never acknowledged that using >>> --with-devel-headers is somewhat of a pain. >>> >>> That ends now. :-) >>> >>> I am publishing a bitbucket repo of three example "tcp2" BTL >>> components. They are almost exact copies of the real TCP BTL >>> component, but have had their configury updated to enable them to be >>> built outside of the Open MPI source tree: >>> >>> 1. A component for the v1.4 Open MPI tree >>> 2. A component for the v1.5/v1.6 Open MPI tree >>> 3. A component for the trunk/v1.7 (as of r24265) Open MPI tree >>> >>> Each of these example components support the --with-devel-headers >>> method as well as a new method: --with-openmpi-source=DIR (i.e., where >>> you specify the corresponding Open MPI source directory, and the >>> component builds against that). >>> >>> There are three different components because the configury between each >>> of them are a bit different. Look at the configure.ac in the version >>> that you care about to see examples of how to get the relevant CPPFLAGS >>> / CFLAGS that you need to build your component. >>> >>> Here's the bitbucket repo: >>> >>> https://bitbucket.org/jsquyres/build-ompi-components-outside-of-source-tree >>> >>> There's a top-level README.txt file in the repo that explains a bit >>> more. >>> >>> Enjoy! >>> >>> -- >>> 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 >>> http://www.open-mpi.org/mailman/listinfo.cgi/deve
Re: [OMPI devel] RFC: use ISO C99 style struct initialization
Even before getting into the Oracle compiler, a fully compliant C99 compiler
such as gcc 4.2.1 complains a lot about the new code. Here is what I get:
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:25: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:28: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:29: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:30: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:31: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:33: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:34: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:35: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:37: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:39: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c: In function
'component_open':
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:45: warning:
unused variable 'c'
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:67: warning: ISO C90
forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:68: warning: ISO C90
forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:69: warning: ISO C90
forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:70: warning: ISO C90
forbids specifying subobject to initialize
george.
On Jan 19, 2011, at 20:36 , Terry Dontje wrote:
> Hopefully we'll find out tomorrow but I think I vaguely remember an issue
> with the Studio compilers and this type of initialization style.
>
> --td
>
> On 01/19/2011 05:22 PM, Nathan Hjelm wrote:
>> Done. I added the module orte/mca/debugger/dummy and I will remove it
>> tomorrow.
>>
>> -Nathan
>> HPC-3, LANL
>>
>> On Wed, 19 Jan 2011, Jeff Squyres wrote:
>>
>>> +1 on Ralph and George's comments.
>>>
>>> Want to make a dummy component somewhere that uses this kind of
>>> initialization and see what happens? Put a test for the C99 initialization
>>> style in configure.m4 to see if it works or not; MTT will then
>>> check this for all the compilers that we care about.
>>>
>>>
>>> On Jan 19, 2011, at 3:58 PM, Ralph Castain wrote:
>>>
I believe the majority of structs used in OMPI are actually declared to be
opal objects of some flavor, so I'm not sure how much this will
actually accomplish. Other than that, I have no real objection - either
way works fine for me.
On Jan 19, 2011, at 12:29 PM, George Bosilca wrote:
> I'm with you on that. Let's create a fake module using the ISO C99 naming
> scheme, and leave it to MTT to figure out where is breaks!
>
> george.
>
> On Jan 19, 2011, at 14:23 , Nathan Hjelm wrote:
>
>> I don't know if this has been discussed before or if this will break
>> Windows (or some obscure platform) support but I would like to start
>> using the ISO C99 style for struct initialization (see section 6.7.8,
>> example 10 in
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf). Using this
>> style would make mca code much easier to read. Any thoughts? Would this
>> break something?
>>
>> Example:
>> struct module_foo {
>> char *bar;
>> int baz;
>> };
>>
>> struct foo foobar = {
>> .bar = "foobar",
>> .baz = 1
>> };
>>
>> -Nathan
>> HPC-3, LANL
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>
>>>
>>> --
>>> 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
>>> ht
Re: [OMPI devel] RFC: use ISO C99 style struct initialization
same type of warnings with gcc-4.3.3
george.
On Jan 20, 2011, at 15:21 , George Bosilca wrote:
> Even before getting into the Oracle compiler, a fully compliant C99 compiler
> such as gcc 4.2.1 complains a lot about the new code. Here is what I get:
>
> ../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:25: warning:
> ISO C90 forbids specifying subobject to initialize
> ../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:28: warning:
> ISO C90 forbids specifying subobject to initialize
> ../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:29: warning:
> ISO C90 forbids specifying subobject to initialize
> ../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:30: warning:
> ISO C90 forbids specifying subobject to initialize
> ../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:31: warning:
> ISO C90 forbids specifying subobject to initialize
> ../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:33: warning:
> ISO C90 forbids specifying subobject to initialize
> ../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:34: warning:
> ISO C90 forbids specifying subobject to initialize
> ../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:35: warning:
> ISO C90 forbids specifying subobject to initialize
> ../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:37: warning:
> ISO C90 forbids specifying subobject to initialize
> ../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:39: warning:
> ISO C90 forbids specifying subobject to initialize
> ../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c: In function
> 'component_open':
> ../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:45: warning:
> unused variable 'c'
> ../../../../../ompi/orte/mca/debugger/dummy/dummy.c:67: warning: ISO C90
> forbids specifying subobject to initialize
> ../../../../../ompi/orte/mca/debugger/dummy/dummy.c:68: warning: ISO C90
> forbids specifying subobject to initialize
> ../../../../../ompi/orte/mca/debugger/dummy/dummy.c:69: warning: ISO C90
> forbids specifying subobject to initialize
> ../../../../../ompi/orte/mca/debugger/dummy/dummy.c:70: warning: ISO C90
> forbids specifying subobject to initialize
>
>
>
> george.
>
>
>
>
> On Jan 19, 2011, at 20:36 , Terry Dontje wrote:
>
>> Hopefully we'll find out tomorrow but I think I vaguely remember an issue
>> with the Studio compilers and this type of initialization style.
>>
>> --td
>>
>> On 01/19/2011 05:22 PM, Nathan Hjelm wrote:
>>> Done. I added the module orte/mca/debugger/dummy and I will remove it
>>> tomorrow.
>>>
>>> -Nathan
>>> HPC-3, LANL
>>>
>>> On Wed, 19 Jan 2011, Jeff Squyres wrote:
>>>
+1 on Ralph and George's comments.
Want to make a dummy component somewhere that uses this kind of
initialization and see what happens? Put a test for the C99
initialization style in configure.m4 to see if it works or not;
MTT will then check this for all the compilers that we care about.
On Jan 19, 2011, at 3:58 PM, Ralph Castain wrote:
> I believe the majority of structs used in OMPI are actually declared to
> be opal objects of some flavor, so I'm not sure how much this
> will actually accomplish. Other than that, I have no real objection -
> either way works fine for me.
>
>
> On Jan 19, 2011, at 12:29 PM, George Bosilca wrote:
>
>> I'm with you on that. Let's create a fake module using the ISO C99
>> naming scheme, and leave it to MTT to figure out where is breaks!
>>
>> george.
>>
>> On Jan 19, 2011, at 14:23 , Nathan Hjelm wrote:
>>
>>> I don't know if this has been discussed before or if this will break
>>> Windows (or some obscure platform) support but I would like to start
>>> using the ISO C99 style for struct initialization (see section 6.7.8,
>>> example 10 in
>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf). Using this
>>> style would make mca code much easier to read. Any thoughts? Would this
>>> break something?
>>>
>>> Example:
>>> struct module_foo {
>>>char *bar;
>>>int baz;
>>> };
>>>
>>> struct foo foobar = {
>>>.bar = "foobar",
>>>.baz = 1
>>> };
>>>
>>> -Nathan
>>> HPC-3, LANL
>>> ___
>>> devel mailing list
>>> de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>>
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
>
Re: [OMPI devel] RFC: use ISO C99 style struct initialization
I didn't see those warning on my mac when I compiled but gcc does indeed
complain if -pedantic is specified without the -std=c99 option. So, in order to
use the initialization style we would need to specify -std=c99 option for gcc.
Not sure if there would be a problem specifying -std=c99?
-Nathan
On Thu, 20 Jan 2011, George Bosilca wrote:
Even before getting into the Oracle compiler, a fully compliant C99 compiler
such as gcc 4.2.1 complains a lot about the new code. Here is what I get:
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:25: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:28: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:29: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:30: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:31: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:33: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:34: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:35: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:37: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:39: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c: In function
'component_open':
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:45: warning:
unused variable 'c'
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:67: warning: ISO C90
forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:68: warning: ISO C90
forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:69: warning: ISO C90
forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:70: warning: ISO C90
forbids specifying subobject to initialize
george.
On Jan 19, 2011, at 20:36 , Terry Dontje wrote:
Hopefully we'll find out tomorrow but I think I vaguely remember an issue with
the Studio compilers and this type of initialization style.
--td
On 01/19/2011 05:22 PM, Nathan Hjelm wrote:
Done. I added the module orte/mca/debugger/dummy and I will remove it tomorrow.
-Nathan
HPC-3, LANL
On Wed, 19 Jan 2011, Jeff Squyres wrote:
+1 on Ralph and George's comments.
Want to make a dummy component somewhere that uses this kind of initialization
and see what happens? Put a test for the C99 initialization style in
configure.m4 to see if it works or not; MTT will then check this for
all the compilers that we care about.
On Jan 19, 2011, at 3:58 PM, Ralph Castain wrote:
I believe the majority of structs used in OMPI are actually declared to be opal
objects of some flavor, so I'm not sure how much this will actually
accomplish. Other than that, I have no real objection - either way works fine
for me.
On Jan 19, 2011, at 12:29 PM, George Bosilca wrote:
I'm with you on that. Let's create a fake module using the ISO C99 naming
scheme, and leave it to MTT to figure out where is breaks!
george.
On Jan 19, 2011, at 14:23 , Nathan Hjelm wrote:
I don't know if this has been discussed before or if this will break Windows
(or some obscure platform) support but I would like to start using the ISO C99
style for struct initialization (see section 6.7.8, example 10 in
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf). Using this style
would make mca code much easier to read. Any thoughts? Would this break
something?
Example:
struct module_foo {
char *bar;
int baz;
};
struct foo foobar = {
.bar = "foobar",
.baz = 1
};
-Nathan
HPC-3, LANL
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
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
http://www.open-mpi.org/mailman/listinfo.cgi/devel
___
devel mailing list
de...@open-mpi.org
htt
Re: [OMPI devel] RFC: use ISO C99 style struct initialization
This is because gcc is defaulting to -std=c90. I strongly suspect that
adding -std=c99 to the CFLAGS eliminates George's warnings. However,
one may need to hunt down equivalent dialect flags for other compilers too.
-Paul
George Bosilca wrote:
same type of warnings with gcc-4.3.3
george.
On Jan 20, 2011, at 15:21 , George Bosilca wrote:
Even before getting into the Oracle compiler, a fully compliant C99 compiler
such as gcc 4.2.1 complains a lot about the new code. Here is what I get:
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:25: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:28: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:29: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:30: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:31: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:33: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:34: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:35: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:37: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:39: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c: In function
'component_open':
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:45: warning:
unused variable 'c'
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:67: warning: ISO C90
forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:68: warning: ISO C90
forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:69: warning: ISO C90
forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:70: warning: ISO C90
forbids specifying subobject to initialize
george.
On Jan 19, 2011, at 20:36 , Terry Dontje wrote:
Hopefully we'll find out tomorrow but I think I vaguely remember an issue with
the Studio compilers and this type of initialization style.
--td
On 01/19/2011 05:22 PM, Nathan Hjelm wrote:
Done. I added the module orte/mca/debugger/dummy and I will remove it tomorrow.
-Nathan
HPC-3, LANL
On Wed, 19 Jan 2011, Jeff Squyres wrote:
+1 on Ralph and George's comments.
Want to make a dummy component somewhere that uses this kind of initialization and see what happens? Put a test for the C99 initialization style in configure.m4 to see if it works or not; MTT will then check this for all the compilers that we care about.
On Jan 19, 2011, at 3:58 PM, Ralph Castain wrote:
I believe the majority of structs used in OMPI are actually declared to be opal objects of some flavor, so I'm not sure how much this will actually accomplish. Other than that, I have no real objection - either way works fine for me.
On Jan 19, 2011, at 12:29 PM, George Bosilca wrote:
I'm with you on that. Let's create a fake module using the ISO C99 naming scheme, and leave it to MTT to figure out where is breaks!
george.
On Jan 19, 2011, at 14:23 , Nathan Hjelm wrote:
I don't know if this has been discussed before or if this will break Windows (or some obscure platform) support but I would like to start using the ISO C99 style for struct initialization (see section 6.7.8, example 10 in http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf). Using this style would make mca code much easier to read. Any thoughts? Would this break something?
Example:
struct module_foo {
char *bar;
int baz;
};
struct foo foobar = {
.bar = "foobar",
.baz = 1
};
-Nathan
HPC-3, LANL
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
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
http://www.op
[OMPI devel] ompi_mpi_init: orte_init failed
Hello, I'm trying to build OpenMPI with fortran on my Mac OS machines using gfortran. I'm using the 64-bit option and trying to install 1.4.2. It seems to build ok and when I compile and run simple programs it works. When I try a more complicated case it works on my desktop but not my laptop. The error that I get is shown below. The fact that it works on my desktop shows me there's a problem with my build on my laptop. Any ideas where I can look to fix it? Thanks, Francis [[INVALID],INVALID] ORTE_ERROR_LOG: Not found in file runtime/orte_init.c at line 125 -- It looks like orte_init failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during orte_init; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): orte_ess_base_select failed --> Returned value Not found (-13) instead of ORTE_SUCCESS -- -- It looks like MPI_INIT failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during MPI_INIT; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): ompi_mpi_init: orte_init failed --> Returned "Not found" (-13) instead of "Success" (0) -- *** The MPI_Init() function was called before MPI_INIT was invoked. *** This is disallowed by the MPI standard. *** Your MPI job will now abort.
Re: [OMPI devel] RFC: use ISO C99 style struct initialization
Yeah, it seems that if the standard is not specified gcc backs off to gnu89
(c90 + some of c99). I have tested the following compilers so far:
gcc : ok by default, not ok with -pedantic unless -std=c99 is specified
icc : ok without any flags, strangely ok with -no-c99 (probably
supported by intel c89 extensions?)
pgi : ok with or without -c99, not so much with -c89
cray : ok by default, not ok with -hnoc99
pathscale : same as gcc
Microsoft's compiler is the likely going to be the compiler that is going to
have problems with this. They implemented some of c99 but not all of it.
-Nathan
On Thu, 20 Jan 2011, Paul H. Hargrove wrote:
This is because gcc is defaulting to -std=c90. I strongly suspect that
adding -std=c99 to the CFLAGS eliminates George's warnings. However, one may
need to hunt down equivalent dialect flags for other compilers too.
-Paul
George Bosilca wrote:
same type of warnings with gcc-4.3.3
george.
On Jan 20, 2011, at 15:21 , George Bosilca wrote:
Even before getting into the Oracle compiler, a fully compliant C99
compiler such as gcc 4.2.1 complains a lot about the new code. Here is
what I get:
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:25: warning:
ISO C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:28: warning:
ISO C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:29: warning:
ISO C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:30: warning:
ISO C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:31: warning:
ISO C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:33: warning:
ISO C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:34: warning:
ISO C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:35: warning:
ISO C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:37: warning:
ISO C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:39: warning:
ISO C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c: In function
'component_open':
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:45: warning:
unused variable 'c'
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:67: warning: ISO C90
forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:68: warning: ISO C90
forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:69: warning: ISO C90
forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:70: warning: ISO C90
forbids specifying subobject to initialize
george.
On Jan 19, 2011, at 20:36 , Terry Dontje wrote:
Hopefully we'll find out tomorrow but I think I vaguely remember an issue
with the Studio compilers and this type of initialization style.
--td
On 01/19/2011 05:22 PM, Nathan Hjelm wrote:
Done. I added the module orte/mca/debugger/dummy and I will remove it
tomorrow.
-Nathan HPC-3, LANL
On Wed, 19 Jan 2011, Jeff Squyres wrote:
+1 on Ralph and George's comments.
Want to make a dummy component somewhere that uses this kind of
initialization and see what happens? Put a test for the C99
initialization style in configure.m4 to see if it works or not;
MTT will then check this for all the compilers that we care about.
On Jan 19, 2011, at 3:58 PM, Ralph Castain wrote:
I believe the majority of structs used in OMPI are actually declared
to be opal objects of some flavor, so I'm not sure how much
this will actually accomplish. Other than that, I have no real
objection - either way works fine for me.
On Jan 19, 2011, at 12:29 PM, George Bosilca wrote:
I'm with you on that. Let's create a fake module using the ISO C99
naming scheme, and leave it to MTT to figure out where is breaks!
george.
On Jan 19, 2011, at 14:23 , Nathan Hjelm wrote:
I don't know if this has been discussed before or if this will break
Windows (or some obscure platform) support but I would like to start
using the ISO C99 style for struct initialization (see section
6.7.8, example 10 in
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf). Using
this style would make mca code much easier to read. Any thoughts?
Would this break something?
Example: struct module_foo {char *bar;int baz; };
struct foo foobar = {.bar = "foobar",.baz = 1 };
-Nathan HPC-3, LANL ___
devel mailing list de...@open-mpi.org
http://www.open-mpi.o
Re: [OMPI devel] ompi_mpi_init: orte_init failed
Francis, I cannot address your situation specifically, but I can tell you from experience that you must pay close attention to the version of Mac OS X for 32-bit/64-bit compiling. gcc/gfortran defaults to 32-bit on OS X 10.5. I am told they default to 64-bit on OS X 10.6. Thus, to compile and link with the proper 64-bit libraries, you may have to specify -m64 at every step: when creating the OpenMPI library, when compiling your application, and when linking your application (presumably, the last two steps are done by an OpenMPI wrapper script for you). On my (desktop) OS X 10.5 Mac, I used the following commands to patch (using my own patch script) and make OpenMPI 1.4.2: # Patch OpenMPI 1.4.2 tar -xjf openmpi-1.4.2.tar.bz2 source patch-openmpi-1.4.2.sh # Configure OpenMPI 1.4.2 for GNU compilers cd openmpi-1.4.2 ./configure >configure.log 2>&1 \ --prefix=$HOME/Desktop/Software/OpenMPI/gnu \ CC="gcc -m64" \ CFLAGS="-g -fast" \ CXX="g++ -m64" \ CXXFLAGS="-g -fast" \ FC="gfortran -m64" \ FCFLAGS="-g -fast" \ F77="gfortran -m64" \ FFLAGS="-g -fast" # Make the library make >make.log 2>&1 # Validate the library make check >check.log 2>&1 Then, I used the following commands to install it: # Install OpenMPI 1.4.2 cd openmpi-1.4.2 make install >install.log 2>&1 Maybe the first thing you could try is to run make check on your laptop. I don't have a laptop to try to replicate your failure. Larry Baker US Geological Survey 650-329-5608 ba...@usgs.gov On Jan 20, 2011, at 2:00 PM, Francis Poulin wrote: Hello, I'm trying to build OpenMPI with fortran on my Mac OS machines using gfortran. I'm using the 64-bit option and trying to install 1.4.2. It seems to build ok and when I compile and run simple programs it works. When I try a more complicated case it works on my desktop but not my laptop. The error that I get is shown below. The fact that it works on my desktop shows me there's a problem with my build on my laptop. Any ideas where I can look to fix it? Thanks, Francis [[INVALID],INVALID] ORTE_ERROR_LOG: Not found in file runtime/ orte_init.c at line 125 -- It looks like orte_init failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during orte_init; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): orte_ess_base_select failed --> Returned value Not found (-13) instead of ORTE_SUCCESS -- -- It looks like MPI_INIT failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during MPI_INIT; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): ompi_mpi_init: orte_init failed --> Returned "Not found" (-13) instead of "Success" (0) -- *** The MPI_Init() function was called before MPI_INIT was invoked. *** This is disallowed by the MPI standard. *** Your MPI job will now abort. ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
