g95 and FFTW
in [Fortran]
|
From: glen herrmannsfeldt on 25 Apr 2010 02:25 Louis Krupp <lkrupp_nospam(a)indra.com.invalid> wrote: <snip> > My personal opinion is that it's a good idea to get rid of the warnings > if it's at all practical. At my current place of employment, warnings > in C and C++ (people laugh at me when I mention Fortran, while I read > this group out of interest) are treated as errors which have to be > fixed. That sounds good, but they keep adding new ones, some of which apply to things that are reasonable to do. Variables that are declared but not used, or set but never referenced again, maybe for future use, or otherwise currently not needed. > I think it's a good thing; if only because it's nice not to > have to wade through a bunch of messages about harmless issues in order > to find warnings that might actually flag real problems. This may or > may not apply to Fortran and its current compilers. Or use grep to remove the ones you don't want to see. -- glen
From: J. Clarke on 25 Apr 2010 08:16 On 4/25/2010 2:25 AM, glen herrmannsfeldt wrote: > Louis Krupp<lkrupp_nospam(a)indra.com.invalid> wrote: > <snip> > >> My personal opinion is that it's a good idea to get rid of the warnings >> if it's at all practical. At my current place of employment, warnings >> in C and C++ (people laugh at me when I mention Fortran, while I read >> this group out of interest) are treated as errors which have to be >> fixed. > > That sounds good, but they keep adding new ones, some of which > apply to things that are reasonable to do. Variables that are > declared but not used, or set but never referenced again, maybe > for future use, or otherwise currently not needed. > >> I think it's a good thing; if only because it's nice not to >> have to wade through a bunch of messages about harmless issues in order >> to find warnings that might actually flag real problems. This may or >> may not apply to Fortran and its current compilers. > > Or use grep to remove the ones you don't want to see. If their policy is no warnings, God help then when they try to use the gnu toolchain.
From: Richard Maine on 25 Apr 2010 14:41 Louis Krupp <lkrupp_nospam(a)indra.com.invalid> wrote: > My personal opinion is that it's a good idea to get rid of the warnings > if it's at all practical. I agree. But I caution against taking it too far as an absolute. Your "good idea" and "practical" reasonably describe it I would think. Going to far in that direction can have negative consequences. In particular, I have seen (fairly often) people propose changing code that is perfectly standard conforming and robust into code that violates the standard and might well fail in some cases - just because the good code generates a warning and the problematic code does not. Perhaps the most common cases of that come from trying to avoid warnings about dummy arguments not being used. There can be perfectly valid reasons to have dummy arguments that are not used. (I have lots of them in my codes, often in procedures provided as hooks for user modification, where the default routine does nothing). Attempts to work around the warning messages often do things like reference variables that might not be defined or even present (in the sense of the PRESENT intrinsic). As a result of things like this, I'm a fairly big fan of compiler options to suppress warnings for particular errors. Note the word "particular". Most (all?) compilers have an option to turn off all warning messages, but that throws out the good with the bad. I like to have the fine-grained control of being able to disable warnings by the message number. Some compilers have a handful of particular warnings that you can disable, but very few these days seem to have the capability of disabling any warning message, which you would pretty much have to do by a message number. My preferred mode of operation is often to review the warnings, decide whether to change the code or accept that it reasonably and validly uses the feature in question. In the later case, I like to be able to disable the warning. Back to the OP's case. Note that most of the tricks that one can use to avoid the warning messages for his case don't actually make the code any more standard conforming or robust. They just hide the problem from the compiler.... at least until you maybe find a "smarter" compiler some day. His code would almost certainly work correctly anyway, and if you did manage to find some strange situation in which the code wouldn't work correctly, the versions that hide the problem from the compiler would probably also fail. You have taken something that is simple and robust, but generates a warning message, and turned it into something that doesn't generate a warning message from the compiler but is likely to leave the human reader wondering what is behind the apparently pointless complication. I would generally take the simpler version and possibly disable the warning message, documenting why I had done so. That particular warning message is one that some compilers do allow disabling; for the nag compiler, I think the option is something like -mismatch_all. Now methods that actually make the code standard conforming strike me as worth a bit more in that they protect you against the possibility that you might later run into a compiler that actually enforces that aspect of the standard. I have had things like that happen to me in the past. Making this case standard conforming is probably tricky (except when static storage is used, in which case equivalence can do it). -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Arjen Markus on 28 Apr 2010 09:43
On 25 apr, 20:41, nos...(a)see.signature (Richard Maine) wrote: > Louis Krupp <lkrupp_nos...(a)indra.com.invalid> wrote: > > My personal opinion is that it's a good idea to get rid of the warnings > > if it's at all practical. > > I agree. But I caution against taking it too far as an absolute. Your > "good idea" and "practical" reasonably describe it I would think. Going > to far in that direction can have negative consequences. > > In particular, I have seen (fairly often) people propose changing code > that is perfectly standard conforming and robust into code that violates > the standard and might well fail in some cases - just because the good > code generates a warning and the problematic code does not. > > Perhaps the most common cases of that come from trying to avoid warnings > about dummy arguments not being used. There can be perfectly valid > reasons to have dummy arguments that are not used. (I have lots of them > in my codes, often in procedures provided as hooks for user > modification, where the default routine does nothing). Attempts to work > around the warning messages often do things like reference variables > that might not be defined or even present (in the sense of the PRESENT > intrinsic). > > As a result of things like this, I'm a fairly big fan of compiler > options to suppress warnings for particular errors. Note the word > "particular". Most (all?) compilers have an option to turn off all > warning messages, but that throws out the good with the bad. I like to > have the fine-grained control of being able to disable warnings by the > message number. Some compilers have a handful of particular warnings > that you can disable, but very few these days seem to have the > capability of disabling any warning message, which you would pretty much > have to do by a message number. > > My preferred mode of operation is often to review the warnings, decide > whether to change the code or accept that it reasonably and validly uses > the feature in question. In the later case, I like to be able to disable > the warning. > > Back to the OP's case. Note that most of the tricks that one can use to > avoid the warning messages for his case don't actually make the code any > more standard conforming or robust. They just hide the problem from the > compiler.... at least until you maybe find a "smarter" compiler some > day. His code would almost certainly work correctly anyway, and if you > did manage to find some strange situation in which the code wouldn't > work correctly, the versions that hide the problem from the compiler > would probably also fail. You have taken something that is simple and > robust, but generates a warning message, and turned it into something > that doesn't generate a warning message from the compiler but is likely > to leave the human reader wondering what is behind the apparently > pointless complication. I would generally take the simpler version and > possibly disable the warning message, documenting why I had done so. > That particular warning message is one that some compilers do allow > disabling; for the nag compiler, I think the option is something like > -mismatch_all. > > Now methods that actually make the code standard conforming strike me as > worth a bit more in that they protect you against the possibility that > you might later run into a compiler that actually enforces that aspect > of the standard. I have had things like that happen to me in the past. > Making this case standard conforming is probably tricky (except when > static storage is used, in which case equivalence can do it). > > -- > Richard Maine | Good judgment comes from experience; > email: last name at domain . net | experience comes from bad judgment. > domain: summertriangle | -- Mark Twain If I understand FFTW correctly, the data type from some of its arguments is taken from the flag that is passed. The Fortran 90 interface could take advantage of that, with a bit of C code. Regards, Arjen |