[Bug c++/101180] New: [12 Regression] Rejected code since r12-299-ga0fdff3cf33f7284

[Bug c++/101180] New: [12 Regression] Rejected code since r12-299-ga0fdff3cf33f7284

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101180

            Bug ID: 101180
           Summary: [12 Regression] Rejected code since
                    r12-299-ga0fdff3cf33f7284
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: jason at gcc dot gnu.org
  Target Milestone: ---

The code is reduced from Skia (part of chromium package):

$ cat enc.ii
#pragma GCC target "avx"
template <typename> struct Simd {};
#pragma GCC push_options
#pragma GCC target "avx,avx2,bmi,bmi2,fma,f16c"
template <typename T> using Full256 = Simd<T>;
template <typename> struct BitCastFromInteger256;
template <> struct BitCastFromInteger256<float> {
  __attribute__((always_inline)) float operator()(long) { return .0f; }
};
long BitCastFromByte_v_0;
template <typename T> void BitCastFromByte(Full256<T>) {
  T{BitCastFromInteger256<T>()(BitCastFromByte_v_0)};
}
template <typename T, typename FromT> void BitCast(T d, FromT) {
  BitCastFromByte(d);
}
int EstimateEntropy___trans_tmp_3;
void EstimateEntropy() {
  Simd<float> df;
  BitCast(df, EstimateEntropy___trans_tmp_3);
}
#pragma GCC pop_options

$ g++ enc.ii -c 
enc.ii: In function ‘void BitCastFromByte(Full256<T>) [with T = float]’:
enc.ii:8:40: error: inlining failed in call to ‘always_inline’ ‘float
BitCastFromInteger256<float>::operator()(long int)’: target specific option
mismatch
    8 |   __attribute__((always_inline)) float operator()(long) { return .0f; }
      |                                        ^~~~~~~~
enc.ii:12:31: note: called from here
   12 |   T{BitCastFromInteger256<T>()(BitCastFromByte_v_0)};
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~

[Bug c++/101180] [12 Regression] Rejected code since r12-299-ga0fdff3cf33f7284

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101180

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-06-23
      Known to work|                            |11.1.0
   Target Milestone|---                         |12.0
      Known to fail|                            |12.0
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

[Bug c++/101180] [12 Regression] Rejected code since r12-299-ga0fdff3cf33f7284

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101180

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think when instantiating templates we shouldn't be adding attributes from
current_optimize_pragma, optimization_current_node or current_target_pragma.
It shouldn't really matter where we instantiate the code from, but where it is
declared.
E.g. given
#pragma GCC push_options
#pragma GCC target "avx"
template <int N>
inline void foo ()
{
}
#pragma GCC pop_options
#pragma GCC push_options
#pragma GCC target "avx2"
void
bar ()
{
  foo<0> ();
}
#pragma GCC pop_options
both GCC 10 and 11 emit:
__attribute__((target ("avx2")))
void bar ()
{
  foo<0> ();
}


__attribute__((target ("avx")))
void foo<0> ()
{
  GIMPLE_NOP
}
but GCC 12 emits:
__attribute__((target ("avx2")))
void bar ()
{
  foo<0> ();
}


__attribute__((target ("avx2"), target ("avx")))
void foo<0> ()
{
  GIMPLE_NOP
}

Another thing is if optimize/target attributes can be ever dependent.  If they
can, I think we have another problem because clearly
ix86_valid_target_attribute_p starts from TREE_TARGET_OPTION
(target_option_default_node) rather than from DECL_FUNCTION_SPECIFIC_TARGET
(fndecl).  I think it should start from the latter if fndecl and
DECL_FUNCTION_SPECIFIC_TARGET is non-NULL (similarly for other targets),
otherwise I really don't understand how
#include <x86intrin.h>

