Re: [PATCH] use attribute exclusion to reject naked vs target_clones conflicts (PR 84723)

[Martin Sebor <msebor@gmail.com>]

Since Jakub has committed an alternate patch that fixes
the ICE (below) this change is no longer necessary for GCC 8.
It still is in my view the right way to address the main part
of the problem so I will resubmit it for GCC 9 in stage 1.

https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00285.html

Martin

On 03/06/2018 10:19 PM, Martin Sebor wrote:
> PR 84723 is about an ICE caused by GCC accepting the mutually
> exclusive attributes target_clones and naked during parsing,
> only to then later crash while assuming such conflicts don't
> happen.
>
> The attached patch adds an exclusion for the two attributes
> to detect when they're both specified on declarations of the
> same function and avoid the ICE that way (there are other
> problems with target_clones that are unrelated to other
> interaction with other attributes).
>
> As this is the first instance of an exclusion between a pair
> of a front/middle-end and back-end attributes, testing the
> straightforward solution of just adding an exclusion for them
> exposed a restriction in the implementation that required more
> extensive changes to make things work.  The current (unpatched)
> code requires exclusions to be symmetric (e.g., when there is
> an exclusion entry for target_clones and naked, there must also
> be another exclusion entry the other way around).  This makes
> sense for attributes in the same table (e.g., all C/C++
> attributes, or all i386 back-end attributes) but not between
> attributes in different tables.  The patch makes additional
> changes to allow asymmetric exclusions without compromising
> the detection of attribute conflicts.  This additional
> enhancement allowed me to remove the self tests.
>
> Since I started working on this last night Jakub has already
> posted an alternate fix that doesn't make use of the exclusion
> framework (plus it fixes the additional bugs/ICEs I referred
> to above).  This patch is thus meant to apply on top of Jakub's
> (the tests will need tweaking to adjust the expected diagnostics).
> If my solution is considered too invasive at this stage I'm fine
> holding off on it and re-posting it in stage 1.  While working
> on it I noticed other opportunities for improvements in this
> area that I would like to make then.
>
> Martin