https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125838
Bug ID: 125838
Summary: aarch64: Implementation divergence in
vendor::preserve_none with variadic calls.
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
CC: alfierichards at gcc dot gnu.org, pinskia at gcc dot
gnu.org,
tnfchris at gcc dot gnu.org
Target Milestone: ---
Created attachment 64750
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=64750&action=edit
example code
I have been investigating cases where my Darwin aarch64 port has testsuite
fails; quite often I compare c.f. clang - since that sets the ABI for Darwin.
This lead to a discovery that we do things differently for variadic calls when
the callee is marked preserve_none (and so is the caller)
The attached code shows this - it is based on one of the suite test-cases - it
compiles with both GCC and clang (albeit with warnings about the noise
attribute on clang).
it needs -std=c23 .. and to be built without optimisation (I do not remember
how to disable IPO on clang).
Anyway .. the bottom line is that for a variadic case
- clang makes a regular variadic call to the function, passing values as
normal and the callee assumes it has a regular variadic call too.
- GCC makes the call as if the preserve_none registers are used, and does not
set up a stack frame on the callee side.
I'm not sure what the right solution is here .. since the callee cannot know
whether the caller is preserve_none or not we might end up with extra stack use
on the callee side - where the caller also effectively has to save a lot of
state too.
For the Darwin port .. I will have to do whatever clang does, since that sets
the system ABI .. but the Darwin variadic calls are also "different" in other
ways .. (for another day)
I tested trunk GCC and clang-21 on cfarm425 .. so the GCC was built locally but
the clang is the one installed as part of the provisioning.
