Export the APIs submitted by Dawn to the Python bindings.  Add a simple test case for the SBModule.compile_unit_iter() API.

llvm-svn: 152952

store to 1. This allows code-gen to select a more appropriate alignment. If left
to zero, an alignment greater than the alignment of the pointer may be selected,
causing code-gen to use instructions which require an alignment greater than the
pointer guarantees.
<rdar://problem/11043589>

llvm-svn: 152951

llvm-svn: 152950

// rdar://11063663

llvm-svn: 152949

llvm-svn: 152948

llvm-svn: 152946

llvm-svn: 152945

It's not a good style idea, as the registers will be laid down in memory in
numerical order, not the order they're in the list, but it's legal. vldm/vstm
are stricter.

rdar://11064740

llvm-svn: 152943

GetSupportFileAtIndex(), GetNumSupportFiles(), FindSupportFileIndex():
   Add API support for getting the list of files in a compilation unit.
GetNumCompileUnits(), GetCompileUnitAtIndex():
   Add API support for retrieving the compilation units in a module.

llvm-svn: 152942

llvm-svn: 152941

For "int i = NULL;" we would produce:

null.cpp:5:11: warning: implicit conversion of NULL constant to integer [-Wconversion]
  int i = NULL;
      ~   ^~~~
null.cpp:1:14: note: expanded from macro 'NULL'
\#define NULL __null
              ^~~~~~

But we really shouldn't trace that macro expansion back into the header, yet we
still want macro back traces for code like this:

\#define FOO NULL
int i = FOO;

or

\#define FOO int i = NULL;
FOO

While providing appropriate tagging at different levels of the expansion, etc.

The included test case exercises these cases & does some basic validation (to
ensure we don't have macro expansion notes where we shouldn't, and do where we
should) - but doesn't go as far as to validate the source location/ranges
used in those notes and warnings.

llvm-svn: 152940

llvm-svn: 152939

This fixes g++.dg/parse/friend5.C.

llvm-svn: 152938

After r150615, which tablegens the group of a diagnostic as an index into the *.inc file, all diagnostic *.inc
files depend on all other diagnostic *.td files, because a diagnostic group can be introduced at any of the diagnostic
*.td files.

llvm-svn: 152937

llvm-svn: 152936

llvm-svn: 152935

ScheduleDAGInstrs: When adding uses we add them into a set that's empty at the beginning, no need to maintain another set for the added regs.

llvm-svn: 152934

For boolean flags in Polly there is no problem if they are given more than once.
Hence, we can allow it to not fail for build systems that (acciently) add flags
several times.

This fixes: PR12278

Reported by: Sebastian Pop  <sebpop@gmail.com>

llvm-svn: 152933

llvm-svn: 152931

Saves one machine word on MachineInstr (88->80 bytes on x86_64, 48->44 on i386).

llvm-svn: 152930

Move the flags around slightly.

llvm-svn: 152929

We currently do not support pointer types in affine expressions. Hence, we
disallow in the SCoP detection. Later we may decide to add support for them.

This fixes PR12277

Reported-By: Sebastian Pop <sebpop@gmail.com>
llvm-svn: 152928

No functionality change.

llvm-svn: 152927

Alter the terminal streams such that they do not get added to the atexit chain, and thus never get destructed.

llvm-svn: 152926

llvm-svn: 152925

llvm-svn: 152924

This reverts commit 7dd9b6327b54b08ece32a4607d5ac093b518b79a.

llvm-svn: 152923

llvm-svn: 152921

  so lit find Polly's library in off-tree build.

llvm-svn: 152920

This fixes PR 4307.

Patch by Eitan Adler!

llvm-svn: 152918

This solves the 'isl_ctx freed, but some objects still reference it' problem
reported in PR12276.

llvm-svn: 152917

lit/TestRunner.py: [Win32] Check all opened_files[] released, rather than (obsoleted) written_files[].

In previous case,
RUN: foo -o %t
RUN: FileCheck < %t
RUN: bar -o %t

2nd read handle might prevent manipulation of 3rd %t in bar, to remove and rename.

llvm-svn: 152916

We can simply confirm the handle released to open it with EXCLUSIVE. Attempting renaming was bad.

llvm-svn: 152915

Enable incremental parsing by the Preprocessor,
where more code can be provided after an EOF.
It mainly prevents the tearing down of the topmost lexer.
To be used like this:
PP.enableIncrementalProcessing();
while (getMoreSource()) {
  while (Parser.ParseTopLevelDecl(ADecl)) {...}
}
PP.enableIncrementalProcessing(false);

llvm-svn: 152914

This also fixes UMax where we did not correctly keep track of the parameters.
Fixes PR12275.

Reported-By: Sebastian Pop <sebpop@gmail.com>
llvm-svn: 152913

llvm-svn: 152912

 this option in the configure step of Polly's builder to get more readable
 output from the stdio log.

llvm-svn: 152910

llvm-svn: 152909

llvm-svn: 152908

alignment. If that's the case, then we want to make sure that we don't increase
the alignment of the store instruction. Because if we increase it to be "more
aligned" than the pointer, code-gen may use instructions which require a greater
alignment than the pointer guarantees.
<rdar://problem/11043589>

llvm-svn: 152907