For as long as MPICH/MPICH2 has been developed, we have always tried to maintain the code as C89 compatible as possible. This is, in general, a good idea. However, this required us to add a lot of code to work with platforms and compilers that don't have C99 support. Given that C99 is almost a decade old now, and most compilers today support it, I'd like to initiate a discussion to see what people's thoughts are on requiring "C89++" support from the compiler for MPICH2. By C89++, I mean C89 together with a few features from C99. My initial list contains just two features with some reasoning: 1. snprintf -- this will allow us to totally get rid of MPIU_Snprintf given that it is not complete anyway, but only provides a handful of options. 2. __VA_ARGS__ -- this will allow us to remove the requirement to add FUNCNAME for each function we add and a lot of code that checks if VA_ARGS is defined before doing anything with it. If there are other C99 features that would be useful, please point them out as well. It goes without saying that the configure will of course still check if these exist. However, if they are not found, instead of trying to fall back to some other internal implementation, it'll abort. If you are against this approach, it'll be helpful if you can point out systems/compilers where it might be a problem. If you support this change, please do point that out as well. Thanks, -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji
I'm in favor of following the evolution of C compilers to C99, but only if we can ensure that C99 features are ubiquitous - we should not assume this is the case. I am particularly worried about the "most compilers today support it" - before making this change, we should undertake a real survey of systems, and that must include non-GNU systems and compilers, and it must include compilers in service, not just the current generation of compilers (we've often had users with compilers that were several years old). Among the list of compilers that we should include are those from the Portland Group, Intel, HP, IBM, Sun, Cray, NEC, Fujitsu, and Hitachi. And I'm sure I've forgotten a few. Bill On Oct 24, 2009, at 12:59 PM, Pavan Balaji wrote:
For as long as MPICH/MPICH2 has been developed, we have always tried to maintain the code as C89 compatible as possible. This is, in general, a good idea. However, this required us to add a lot of code to work with platforms and compilers that don't have C99 support. Given that C99 is almost a decade old now, and most compilers today support it, I'd like to initiate a discussion to see what people's thoughts are on requiring "C89++" support from the compiler for MPICH2.
By C89++, I mean C89 together with a few features from C99. My initial list contains just two features with some reasoning:
1. snprintf -- this will allow us to totally get rid of MPIU_Snprintf given that it is not complete anyway, but only provides a handful of options.
2. __VA_ARGS__ -- this will allow us to remove the requirement to add FUNCNAME for each function we add and a lot of code that checks if VA_ARGS is defined before doing anything with it.
If there are other C99 features that would be useful, please point them out as well. It goes without saying that the configure will of course still check if these exist. However, if they are not found, instead of trying to fall back to some other internal implementation, it'll abort.
If you are against this approach, it'll be helpful if you can point out systems/compilers where it might be a problem.
If you support this change, please do point that out as well.
Thanks,
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
I've added C99 support information for most of the compilers on our "Compiler Quirks" page: http://wiki.mcs.anl.gov/mpich2/index.php/Compiler_Quirks Does Fujitsu still have a compiler that is actually used for HPC situations? AFAICT they use the Sun Studio now for non-mainframe stuff. Does NEC still have a special compiler now that they've killed the SX line off? Do we know anything about the Hitachi compiler? There are a set of compilers that we should care about, and there are plenty that we shouldn't. Old and largely unused compilers don't need to be supported in future versions of MPICH2, they can always use an older MPICH2 version. We shouldn't allow old, low-end, and obscure systems to drag down our development. Please note that I'm not saying we should break these other compilers just for the sake of breaking them, but rather if there is a real value to be gained by assuming some reasonable level of compiler support then we should probably assume it. -Dave On Oct 25, 2009, at 1:51 PM, William Gropp wrote:
I'm in favor of following the evolution of C compilers to C99, but only if we can ensure that C99 features are ubiquitous - we should not assume this is the case. I am particularly worried about the "most compilers today support it" - before making this change, we should undertake a real survey of systems, and that must include non- GNU systems and compilers, and it must include compilers in service, not just the current generation of compilers (we've often had users with compilers that were several years old).
Among the list of compilers that we should include are those from the Portland Group, Intel, HP, IBM, Sun, Cray, NEC, Fujitsu, and Hitachi. And I'm sure I've forgotten a few.
Bill
On Oct 24, 2009, at 12:59 PM, Pavan Balaji wrote:
For as long as MPICH/MPICH2 has been developed, we have always tried to maintain the code as C89 compatible as possible. This is, in general, a good idea. However, this required us to add a lot of code to work with platforms and compilers that don't have C99 support. Given that C99 is almost a decade old now, and most compilers today support it, I'd like to initiate a discussion to see what people's thoughts are on requiring "C89++" support from the compiler for MPICH2.
By C89++, I mean C89 together with a few features from C99. My initial list contains just two features with some reasoning:
1. snprintf -- this will allow us to totally get rid of MPIU_Snprintf given that it is not complete anyway, but only provides a handful of options.
2. __VA_ARGS__ -- this will allow us to remove the requirement to add FUNCNAME for each function we add and a lot of code that checks if VA_ARGS is defined before doing anything with it.
If there are other C99 features that would be useful, please point them out as well. It goes without saying that the configure will of course still check if these exist. However, if they are not found, instead of trying to fall back to some other internal implementation, it'll abort.
If you are against this approach, it'll be helpful if you can point out systems/compilers where it might be a problem.
If you support this change, please do point that out as well.
Thanks,
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
On 10/25/2009 01:51 PM, William Gropp wrote:
Among the list of compilers that we should include are those from the Portland Group, Intel, HP, IBM, Sun, Cray, NEC, Fujitsu, and Hitachi. And I'm sure I've forgotten a few.
PGI, Intel, IBM, Sun, Cray (Pathscale) are OK. I'd vote for not worrying about the rest. That time is better spent on research. Votes? -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji
On Oct 28, 2009, at 1:28 PM, Pavan Balaji wrote:
On 10/25/2009 01:51 PM, William Gropp wrote:
Among the list of compilers that we should include are those from the Portland Group, Intel, HP, IBM, Sun, Cray, NEC, Fujitsu, and Hitachi. And I'm sure I've forgotten a few.
PGI, Intel, IBM, Sun, Cray (Pathscale) are OK. I'd vote for not worrying about the rest. That time is better spent on research.
Votes?
Sounds good to me. We don't have access to these other compilers, so it's difficult to even test for their quirks, let alone properly support them. -Dave
On Sat, Oct 24, 2009 at 12:59:43PM -0500, Pavan Balaji wrote:
I'd like to initiate a discussion to see what people's thoughts are on requiring "C89++" support from the compiler for MPICH2. ...
If there are other C99 features that would be useful, please point them out as well.
What about the "named member" syntax for structs? I might have the terminology wrong...the syntax where you can explicitly initialize each member of the struct. I know if I modify a struct by adding new members to the end I avoid a lot of headaches. I also know I've neglected to do this at least once :> ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA
1. snprintf -- this will allow us to totally get rid of MPIU_Snprintf given that it is not complete anyway, but only provides a handful of options.
I believe Windows doesn't have snprintf. There is an _snprintf, but they recommend using sprintf_s. Rajeev
However windows has the *snprintf functionality* . We should be ok there... -jayesh ----- Original Message ----- From: "Rajeev Thakur" <[email protected]> To: [email protected] Sent: Monday, October 26, 2009 1:22:00 PM GMT -06:00 US/Canada Central Subject: Re: [mpich2-core] C89++ for MPICH2
1. snprintf -- this will allow us to totally get rid of MPIU_Snprintf given that it is not complete anyway, but only provides a handful of options.
I believe Windows doesn't have snprintf. There is an _snprintf, but they recommend using sprintf_s. Rajeev
I just noticed that we have been using snprintf in mpd for a long time (since 2002, at least), and no one noticed any problem with it so far. That might give us some indication, at least about the snprintf part. -- Pavan On 10/24/2009 12:59 PM, Pavan Balaji wrote:
For as long as MPICH/MPICH2 has been developed, we have always tried to maintain the code as C89 compatible as possible. This is, in general, a good idea. However, this required us to add a lot of code to work with platforms and compilers that don't have C99 support. Given that C99 is almost a decade old now, and most compilers today support it, I'd like to initiate a discussion to see what people's thoughts are on requiring "C89++" support from the compiler for MPICH2.
By C89++, I mean C89 together with a few features from C99. My initial list contains just two features with some reasoning:
1. snprintf -- this will allow us to totally get rid of MPIU_Snprintf given that it is not complete anyway, but only provides a handful of options.
2. __VA_ARGS__ -- this will allow us to remove the requirement to add FUNCNAME for each function we add and a lot of code that checks if VA_ARGS is defined before doing anything with it.
If there are other C99 features that would be useful, please point them out as well. It goes without saying that the configure will of course still check if these exist. However, if they are not found, instead of trying to fall back to some other internal implementation, it'll abort.
If you are against this approach, it'll be helpful if you can point out systems/compilers where it might be a problem.
If you support this change, please do point that out as well.
Thanks,
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
How about making snprintf a requirement starting mpich2-1.3? The nightly tests already cover GNU, Intel, PGI, Sun, Absoft and (soon) Pathscale compilers. We can ask the Fujitsu guys whether it is supported for their compiler. We can also send out a note on mpich-discuss to make sure no one is using a compiler which doesn't support snprintf. -- Pavan On 11/24/2009 05:24 PM, Pavan Balaji wrote:
I just noticed that we have been using snprintf in mpd for a long time (since 2002, at least), and no one noticed any problem with it so far. That might give us some indication, at least about the snprintf part.
-- Pavan
On 10/24/2009 12:59 PM, Pavan Balaji wrote:
For as long as MPICH/MPICH2 has been developed, we have always tried to maintain the code as C89 compatible as possible. This is, in general, a good idea. However, this required us to add a lot of code to work with platforms and compilers that don't have C99 support. Given that C99 is almost a decade old now, and most compilers today support it, I'd like to initiate a discussion to see what people's thoughts are on requiring "C89++" support from the compiler for MPICH2.
By C89++, I mean C89 together with a few features from C99. My initial list contains just two features with some reasoning:
1. snprintf -- this will allow us to totally get rid of MPIU_Snprintf given that it is not complete anyway, but only provides a handful of options.
2. __VA_ARGS__ -- this will allow us to remove the requirement to add FUNCNAME for each function we add and a lot of code that checks if VA_ARGS is defined before doing anything with it.
If there are other C99 features that would be useful, please point them out as well. It goes without saying that the configure will of course still check if these exist. However, if they are not found, instead of trying to fall back to some other internal implementation, it'll abort.
If you are against this approach, it'll be helpful if you can point out systems/compilers where it might be a problem.
If you support this change, please do point that out as well.
Thanks,
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
participants (6)
-
Dave Goodell -
Jayesh Krishna -
Pavan Balaji -
Rajeev Thakur -
Rob Latham -
William Gropp