January 2014 - devel - mailman3.cels.anl.gov

Re: [mpich-devel] MPICH per-obj build issues
by Archer, Charles J 23 Jan '14

23 Jan '14

Ok. The patch isn’t quite right, I’m going through all the thread options to test my current patch. You definitely need to protect the prototypes with (my first patch will break the single thread build): #if defined(MPICH_IS_THREADED) && !defined(MPID_DEVICE_DEFINES_THREAD_CS) -C From: Wesley Bland [mailto:[email protected]] Sent: Thursday, January 23, 2014 12:44 PM To: Archer, Charles J Cc: Pavan Balaji; William Gropp; devel(a)mpich.org Subject: Re: MPICH per-obj build issues Hi Charles, I know little about the threading inside MPICH at this point and even less about per object builds. Though I intend to now learn more about this, I’m CC’ing the mpich-devel mailing list in an effort to bring in the right people more quickly. Wesley On Jan 23, 2014, 2:03:48 PM, Archer, Charles J <charles.j.archer(a)intel.com<mailto:[email protected]>> wrote: ________________________________ Hi, Wesley, I’m playing around with per-obj builds, using per-object/tls configure options. pamid defined it’s own critical sections so it doesn’t see this build error, but I’m trying to use default per-obj builds and I hit this: mpiimplthreadpost.h:27: error: static declaration of 'MPIU_Thread_CS_enter_lockname_impl_' follows non-static declaration My solution for me was to prototype the functions in src/include/mpiimplthread.h: diff --git a/src/include/mpiimplthread.h b/src/include/mpiimplthread.h index f0141c6..c9af705 100644 --- a/src/include/mpiimplthread.h +++ b/src/include/mpiimplthread.h @@ -1039,5 +1039,20 @@ do { \ #define MPIU_THREAD_MPI_OBJ_FINALIZE(objptr_) do {} while (0) #endif + +#if 0 +static MPIU_DBG_INLINE_KEYWORD void +MPIU_Thread_CS_enter_lockname_impl_(enum MPIU_Nest_mutexes kind, + const char *lockname, + MPID_Thread_mutex_t *mutex); + + +static MPIU_DBG_INLINE_KEYWORD void +MPIU_Thread_CS_exit_lockname_impl_(enum MPIU_Nest_mutexes kind, + const char *lockname, + MPID_Thread_mutex_t *mutex); +#endif + + #endif /* !defined(MPIIMPLTHREAD_H_INCLUDED) */ …. Can you guys add in the prototypes? This patch isn’t complete, I wanted to talk to you first. Is this the right solution? Also related (reported by Bill): https://trac.mpich.org/projects/mpich/ticket/1937

1 0

Re: [mpich-devel] MPICH per-obj build issues
by Wesley Bland 23 Jan '14

23 Jan '14

