llvm-svn: 166073

target options around so they can be accessed at any point (rather
than keeping them transient).

llvm-svn: 166072

explicitly specified iff it was specified in the declaration.

llvm-svn: 166071

This is consistent/interoperable with GCC 4.7 (& __cxa_deleted_function isn't
present in 4.4 - not sure when it got added, but you'll need something with
that function available for this to work).

llvm-svn: 166069

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.

llvm-svn: 166065

front-end and the AsmParser.  No functional change intended.

llvm-svn: 166063

llvm-svn: 166056

We generalize r166040 to handle ABI alignment issues for all types.

rdar://12439123

llvm-svn: 166052

@implementation.

llvm-svn: 166047

We expand varargs in clang and the call site is handled in the back end, it is
hard to match exactly how illegal vectors are handled in the backend. Therefore,
we legalize the illegal vector types in clang:
if (Size <= 32), legalize to i32.
if (Size == 64), legalize to v2i32.
if (Size == 128), legalize to v4i32.
if (Size > 128), use indirect.

rdar://12439123

llvm-svn: 166043

We create an aligned temporary space and copy the content over from ap.cur to
the temporary space. This is necessary if the natural alignment of the type is
greater than the ABI alignment.

rdar://12439123

llvm-svn: 166040

This implementation doesn't warn on anything that GCC doesn't warn on with the
exception of templates specializations (GCC doesn't warn, Clang does). The
specific skipped cases (boolean, constant expressions, enums) are open for
debate/adjustment if anyone wants to demonstrate that GCC is being overly
conservative here. The only really obvious false positive I found was in the
Clang regression suite's MPI test - apparently MPI uses specific flag values in
pointer constants. (eg: #define FOO (void*)~0)

llvm-svn: 166039

don't try the normal GetOrCreateLLVM. The latter could drop the weak
atrtibute on the second reference, if there is no explicit declaration
of the aliasee.

llvm-svn: 166032

// rdar://12491143

llvm-svn: 166030

hopelessly poorly written code after spewing several
errors. // rdar://12491143

llvm-svn: 166025

metadata.

llvm-svn: 166023

  if (CGM.getModuleDebugInfo())
    DebugInfo = CGM.getModuleDebugInfo()
into a call:
  maybeInitializeDebugInfo();

This is a simplification for a possible future fix of PR13942.

llvm-svn: 166019

Use the Attributes::get method which takes an AttrVal value directly to simplify the code a bit. No functionality change.

llvm-svn: 166010

Follow-up to r165838, which fixed a potential crash.

llvm-svn: 166002

llvm-svn: 165994

llvm-svn: 165993

llvm-svn: 165992

llvm-svn: 165988

llvm-svn: 165977

llvm-svn: 165976

llvm-svn: 165975

llvm-svn: 165974

of their own.

llvm-svn: 165972

See PR14013.

llvm-svn: 165962

Move the Attributes::Builder outside of the Attributes class and into its own class named AttrBuilder. No functionality change.

llvm-svn: 165961

-The front-end now builds a single assembly string and feeds it to the
 AsmParser.  The front-end iterates on a per statement basis by calling the
 ParseStatement() function.  Please note, the calling of ParseStatement() and
 and any notion of MCAsmParsedOperands will be sunk into the MC layer in the
 near future.  I plan to expose more basic APIs such as getClobbers, etc.

-The enumeration of the AsmString expressions have been reworked to use SMLocs
 rather than assembly Pieces, which were being parsed in the front-end.

-The test case, t8(), was modified due to r129223.  I'll have to find a way to
 work around things such as these.

Sorry for the large commit, but breaking this in multiple smaller commits proved
too irritating.

llvm-svn: 165957

template when comment is comming from overridden declaration. 
// rdar://12378793

llvm-svn: 165953

created.

llvm-svn: 165943

[asan] make AddressSanitizer to be a FunctionPass instead of ModulePass. clang part: for FunctionPass we need to run asan at a different point, otherwise it will run before inlining

llvm-svn: 165937

Review: http://llvm-reviews.chandlerc.com/D62
llvm-svn: 165933

llvm-svn: 165925

description. Previously, one could emulate this behavior by placing
the header in an always-unavailable submodule, but Argyrios guilted me
into expressing this idea properly.

llvm-svn: 165921

Convert the uses of the Attributes class over to the new format. The
Attributes::get method call now takes an LLVM context so that the attributes
object can be uniquified and stored.

llvm-svn: 165918

fails to return a value, to make debugging this issue easier.

llvm-svn: 165914

llvm-svn: 165911