On 08/09/2017 01:55 PM, Joseph Myers wrote: > 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). Right. With the caveat that there may be paths we're simply unaware of which might cause something to be handled earlier than expected. For example, interactions with nested functions, or with the backends squirreling away information via ENCODE_SECTION_INFO and the like. But in general, we should be seeing all the declarations before we start generating code.
> >> 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. Agreed. > > 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. In the subset case we could argue that there is a "winner" -- the set that allows us to generate the best code. Of course this assumes that the underlying semantics of the code match the given attributes. jeff