__attribute__((target ("avx"))) __attribute__((target ("crc32"))) void
foo ()
{
  __m256 a = {}, b = {};
  __m256 c = _mm256_and_ps (a, b);
  unsigned int d = 1;
  d = __crc32b (d, 0x55);
}
can work properly (it doesn't).

For the former issue, perhaps apply_late_template_attributes could temporarily
override current_optimize_pragma, optimization_current_node and
current_target_pragma around the cplus_decl_attributes call in there.
Also scope_chain->omp_declare_target_attribute.

Note, I think older GCCs suffered from this bug too, but before
r12-299-ga0fdff3cf33f7284 we didn't call cplus_decl_attributes at least when
there wasn't any dependent attribute.  But I guess it should be easy to add
some unrelated dependent attribute to trigger it before.

[Bug c++/101180] [12 Regression] Rejected code since r12-299-ga0fdff3cf33f7284

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101180

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 51833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51833&action=edit
gcc12-pr101180.patch

Untested patch for the first issue.

[Bug c++/101180] [12 Regression] Rejected code since r12-299-ga0fdff3cf33f7284

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101180

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:b751b225e4f02cf0c446e659e7c3e204096468bf

commit r12-5426-gb751b225e4f02cf0c446e659e7c3e204096468bf
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Nov 19 22:09:01 2021 +0100

    c++: Avoid adding implicit attributes during apply_late_template_attributes
[PR101180]

    decl_attributes and its caller cplus_decl_attributes sometimes add
    implicit attributes, e.g. optimize attribute if #pragma GCC optimize
    is active, target attribute if #pragma GCC target is active, or
    e.g. omp declare target attribute if in between #pragma omp declare target
    and #pragma omp end declare target.

    For templates that seems highly undesirable to me though, they should
    get those implicit attributes from the spot the templates were parsed
    (and they do get that), then tsubst through copy_node copies those
    attributes, but then apply_late_template_attributes can or does add
    a new set from the spot where they are instantiated, which can be pretty
    random point of first use of the template.

    Consider e.g.
     #pragma GCC push_options
     #pragma GCC target "avx"
     template <int N>
     inline void foo ()
     {
     }
     #pragma GCC pop_options
     #pragma GCC push_options
     #pragma GCC target "crc32"
     void
     bar ()
     {
       foo<0> ();
     }
     #pragma GCC pop_options
    testcase where the intention is that foo has avx target attribute
    and bar has crc32 target attribute, but we end up with
    __attribute__((target ("crc32"), target ("avx")))
    on foo<0> (and due to yet another bug actually don't enable avx
    in foo<0>).  In this particular case it is a regression caused
    by r12-299-ga0fdff3cf33f7284 which apparently calls
    cplus_decl_attributes even if attributes != NULL but late_attrs
    is NULL, before those changes we didn't call it in those cases.
    But, if there is at least one unrelated dependent attribute this
    would happen already in older releases.

    The following patch fixes that by temporarily overriding the variables
    that control the addition of the implicit attributes.

    Shall we also change the function so that it doesn't call
    cplus_decl_attributes if late_attrs is NULL, or was that change
    intentional?

    2021-11-19  Jakub Jelinek  <jakub@redhat.com>

            PR c++/101180
            * pt.c (apply_late_template_attributes): Temporarily override
            current_optimize_pragma, optimization_current_node,
            current_target_pragma and
scope_chain->omp_declare_target_attribute,
            so that cplus_decl_attributes doesn't add implicit attributes.

            * g++.target/i386/pr101180.C: New test.

[Bug c++/101180] [12 Regression] Rejected code since r12-299-ga0fdff3cf33f7284

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101180

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:364539710f828851b9fac51c39033cd09aa620de

commit r12-5441-g364539710f828851b9fac51c39033cd09aa620de
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sun Nov 21 21:06:23 2021 +0100

    i386: Fix up handling of target attribute [PR101180]

    As shown in the testcase below, if a function has multiple target
attributes
    (rather than a single one with one or more arguments) or if a function
    gets one target attribute on one declaration and another one on another
    declaration, on x86 their effect is not combined into
    DECL_FUNCTION_SPECIFIC_TARGET, but instead only the last processed target
    attribute wins.  aarch64 handles this right, the following patch follows
    what it does, i.e. only start with target_option_default_node if
    DECL_FUNCTION_SPECIFIC_TARGET is previously NULL (i.e. the first target
    attribute being processed on a function) and otherwise start from the
    previous DECL_FUNCTION_SPECIFIC_TARGET.

    2021-11-21  Jakub Jelinek  <jakub@redhat.com>

            PR c++/101180
            * config/i386/i386-options.c (ix86_valid_target_attribute_p): If
            fndecl already has DECL_FUNCTION_SPECIFIC_TARGET, use that as base
            instead of target_option_default_node.

            * gcc.target/i386/pr101180.c: New test.

[Bug c++/101180] [12 Regression] Rejected code since r12-299-ga0fdff3cf33f7284

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101180

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

[Bug c++/101180] [12 Regression] Rejected code since r12-299-ga0fdff3cf33f7284

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101180

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:8e86218f05c1a866b43ae5af3e303f91fb6d7ff0

commit r12-5511-g8e86218f05c1a866b43ae5af3e303f91fb6d7ff0
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Nov 25 08:39:35 2021 +0100

    c++: Return early in apply_late_template_attributes if there are no late
attribs [PR101180]

    The r12-299-ga0fdff3cf33f7284 change can result in cplus_decl_attributes
being called
    even if there are no late attributes (but at least one early attribute) in
    apply_late_template_attributes.  This patch fixes that, so that we return
early
    if there are no late attrs, only arrange for TYPE_ATTRIBUTES to get the
early
    attribute list.

    2021-11-25  Jakub Jelinek  <jakub@redhat.com>

            PR c++/101180
            * pt.c (apply_late_template_attributes): Return early if there are
no
            dependent attributes.