http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60906

--- Comment #3 from Harald van Dijk <harald at gigawatt dot nl> ---
Speaking only as a user, the behaviour I personally naïvely expected would be
to push the default function's attributes into each target-specific function's
attributes, and use the already existing rules for diagnosing conflicting
attributes. The dispatcher (ifunc) would take the attributes of the default
function.

Test cases:

void f1() __attribute__((target("default")));
void f1() __attribute__((target("arch=corei7"), noreturn));
// valid, but would apply noreturn attribute only to arch=corei7 declaration

void f2() __attribute__((target("default"), noreturn));
void f2() __attribute__((target("arch=corei7")));
// valid, would apply noreturn attribute to all three declarations

void f3() __attribute__((target("default"), regparm(3)));
void f3() __attribute__((target("arch=corei7")));
// valid, would apply regparm(3) attribute to all three declarations

void f4() __attribute__((target("default")));
void f4() __attribute__((target("arch=corei7"), regparm(3)));
// invalid

The f4 testcase would be analogous to

int f(int x);
int f(int x) __attribute__((regparm(3)));

which is already a compile-time error (in 32-bit mode).

Reply via email to