llvm-svn: 63138

Also changed FunctionTypeProto to be allocated with 8-byte alignment (noticed by Doug). I couldn't think of any reason to allocate on 16-byte boundaries. If anyone remembers why we were doing this, let me know!

llvm-svn: 63137

llvm-svn: 63136

Remove many references to ASTContext::getAllocator(), replacing them with calls to the recently added placement new (which uses ASTContext's allocator for memory). Also added ASTContext::Deallocate().

This will simplify runtime replacement of ASTContext's allocator. Keeping the allocator private (and removing getAllocator() entirely) is also goodness.

llvm-svn: 63135

llvm-svn: 63132

doesn't set the relocation model when -mdynamic-no-pic is present.

llvm-svn: 63129

a uint64_t to verify that the value is in range for the given type,
to help catch accidental overflow. Fix a few places that relied on
getConstant implicitly truncating the value.

llvm-svn: 63128

If an input constraint refers to an output constraint, it should have the same constraint info as the output constraint. Fixes PR3417

llvm-svn: 63127

Still more work to do in this area.

llvm-svn: 63126

machine as x86_64.

llvm-svn: 63122

llvm-svn: 63121

llvm-svn: 63120

llvm-svn: 63119

instead of via a by-reference argument. No functionality change.

llvm-svn: 63118

llvm-svn: 63117

llvm-svn: 63116

llvm-svn: 63113

llvm-svn: 63112

.def file for each library.  This means that adding a diagnostic
to sema doesn't require all the other libraries to be rebuilt.

Patch by Anders Johnsen!

llvm-svn: 63111

Fix bug in BasicStore::getLValueElement where if the base of an array subscript expression was an ElementRegion we stacked another ElementRegion on top of that.

This fixes PR 3422.

llvm-svn: 63110

of a type.  The implementation is currently something of a hack, but is 
sufficient for now and allows clients to be built on it.

llvm-svn: 63108

causing assertion failures in getSExtValue().
Fix it by making highWordBits actually contain what its name says,
and add some more unit-tests for APInt.
This fixes PR3419.

llvm-svn: 63107

llvm-svn: 63104

llvm-svn: 63101

__extension__.  This sort of construct shows up in the gcc source code.

llvm-svn: 63100

as reported to the user and as manipulated by #line.  This is what __FILE__,
__INCLUDE_LEVEL__, diagnostics and other things should follow (but not 
dependency generation!).  

This patch also includes several cleanups along the way: 

- SourceLocation now has a dump method, and several other places 
  that did similar things now use it.
- I cleaned up some code in AnalysisConsumer, but it should probably be
  simplified further now that NamedDecl is better.
- TextDiagnosticPrinter is now simplified and cleaned up a bit.

This patch is a prerequisite for #line, but does not actually provide 
any #line functionality.

llvm-svn: 63098

llvm-svn: 63097

llvm-svn: 63095

llvm-svn: 63094

address space we used up.  Some interesting data:

For c99-intconst-1.c:
6912762 SLocEntry's allocated, 25592386B of Sloc address space used.

For cocoa.h:
26469 SLocEntry's allocated, 10278752B of Sloc address space used.

For carbon.h:
27364 SLocEntry's allocated, 12398141B of Sloc address space used.

Clearly 2G of sloc address space should be enough for anyone?!

llvm-svn: 63093

llvm-svn: 63092

llvm-svn: 63091

llvm-svn: 63090

llvm-svn: 63089

llvm-svn: 63088

 - gcc appears to be classifying <1 x double> as INTEGER which is
   odd. Will investigate later.

llvm-svn: 63086

llvm-svn: 63085

- Add the distinction between the 'bug type' and the 'bug description'

HTMLDiagnostics:
- Output the bug type field as HTML comments

scan-build:
- Use the bug type field instead of the bug description for the HTML table.
- Radar filing now automatically picks up the bug description in the title (addresses <rdar://problem/6265970>)

llvm-svn: 63084

 - Code quality is poor, but simple.

llvm-svn: 63083

llvm-svn: 63080