Page MenuHomePhabricator

[clang] Allow specifying the aapcs and aapcs-vfp for windows on arm
Needs ReviewPublic

Authored by mstorsjo on Jan 9 2021, 1:56 PM.

Details

Diff Detail

Event Timeline

mstorsjo created this revision.Jan 9 2021, 1:56 PM
mstorsjo requested review of this revision.Jan 9 2021, 1:56 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 9 2021, 1:56 PM

Can you please add some more context around the motivation for this change? It seems ... unnecessary as everything is already AAPCS/AAPCS-VFP.

Can you please add some more context around the motivation for this change? It seems ... unnecessary as everything is already AAPCS/AAPCS-VFP.

Yeah it's a redundant attribute, but I don't think we'd need to warn about it, but could accept it as well. Aapcs-vfp would be a no-op while plain aapcs would pass floats in gprs.

The reason for the patch is from wine; wine uses __attribute__((pcs("aapcs-vfp"))) (within an #ifdef __GNUC__) to get the right hardfloat calling convention when building for linux with a softfloat ABI (like e.g. the android userspace). If using those headers for targeting mingw, it triggers warnings with clang - and I didn't see why one shouldn't accept these attributes even on that target. I could try making wine stop using the redundant attribute when actully building code for a mingw target too, though.

I think that it makes more sense to ignore the aapcs-vfp calling convention attribute (returning CCCR_Ignore), and warn on the aapcs. The redundant calling convention attribute does nothing, and I think that simply ignoring it would solve your issue. However, changing the calling convention to aapcs would break interoperability, so warning on that seems reasonable still. I think that if Wine is willing to adjust their use of the attribute, that would really be nicer - it allows us to keep the behaviour as close to MSVC as possible.

rnk added a comment.Jan 13 2021, 6:28 PM

I don't see how supporting this attribute would break interop with MSVC. MSVC doesn't support these attributes, only GCC and Clang do. Presumably in the wine environment, some headers using these _GNUC extensions are being included somewhere, and IMO we should accept the attributes and honor them.