Hi Charles, I know little about the threading inside MPICH at this point and even less about per object builds. Though I intend to now learn more about this, I’m CC’ing the mpich-devel mailing list in an effort to bring in the right people more quickly. Wesley On Jan 23, 2014, 2:03:48 PM, Archer, Charles J <charles.j.archer(a)intel.com> wrote: Hi, Wesley, I’m playing around with per-obj builds, using per-object/tls configure options. pamid defined it’s own critical sections so it doesn’t see this build error, but I’m trying to use default per-obj builds and I hit this: mpiimplthreadpost.h:27: error: static declaration of 'MPIU_Thread_CS_enter_lockname_impl_' follows non-static declaration My solution for me was to prototype the functions in src/include/mpiimplthread.h: diff --git a/src/include/mpiimplthread.h b/src/include/mpiimplthread.h index f0141c6..c9af705 100644 --- a/src/include/mpiimplthread.h +++ b/src/include/mpiimplthread.h @@ -1039,5 +1039,20 @@ do { \ #define MPIU_THREAD_MPI_OBJ_FINALIZE(objptr_) do {} while (0) #endif + +#if 0 +static MPIU_DBG_INLINE_KEYWORD void +MPIU_Thread_CS_enter_lockname_impl_(enum MPIU_Nest_mutexes kind, + const char *lockname, + MPID_Thread_mutex_t *mutex); + + +static MPIU_DBG_INLINE_KEYWORD void +MPIU_Thread_CS_exit_lockname_impl_(enum MPIU_Nest_mutexes kind, + const char *lockname, + MPID_Thread_mutex_t *mutex); +#endif + + #endif /* !defined(MPIIMPLTHREAD_H_INCLUDED) */ …. Can you guys add in the prototypes? This patch isn’t complete, I wanted to talk to you first. Is this the right solution? Also related (reported by Bill): https://trac.mpich.org/projects/mpich/ticket/1937

1 0

Re: [mpich-devel] P states and MPI
by Rountree, Barry L. 17 Jan '14

17 Jan '14

The released version of Adagio is here: [email protected]:scalability-llnl/Adagio.git The algorithm described is the most trivial of the three we looked at in Rountree ICS 2009. We called it "Fermata": predict how long the MPI rank would wait in a blocking MPI call, and if the expected delay was long enough, drop down to the lowest CPU clock frequency and pop back up just before the call was expected to complete. We saw significant (>10%) total system energy savings will <1% execution time overhead. The best algorithm, though, slowed down computation to consume slack time that was generated by blocking calls, and only if any slack remained we dropped into the lowest frequency. That got us 20% total system energy savings on ParaDis with <1% execution time overhead. This was very much a research project and I expect bitrot has set in by now. Rewriting from scratch wouldn't be difficult (now that I have 5 years more experience writing PMPI tools), but there are a few complications that would need to be addressed before this could be made into a production tool (OpenMP, nondeterminism caused by turbo mode, processor performance inhomogeneity, etc). I think the more interesting question is how to optimize performance under a power bound; solving that problem has the side effect of achieving near-optimal energy use (at least in the common case). We're working on redoing Adagio to solve thing problem, using Intel Running Average Power Limit (RAPL) technology. Best, Barry On 1/17/14 8:25 AM, "Bronis R. de Supinski" <bronis(a)llnl.gov> wrote: > >Jeff: > >Adagio has similar characteristics. Barry has recently >released it so he should comment on its availability. > >Bronis > > >On Fri, 17 Jan 2014, Jeff Hammond wrote: > >> Thanks Bill. I agree with your assessment. If this is the type of >> thing that pays off in practice, then it seems to argue for the >> necessary policy changes. >> >> Bronis - What impresses me about this is the ease at which it can >> deployed. For the codes for which it reduces power consumption, it's >> free joules. If it doesn't, there is nothing lost. If your code is >> similarly portable and easy to deploy, then I'll have to evaluate >> which one is more effective for the relevant workload. >> >> Best, >> >> Jeff >> >> >> On Fri, Jan 17, 2014 at 8:46 AM, Bronis R. de Supinski >><bronis(a)llnl.gov> wrote: >>> >>> Um, I would say the Dell approach has no novelty and is >>> rather rudimentary. We have done a lot more in Adagio: >>> >>> http://dl.acm.org/citation.cfm?id=1542340 >>> >>> @inproceedings{Rountree:2009:AMD:1542275.1542340, >>> author = {Rountree, Barry and Lownenthal, David K. and de Supinski, >>>Bronis >>> R. and Schulz, Martin and Freeh, Vincent W. and Bletsch, Tyler}, >>> title = {Adagio: Making DVS Practical for Complex HPC Applications}, >>> booktitle = {Proceedings of the 23rd International Conference on >>> Supercomputing}, >>> series = {ICS '09}, >>> year = {2009}, >>> isbn = {978-1-60558-498-0}, >>> location = {Yorktown Heights, NY, USA}, >>> pages = {460--469}, >>> numpages = {10}, >>> url = {http://doi.acm.org/10.1145/1542275.1542340}, >>> doi = {10.1145/1542275.1542340}, >>> acmid = {1542340}, >>> publisher = {ACM}, >>> address = {New York, NY, USA}, >>> keywords = {dvfs, dvs, energy, mpi, runtime}, >>> >>> } >>> >>> >>> >>> On Fri, 17 Jan 2014, William Gropp wrote: >>> >>>> There has been some work on this for parallel programs; Wu Feng at >>>> Virginia Tech has done some, for example. I don't recall seeing any >>>>work >>>> that used the profiling interface. Some of the issues raised, >>>>especially >>>> the required privs, mean that this is only available for experiments, >>>>not >>>> production, until that changes. Also, its sometimes possible to make >>>> predictions about wait times based on previous iterations; that could >>>>be >>>> used to refine such control. >>>> >>>> Bill >>>> >>>> William Gropp >>>> Director, Parallel Computing Institute >>>> Deputy Director for Research >>>> Institute for Advanced Computing Applications and Technologies >>>> Thomas M. Siebel Chair in Computer Science >>>> University of Illinois Urbana-Champaign >>>> >>>> >>>> >>>> >>>> On Jan 16, 2014, at 9:36 PM, Jeff Hammond wrote: >>>> >>>>> I was impressed by >>>>> >>>>> >>>>>http://www.hpcadvisorycouncil.com/events/2013/Spain-Workshop/pdf/5_Del >>>>>l.pdf >>>>> / >>>>> >>>>>http://www.bsc.es/sites/default/files/public/mare_nostrum/2013hpcac-05 >>>>>.pdf. >>>>> I wonder if anyone else has seen this, done anything similar, is >>>>> interested in doing something similar, etc. I can imagine that a >>>>>more >>>>> integrated implementation has some performance advantages, albeit at >>>>> much greater maintenance cost. >>>>> >>>>> Thanks, >>>>> >>>>> Jeff >>>>> >>>>> -- >>>>> Jeff Hammond >>>>> jeff.science(a)gmail.com >>>> >>>> >>>> >>> >> >> >> >> -- >> Jeff Hammond >> Argonne Leadership Computing Facility >> University of Chicago Computation Institute >> jhammond(a)anl.gov / jhammond(a)uchicago.edu / (630) 252-5381 >> http://www.linkedin.com/in/jeffhammond >> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond >>

1 0

Re: [mpich-devel] P states and MPI
by Bronis R. de Supinski 17 Jan '14

17 Jan '14

Jeff: Adagio has similar characteristics. Barry has recently released it so he should comment on its availability. Bronis On Fri, 17 Jan 2014, Jeff Hammond wrote: > Thanks Bill. I agree with your assessment. If this is the type of > thing that pays off in practice, then it seems to argue for the > necessary policy changes. > > Bronis - What impresses me about this is the ease at which it can > deployed. For the codes for which it reduces power consumption, it's > free joules. If it doesn't, there is nothing lost. If your code is > similarly portable and easy to deploy, then I'll have to evaluate > which one is more effective for the relevant workload. > > Best, > > Jeff > > > On Fri, Jan 17, 2014 at 8:46 AM, Bronis R. de Supinski <bronis(a)llnl.gov> wrote: >> >> Um, I would say the Dell approach has no novelty and is >> rather rudimentary. We have done a lot more in Adagio: >> >> http://dl.acm.org/citation.cfm?id=1542340 >> >> @inproceedings{Rountree:2009:AMD:1542275.1542340, >> author = {Rountree, Barry and Lownenthal, David K. and de Supinski, Bronis >> R. and Schulz, Martin and Freeh, Vincent W. and Bletsch, Tyler}, >> title = {Adagio: Making DVS Practical for Complex HPC Applications}, >> booktitle = {Proceedings of the 23rd International Conference on >> Supercomputing}, >> series = {ICS '09}, >> year = {2009}, >> isbn = {978-1-60558-498-0}, >> location = {Yorktown Heights, NY, USA}, >> pages = {460--469}, >> numpages = {10}, >> url = {http://doi.acm.org/10.1145/1542275.1542340}, >> doi = {10.1145/1542275.1542340}, >> acmid = {1542340}, >> publisher = {ACM}, >> address = {New York, NY, USA}, >> keywords = {dvfs, dvs, energy, mpi, runtime}, >> >> } >> >> >> >> On Fri, 17 Jan 2014, William Gropp wrote: >> >>> There has been some work on this for parallel programs; Wu Feng at >>> Virginia Tech has done some, for example. I don't recall seeing any work >>> that used the profiling interface. Some of the issues raised, especially >>> the required privs, mean that this is only available for experiments, not >>> production, until that changes. Also, its sometimes possible to make >>> predictions about wait times based on previous iterations; that could be >>> used to refine such control. >>> >>> Bill >>> >>> William Gropp >>> Director, Parallel Computing Institute >>> Deputy Director for Research >>> Institute for Advanced Computing Applications and Technologies >>> Thomas M. Siebel Chair in Computer Science >>> University of Illinois Urbana-Champaign >>> >>> >>> >>> >>> On Jan 16, 2014, at 9:36 PM, Jeff Hammond wrote: >>> >>>> I was impressed by >>>> >>>> http://www.hpcadvisorycouncil.com/events/2013/Spain-Workshop/pdf/5_Dell.pdf >>>> / >>>> http://www.bsc.es/sites/default/files/public/mare_nostrum/2013hpcac-05.pdf. >>>> I wonder if anyone else has seen this, done anything similar, is >>>> interested in doing something similar, etc. I can imagine that a more >>>> integrated implementation has some performance advantages, albeit at >>>> much greater maintenance cost. >>>> >>>> Thanks, >>>> >>>> Jeff >>>> >>>> -- >>>> Jeff Hammond >>>> jeff.science(a)gmail.com >>> >>> >>> >> > > > > -- > Jeff Hammond > Argonne Leadership Computing Facility > University of Chicago Computation Institute > jhammond(a)anl.gov / jhammond(a)uchicago.edu / (630) 252-5381 > http://www.linkedin.com/in/jeffhammond > https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond >

1 0

Re: [mpich-devel] P states and MPI
by Jeff Hammond 17 Jan '14

17 Jan '14

Thanks Bill. I agree with your assessment. If this is the type of thing that pays off in practice, then it seems to argue for the necessary policy changes. Bronis - What impresses me about this is the ease at which it can deployed. For the codes for which it reduces power consumption, it's free joules. If it doesn't, there is nothing lost. If your code is similarly portable and easy to deploy, then I'll have to evaluate which one is more effective for the relevant workload. Best, Jeff On Fri, Jan 17, 2014 at 8:46 AM, Bronis R. de Supinski <bronis(a)llnl.gov> wrote: > > Um, I would say the Dell approach has no novelty and is > rather rudimentary. We have done a lot more in Adagio: > > http://dl.acm.org/citation.cfm?id=1542340 > > @inproceedings{Rountree:2009:AMD:1542275.1542340, > author = {Rountree, Barry and Lownenthal, David K. and de Supinski, Bronis > R. and Schulz, Martin and Freeh, Vincent W. and Bletsch, Tyler}, > title = {Adagio: Making DVS Practical for Complex HPC Applications}, > booktitle = {Proceedings of the 23rd International Conference on > Supercomputing}, > series = {ICS '09}, > year = {2009}, > isbn = {978-1-60558-498-0}, > location = {Yorktown Heights, NY, USA}, > pages = {460--469}, > numpages = {10}, > url = {http://doi.acm.org/10.1145/1542275.1542340}, > doi = {10.1145/1542275.1542340}, > acmid = {1542340}, > publisher = {ACM}, > address = {New York, NY, USA}, > keywords = {dvfs, dvs, energy, mpi, runtime}, > > } > > > > On Fri, 17 Jan 2014, William Gropp wrote: > >> There has been some work on this for parallel programs; Wu Feng at >> Virginia Tech has done some, for example. I don't recall seeing any work >> that used the profiling interface. Some of the issues raised, especially >> the required privs, mean that this is only available for experiments, not >> production, until that changes. Also, its sometimes possible to make >> predictions about wait times based on previous iterations; that could be >> used to refine such control. >> >> Bill >> >> William Gropp >> Director, Parallel Computing Institute >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Thomas M. Siebel Chair in Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> >> On Jan 16, 2014, at 9:36 PM, Jeff Hammond wrote: >> >>> I was impressed by >>> >>> http://www.hpcadvisorycouncil.com/events/2013/Spain-Workshop/pdf/5_Dell.pdf >>> / >>> http://www.bsc.es/sites/default/files/public/mare_nostrum/2013hpcac-05.pdf. >>> I wonder if anyone else has seen this, done anything similar, is >>> interested in doing something similar, etc. I can imagine that a more >>> integrated implementation has some performance advantages, albeit at >>> much greater maintenance cost. >>> >>> Thanks, >>> >>> Jeff >>> >>> -- >>> Jeff Hammond >>> jeff.science(a)gmail.com >> >> >> > -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)anl.gov / jhammond(a)uchicago.edu / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-devel] P states and MPI
by Bronis R. de Supinski 17 Jan '14

17 Jan '14

I guess I should add that in particular we predict wait times on a call site basis in order to exploit consistent imbalance (or even slowly evolving imbalance, see the results for ParaDiS, for which process work changes but not rapidly, which is typical of real apps) On Fri, 17 Jan 2014, Bronis R. de Supinski wrote: > > Um, I would say the Dell approach has no novelty and is > rather rudimentary. We have done a lot more in Adagio: > > http://dl.acm.org/citation.cfm?id=1542340 > > @inproceedings{Rountree:2009:AMD:1542275.1542340, > author = {Rountree, Barry and Lownenthal, David K. and de Supinski, Bronis > R. and Schulz, Martin and Freeh, Vincent W. and Bletsch, Tyler}, > title = {Adagio: Making DVS Practical for Complex HPC Applications}, > booktitle = {Proceedings of the 23rd International Conference on > Supercomputing}, > series = {ICS '09}, > year = {2009}, > isbn = {978-1-60558-498-0}, > location = {Yorktown Heights, NY, USA}, > pages = {460--469}, > numpages = {10}, > url = {http://doi.acm.org/10.1145/1542275.1542340}, > doi = {10.1145/1542275.1542340}, > acmid = {1542340}, > publisher = {ACM}, > address = {New York, NY, USA}, > keywords = {dvfs, dvs, energy, mpi, runtime}, > } > > > > On Fri, 17 Jan 2014, William Gropp wrote: > >> There has been some work on this for parallel programs; Wu Feng at >> Virginia Tech has done some, for example. I don't recall seeing any work >> that used the profiling interface. Some of the issues raised, especially >> the required privs, mean that this is only available for experiments, not >> production, until that changes. Also, its sometimes possible to make >> predictions about wait times based on previous iterations; that could be >> used to refine such control. >> >> Bill >> >> William Gropp >> Director, Parallel Computing Institute >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Thomas M. Siebel Chair in Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> >> On Jan 16, 2014, at 9:36 PM, Jeff Hammond wrote: >> >> > I was impressed by >> > http://www.hpcadvisorycouncil.com/events/2013/Spain-Workshop/pdf/5_Dell.pdf >> > / >> > http://www.bsc.es/sites/default/files/public/mare_nostrum/2013hpcac-05.pdf. >> > I wonder if anyone else has seen this, done anything similar, is >> > interested in doing something similar, etc. I can imagine that a more >> > integrated implementation has some performance advantages, albeit at >> > much greater maintenance cost. >> > >> > Thanks, >> > >> > Jeff >> > >> > -- >> > Jeff Hammond >> > jeff.science(a)gmail.com >> >> >

1 0

Re: [mpich-devel] P states and MPI
by Bronis R. de Supinski 17 Jan '14

17 Jan '14

Um, I would say the Dell approach has no novelty and is rather rudimentary. We have done a lot more in Adagio: http://dl.acm.org/citation.cfm?id=1542340 @inproceedings{Rountree:2009:AMD:1542275.1542340, author = {Rountree, Barry and Lownenthal, David K. and de Supinski, Bronis R. and Schulz, Martin and Freeh, Vincent W. and Bletsch, Tyler}, title = {Adagio: Making DVS Practical for Complex HPC Applications}, booktitle = {Proceedings of the 23rd International Conference on Supercomputing}, series = {ICS '09}, year = {2009}, isbn = {978-1-60558-498-0}, location = {Yorktown Heights, NY, USA}, pages = {460--469}, numpages = {10}, url = {http://doi.acm.org/10.1145/1542275.1542340}, doi = {10.1145/1542275.1542340}, acmid = {1542340}, publisher = {ACM}, address = {New York, NY, USA}, keywords = {dvfs, dvs, energy, mpi, runtime}, } On Fri, 17 Jan 2014, William Gropp wrote: > There has been some work on this for parallel programs; Wu Feng at Virginia Tech has done some, for example. I don't recall seeing any work that used the profiling interface. Some of the issues raised, especially the required privs, mean that this is only available for experiments, not production, until that changes. Also, its sometimes possible to make predictions about wait times based on previous iterations; that could be used to refine such control. > > Bill > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Thomas M. Siebel Chair in Computer Science > University of Illinois Urbana-Champaign > > > > > On Jan 16, 2014, at 9:36 PM, Jeff Hammond wrote: > >> I was impressed by >> http://www.hpcadvisorycouncil.com/events/2013/Spain-Workshop/pdf/5_Dell.pdf >> / http://www.bsc.es/sites/default/files/public/mare_nostrum/2013hpcac-05.pdf. >> I wonder if anyone else has seen this, done anything similar, is >> interested in doing something similar, etc. I can imagine that a more >> integrated implementation has some performance advantages, albeit at >> much greater maintenance cost. >> >> Thanks, >> >> Jeff >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com > >

1 0

Re: [mpich-devel] P states and MPI
by William Gropp 17 Jan '14

17 Jan '14

There has been some work on this for parallel programs; Wu Feng at Virginia Tech has done some, for example. I don't recall seeing any work that used the profiling interface. Some of the issues raised, especially the required privs, mean that this is only available for experiments, not production, until that changes. Also, its sometimes possible to make predictions about wait times based on previous iterations; that could be used to refine such control. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Jan 16, 2014, at 9:36 PM, Jeff Hammond wrote: > I was impressed by > http://www.hpcadvisorycouncil.com/events/2013/Spain-Workshop/pdf/5_Dell.pdf > / http://www.bsc.es/sites/default/files/public/mare_nostrum/2013hpcac-05.pdf. > I wonder if anyone else has seen this, done anything similar, is > interested in doing something similar, etc. I can imagine that a more > integrated implementation has some performance advantages, albeit at > much greater maintenance cost. > > Thanks, > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com

1 0

P states and MPI
by Jeff Hammond 16 Jan '14

16 Jan '14

I was impressed by http://www.hpcadvisorycouncil.com/events/2013/Spain-Workshop/pdf/5_Dell.pdf / http://www.bsc.es/sites/default/files/public/mare_nostrum/2013hpcac-05.pdf. I wonder if anyone else has seen this, done anything similar, is interested in doing something similar, etc. I can imagine that a more integrated implementation has some performance advantages, albeit at much greater maintenance cost. Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com

1 0

Re: [mpich-devel] Weak symbols, clang, and users compiling with -fvisibility=hidden
by Kenneth Raffenetti 13 Jan '14

13 Jan '14

Hi Jed, Thanks for reporting this. I don't know the exact history of the configure tests, but my "fix" was to make the results consistent across our testing platforms. From your email, it appears there is larger issue we need to address in order to do what's intended. I'll create a new ticket. Ken On 01/08/2014 02:19 PM, "Antonio J. Peña" wrote: > > Let me discuss this with Ken. We'll get back to you. > > Antonio > > > On 01/06/2014 06:19 PM, Jed Brown wrote: >> Jed Brown <jedbrown(a)mcs.anl.gov> writes: >> >>> Pavan Balaji <balaji(a)mcs.anl.gov> writes: >>>> This attribute is tested in configure before it’s added to mpi.h.in. >>> Yes, the configure test is incorrect and the resulting usage in MPICH is >>> broken (does not do what you intend). >> As far as I know, >> >> #pragma weak MPI_Xyz = PMPI_Xyz >> >> is equivalent to what was intended with the attribute syntax >> >> __attribute__((weak, alias("PMPI_Xyz"))) >> >> (which belongs in an implementation file, not in the public header). Is >> there a reason to bother testing for the attribute syntax? > >

1 0