On 27/09/2025 10:44, Alfie Richards wrote:
On 26/09/2025 21:26, Joseph Myers wrote:
Since this feature involves function name mangling, I'd like to
understand
how it interacts with other features affecting assembler names for
functions, and make sure there are associated testcases for those
interactions. Specifically:
* How does this interact with asm redirection for functions, if that's
used on any target_version or target_clones declaration or definition?
* How does this interact with the use of the simd attribute to map calls
made to a scalar function to vector variants of that function, if that
attribute (or similar OMP pragma) is used on a function also using one of
the new attributes?
Hi Joseph,
Thank you for the review.
It was previously decided to disallow asm with target_clones and
target_version. I will resubmit with that disallowed with an error and
some tests.
Hi Joseph and Marek (or anyone else knowledgeable in the C front-end),
I'm attempting to implement these diagnostics at the moment but I am
struggling to find an implementation.
The issue is for situations like:
```c
int fn(void) asm ("name");
int fn [[gnu::target_version("sve")]] (void) {
...
}
```
At the time of maybe_apply_renaming_pragma we have not processed
target_version so cannot emit an error.
At time of processing the target_version attribute, I cannot find a way
to detect the previous decl was renamed to diagnose.
I can imagine some intrusive work around's, such as adding a flag to the
decl to mark is as renamed. Do you have a preferred solution?
Thanks,
Alfie
I'll check if we want to specify that explicitly in the ACLE.
For OMP pragmas/SIMD attributes. I imagine we will want to disallow this
similarly. I would be open to adding later but I think it would need
further analysis thought as the behaviour seems non-obvious. Do you have
a strong thought on this?
Thanks,
Alfie
