On Tue, Oct 16, 2012 at 8:52 AM, Derek Schuff <[email protected]> wrote: > Ping! > There are several bits that had to be touched, but the change is very > straightforward. > > On Thu, Oct 11, 2012 at 2:53 PM, Derek Schuff <[email protected]> wrote: >> Background: >> Because PNaCl bitcode must be target-independent, it uses some >> different bitcode representations from other targets (e.g. byval and >> sret for structures). This means that without additional type >> information, it cannot meet some native ABI requirements for some >> targets (e.g. passing structures containing unions by value on >> x86-64). To allow generation of code which uses the correct native >> ABIs, we also support triples such as x86_64-nacl, which uses >> target-dependent IR (as opposed to le32-nacl, which uses byval and >> sret). >> >> To allow interoperation between the two types of code, this patch adds >> a calling convention attribute to be used in code compiled with the >> target-dependent triple, which will generate code using the le32-style >> bitcode. This calling convention does not need to be explicitly >> supported in the backend because it determines bitcode representation >> rather than native conventions (the backend just needs to undersand >> how to handle byval and sret for the Native Client OS). >> >> This patch implements __attribute__((pnaclcall)) to generate calls in >> bitcode according to the le32 bitcode conventions, an attribute which >> is accepted by any Native Client target, but issues a warning >> otherwise. >> >> Please take a look, thanks. >> -Derek
+ // There appears to be no way to get the callingconv here, so just use + // the native version. FIXME: throw an early error if a function has + // pnaclcall attribute and varargs. CGF.CurFnInfo->getASTCallingConvention() ? I don't see any other issues. -Eli _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
