Re: [hwloc-devel] MPICH2 question
On 10/21/2009 04:44 PM, Samuel Thibault wrote: > Pavan Balaji, le Wed 21 Oct 2009 16:40:42 -0500, a écrit : >>> Please read this thread: >>> >>> http://www.open-mpi.org/community/lists/hwloc-devel/2009/09/0054.php >> Thanks. Is the only issue to not use AC_C_RESTRICT that of conflicting >> name space? > > Not only, it's also that you never know in advance which compiler will > be used while including hwloc.h, and thus what _that_ compiler will > support, thus the dynamic discovery. I'm not sure I understand the problem here. Let me illustrate what I mean. Suppose you are using gcc to compile hwloc and suncc to compile some application using hwloc. Let's say gcc uses __restrict and suncc uses _Restrict (I didn't check what these compilers use; these are just for illustration). hwloc configure.in will have -- AX_PREFIX_CONFIG_H([include/hwloc_config.h], [hwloc]) AC_C_RESTRICT Suppose you compiled hwloc with gcc, you'll get the following in your new config file -- /* Note the hwloc_ prefix added by the AX_PREFIX_CONFIG_H macro */ #define hwloc_restrict __restrict Now, if the application is using suncc, and it tries to find what spelling for restrict it needs to use, it'll come up with -- #define restrict _Restrict These do not conflict at all; hwloc will use its definition of restrict and the application will use its. Why is this a problem? -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji
Re: [hwloc-devel] MPICH2 question
On 10/21/2009 10:38 AM, Samuel Thibault wrote: > Pavan Balaji, le Wed 21 Oct 2009 10:36:33 -0500, a écrit : >> On 10/21/2009 10:28 AM, Samuel Thibault wrote: >>> Pavan Balaji, le Wed 21 Oct 2009 09:55:36 -0500, a écrit : 1. I see a AC_PROG_CC_C99 in the configure.ac. Do you require the compiler to be C99 capable always? >>> No, we ended up using constructs which should pass c90 and the compilers >>> we have tested (aix, solaris, icc). >> So shouldn't the AC_PROG_CC_C99 be gotten rid of? > > No because when C99 is available, we enable some optimization features, > like __hwloc_restrict. It looks like __hwloc_restrict is not actually checking for C99, but instead doing something GNU specific: #if (__GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 95)) # define __hwloc_restrict __restrict #else # if __STDC_VERSION__ >= 199901L # define __hwloc_restrict restrict # else # define __hwloc_restrict # endif #endif Wouldn't it be better to add a feature test for restrict, instead of this? -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji
Re: [hwloc-devel] MPICH2 question
On Oct 21, 2009, at 1:18 PM, Samuel Thibault wrote: > configuring/building hwloc with icc results in a *lot* > of warnings; I didn't test functionality). Mmm, I have already successfully tested with icc9. The kind of warnings I've seen were not worth fixing to my mind: unused parameters, mostly, are you using some particular option? I didn't look closely at what the warnings were -- I just saw a lot of them go by. I can look closer. I didn't use any particular configure options -- just --prefix. This was on RHEL4 using icc 11.1.056 (I just updated my intel compilers this morning to the latest latest latest). (/me looks closer) Wow, you're right -- there's *truckloads* of variable-never-referenced and variable-set-but-not-used warnings. Those should be cleaned up IMHO, but they can wait until after 0.9.1, also IMHO. I'll file a ticket against 1.0. My pathscale compiler license has expired, and the license server for my PGI license has gone down -- so I can't check any other compilers at the moment. -- Jeff Squyres jsquy...@cisco.com
Re: [hwloc-devel] MPICH2 question
> Pavan -- is it a problem to always compile hwloc with gcc? Yeah, this will be a problem. For us to enable hwloc by default, it'll need to build with all compilers and on all platforms without errors (and hopefully without warnings either). -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji
Re: [hwloc-devel] MPICH2 question
Jeff Squyres, le Wed 21 Oct 2009 12:50:55 -0400, a écrit : > configuring/building hwloc with icc results in a *lot* > of warnings; I didn't test functionality). Mmm, I have already successfully tested with icc9. The kind of warnings I've seen were not worth fixing to my mind: unused parameters, mostly, are you using some particular option? Samuel
Re: [hwloc-devel] MPICH2 question
Jeff Squyres, le Wed 21 Oct 2009 12:46:38 -0400, a écrit : > I'd be surprised if there's a system out there that doesn't have some > flavor of egrep that satisfies AC_PROG_EGREP (especially if Libtool > uses it heavily). Do we know if this is the case, or is this a > hypothetical that a suitable egrep might not be found? Well, all I can say is that I've had no problem on the tested OSes, i.e. notably solaris, AIX, HP-UX and OSF (without the GNU tools). Samuel
Re: [hwloc-devel] MPICH2 question
FWIW, I see at least some GNU-isms in the hwloc code that might be problematic for embedding hwloc in other code bases that don't use gcc to compile. E.g., in OMPI, we'd prefer to use the same compiler suite to compile hwloc that was used to compile OMPI itself (e.g., intel, PGI, ...etc. -- configuring/building hwloc with icc results in a *lot* of warnings; I didn't test functionality). I don't know if we want to target that for v0.9.1 or not -- my first reaction is to postpone this to v1.0 in order to get v0.9.1 out the door. Fully bake in all the embedding -- including cleaning up any potential GNU-isms -- for v1.0. Pavan -- is it a problem to always compile hwloc with gcc? On Oct 21, 2009, at 11:39 AM, Pavan Balaji wrote: On 10/21/2009 10:38 AM, Samuel Thibault wrote: > Pavan Balaji, le Wed 21 Oct 2009 10:36:33 -0500, a écrit : >> On 10/21/2009 10:28 AM, Samuel Thibault wrote: >>> Pavan Balaji, le Wed 21 Oct 2009 09:55:36 -0500, a écrit : 1. I see a AC_PROG_CC_C99 in the configure.ac. Do you require the compiler to be C99 capable always? >>> No, we ended up using constructs which should pass c90 and the compilers >>> we have tested (aix, solaris, icc). >> So shouldn't the AC_PROG_CC_C99 be gotten rid of? > > No because when C99 is available, we enable some optimization features, > like __hwloc_restrict. Gotcha! Thanks for the clarification. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji ___ hwloc-devel mailing list hwloc-de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel -- Jeff Squyres jsquy...@cisco.com
Re: [hwloc-devel] MPICH2 question
On Oct 21, 2009, at 10:20 AM, Samuel Thibault wrote: I've checked configure, only the check for egrep may fail and does not provide any fallback which we could have used. It's only used for the documentation generation, Jeff, maybe we can find an alternative to egrep for what we use it for? We use it for running latex (i.e., looking for some warning messages in the latex output to know if we need to run it again). This could be coded around and/or removed entirely if desired. However, I notice that libtool makes extensive use of egrep. Specifically, even if I remove AC_PROG_EGREP, it's checked for later in configure and is used a lot by libtool. I'd be surprised if there's a system out there that doesn't have some flavor of egrep that satisfies AC_PROG_EGREP (especially if Libtool uses it heavily). Do we know if this is the case, or is this a hypothetical that a suitable egrep might not be found? -- Jeff Squyres jsquy...@cisco.com
Re: [hwloc-devel] MPICH2 question
On 10/21/2009 10:38 AM, Samuel Thibault wrote: > Pavan Balaji, le Wed 21 Oct 2009 10:36:33 -0500, a écrit : >> On 10/21/2009 10:28 AM, Samuel Thibault wrote: >>> Pavan Balaji, le Wed 21 Oct 2009 09:55:36 -0500, a écrit : 1. I see a AC_PROG_CC_C99 in the configure.ac. Do you require the compiler to be C99 capable always? >>> No, we ended up using constructs which should pass c90 and the compilers >>> we have tested (aix, solaris, icc). >> So shouldn't the AC_PROG_CC_C99 be gotten rid of? > > No because when C99 is available, we enable some optimization features, > like __hwloc_restrict. Gotcha! Thanks for the clarification. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji
[hwloc-devel] MPICH2 question
Pavan and I chatted on the phone this morning about https://svn.open-mpi.org/trac/hwloc/ticket/4 . The *easiest* solution for MPICH2 would be if they could AC_CONFIG_SUBDIRS our configure script. However, this has the condition that hwloc's configure could never fail -- e.g., it can't call AC_MSG_ERROR. For unsupported platforms, it will need to still succeed and build/install a token libhwloc.la. This libhwloc.a can just return a graceful failure from hwloc_init() at run-time indicating that it can't do anything on this platform. By default, I'm not comfortable with this. But I would be comfortable with such a scheme if a non-default flag is passed to configure (e.g., "--enable-always-build", or perhaps a better name). Would this be hard to do from the building side? I.e., I have not looked in the C code much yet -- do we have much code that won't build on unsupported platforms, or do we need a "generic / always fail" .c file that is trivial/portable C, but always returns failures for all hwloc API functions...? -- Jeff Squyres jsquy...@cisco.com
