[PATCH] Add module flags metadata to record the settings for enum and wchar width

Oliver Stannard oliver.stannard at arm.com
Fri Jun 20 02:11:14 PDT 2014


> wchar_t is unsigned long on any ARM environment strictly following AAPCS. Windows on ARM does not strictly follow AAPCS (it is pretty close though), and uses an unsigned short for wchar_t.

The AAPCS allows wchar_t to be unsigned int or unsigned short, with the choice left up to the platform ABI [1, 7.1.1]. Windows on ARM defines wchar_t to be unsigned short [2, C/C++ Specifics], which is allowed by the AAPCS.

> Enums are a bit more tricky, with them defaulting to short, but extending to long if any of the elements of the enumeration exceed the limits of short.

I think we are getting our terminology mixed up. The two variants permitted by the AAPCS are [1, 7.1.3]:
* An enumerated type normally occupies a word (int or unsigned int). If a word cannot represent all of its enumerated values the type occupies a double word (long long or unsigned long long). This corresponds to clang's -fno-short-enums.
* The type of the storage container for an enumerated type is the smallest integer type that can contain all of its enumerated values. This corresponds to clang's -fshort-enums, which is the default.

According to the C standard (I only checked C99), the enum type is implementation defined [3, 6.7.2.2.4], but it looks like clang implements it as above for all targets (Sema::ActOnEnumBody, currently line 13014-13107).

> That said, would you be opposed to using an enumeration for the values of this metadata Oliver?

With the current patch, the backend needs to know what the frontend is doing when using long/short wchar/enums. Perhaps it would be better to store the size of wchar_t and the minimum size of an enum? This should avoid the need to duplicate this target- and language-specific knowledge.


> Even though we "assumed" that was true, we didn't have the attributes in place, if the default was different, say v4 from v7, than you'll get weird results.

If the default was different, the code will have been compiled with different assumptions about wchar_t and enum size, so we want the build attributes to prevent the user from linking these two objects together.

> I think a better approach is to *just* emit the metadata is the flag exists.

With the current backend implementation, if there is no metadata the build attribute will not be emitted, and the default build attribute is that enums/wchars were not used as this is the only safe default. If the backend were to work out the default, this would duplicate the logic for selecting the default, and if we get it wrong the build attributes will not match the code.



# http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf
# http://msdn.microsoft.com/en-us/library/dn736986.aspx
# C99 draft with TC1-3

http://reviews.llvm.org/D4212






More information about the cfe-commits mailing list