From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 0AC6B385800F; Thu, 18 Nov 2021 18:01:23 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0AC6B385800F
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/101180] [12 Regression] Rejected code since
 r12-299-ga0fdff3cf33f7284
Date: Thu, 18 Nov 2021 18:01:22 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-101180-4-Sb85oyp8UH@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-101180-4@http.gcc.gnu.org/bugzilla/>
References: <bug-101180-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Nov 2021 18:01:23 -0000

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

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 t=
hey
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 =3D {}, b =3D {};
  __m256 c =3D _mm256_and_ps (a, b);
  unsigned int d =3D 1;
  d =3D __crc32b (d, 0x55);
}
can work properly (it doesn't).

For the former issue, perhaps apply_late_template_attributes could temporar=
ily
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.=