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.
