On Tue, Apr 12, 2016 at 04:27:48PM -0400, Jason Merrill wrote:
> Unfortunately, a drawback of doing this in the front end is that it's
> difficult to warn only about affected cases; the front end doesn't know
> what's actually going to be emitted, and has to warn conservatively, leading
> to false positives particularly for inline functions.
>
> The third patch is a sketch of an attempt to address this by delaying the
> warning until expand time. We can't use front end information at this point
> because it has been thrown away by pass_ipa_free_lang_data, so I'm resorting
> to pre-generating the warning and stashing it away. This is several kinds of
> kludge, including hashing on a call location, but it greatly improves the
> accuracy of the warning. I'm hoping that someone will have a better idea
> about how to approach this.
Is the intent that we emit different warnings between e.g.
-fkeep-inline-functions vs. without that, or -O0 vs. -O2?
Do you want to warn just on the out of line definitions (visible outside of
the containing TU), or also calls to those?
For e.g. warning on calls to those functions it could be similar to the
warning attribute - where we warn if a call to function with that attribute
is expanded - if it is inlined or optimized away etc., we don't warn.
For warnings on the definitions, perhaps stick it into the IL (could be
internal fn, we have e.g. IFN_ANNOTATE that can hold some info, though right
now it is removed quite early). We'd need to remove it when inlining from
the IL, and decide what to do if such functions are e.g. cloned (SRA,
IPA-CP, ...).
Jakub
