https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |rejects-valid
Target|hurd freebsd |*-aix7.1 hurd freebsd
Status|ASSIGNED |NEW
--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
I can reproduce the error with an rs6000-aix7.1 cross:
$ cat pr93419.c && /build/rs6000-aix7.1/gcc-trunk/gcc/xgcc -B
/build/rs6000-aix7.1/gcc-trunk/gcc pr93419.c
#if __has_attribute (ifunc)
typedef void (fntype)(void);
fntype* fn_select (void) { return 0; }
void fn(void) __attribute__((ifunc ("fn_select")));
#endif
pr93419.c:5:6: error: 'ifunc' is not supported on this target
5 | void fn(void) __attribute__((ifunc ("fn_select")));
| ^~
It is issued in varasm.c under one of two conditions:
if (TREE_CODE (decl) == FUNCTION_DECL
&& cgraph_node::get (decl)->ifunc_resolver)
{
#if defined (ASM_OUTPUT_TYPE_DIRECTIVE)
if (targetm.has_ifunc_p ())
ASM_OUTPUT_TYPE_DIRECTIVE
(asm_out_file, IDENTIFIER_POINTER (id),
IFUNC_ASM_TYPE);
else
#endif
error_at (DECL_SOURCE_LOCATION (decl),
"%qs is not supported on this target", "ifunc");
}
Neither of these seems to be considered by the operator (in fact, it looks like
the only thing the handler does consider is the whether the attribute is
defined for the target), so confirmed as a bug. It seems that the conditions
in varasm.c (and anywhere else in the compiler) that determine whether or not
an attribute is supported should be abstracted into an API and tested by the
builtin handler during preprocessing as well as by later stages.
