On Wed, 9 Aug 2017, Martin Sebor wrote: > the same function with the other of this pair attributes. I'd > also be okay with not diagnosing this combination if I could > convince myself that it's safe (or can be made safe) and treated > consistently.
I'd expect it to be safe; it might simply happen that some calls are optimized based on incomplete information (and even that is doubtful, as all optimizations except front-end folding should be taking place after all the declarations have been seen). > The problem whose subset the diagnostic detects is declaring > the function const and calling it before the pure declaration > that corresponds to its definition is seen. I.e., the inverse > of what the ssa-ccp-2.c test does. I think a mismatch between > the attributes is as suspect as a mismatch in the function's > signature. In the ssa-ccp-2.c case, it's not clear to me the test intends to use the same function at all; maybe one of the foo9 functions should be renamed. I think it's actually like having a non-prototype declaration and a prototype one, where a composite type is formed from two compatible types. (We have a warning in the very specific case of a non-prototype *definition* followed by a prototype declaration.) > In any event, it sounds to me that conceptually, it might be > useful to be able to specify which of a pair of mutually > exclusive (or redundant) attributes to retain and/or accept: > the first or the second, and not just whether to accept or > drop the most recent one. That will make it possible to make > the most appropriate decision about each specific pair of > attributes without impacting any of the others. If they conflict, I'm not sure there's any basis for making a choice specific to a particular pair of attributes. In cases like const and pure where one is a subset of the other, it makes sense to choose based on the pair of attributes - and not necessarily to warn under the same conditions as the warnings for conflicting attributes. -- Joseph S. Myers jos...@codesourcery.com
