llvm-svn: 198786

fields.

llvm-svn: 198785

llvm-svn: 198784

llvm-svn: 198783

We (perhaps over-cautiously) disable the new plugin tests on static Windows
builds right now, matching what LLVM core does. This change was needed for the
lit check to work.

Thanks to Warren Hunt for spotting this.

llvm-svn: 198782

[Serialization] In ASTReader::getInputFile record it when we didn't find the file to avoid looking it up again.

Hopefully addresses rdar://14514222.

llvm-svn: 198781

resolution works.

llvm-svn: 198780

...rather somewhere in the destructor when we try to access something and
realize the object has already been deleted. This is necessary because
the destructor is processed before the 'delete' itself.

Patch by Karthik Bhat!

llvm-svn: 198779

It's not a real instruction any more and doesn't need encoding information.

llvm-svn: 198778

to the following two rules:
  1) fold (vselect (build_vector AllOnes), A, B) -> A
  2) fold (vselect (build_vector AllZeros), A, B) -> B

llvm-svn: 198777

Fixed a kernel panic that would occur if you debug anything on MacOSX 10.7 or earlier due to the use of the POSIX_SPAWN_CLOEXEC_DEFAULT attribute flag that closes all file descriptors on exec. We now dyamically detect the OS version and do the right thing.

llvm-svn: 198776

No idea how this was compiling locally. Found by the bots.

llvm-svn: 198775

These private functions return pointers to the internal storage.

llvm-svn: 198774

llvm-svn: 198772

llvm-svn: 198771

PR18406.

llvm-svn: 198770

Before:
  vector<int> foo{ ::SomeFunction()};

After:
  vector<int> foo{::SomeFunction()};

llvm-svn: 198769

No functional change intended.

llvm-svn: 198768

Reviewers: djasper

Reviewed By: djasper

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2519

llvm-svn: 198767

Python doesn't do a good job at diagnosing string exec() so use execfile()
where available.

This should be a timesaver when trying to get to the bottom of build bot
failures.

Before:

    File "llvm/utils/lit/lit/TestingConfig.py", line 93, in load_from_path
      exec("exec data in cfg_globals")
    File "<string>", line 1, in <module>
    File "<string>", line 194, in <module>
  NameError: name 'typo' is not defined

After:

    File "llvm/utils/lit/lit/TestingConfig.py", line 95, in load_from_path
    execfile(path, cfg_globals)
    File "clang/test/lit.cfg", line 194, in <module>
      typo
      ^~~~
  NameError: name 'typo' is not defined

llvm-svn: 198766

Patch reviewed by Rafael Espindola.

llvm-svn: 198765

This is a further build fix attempt for r198747 on some Makefile builders where
the value wasn't set at all.

llvm-svn: 198764

llvm-svn: 198763

Mark them as requiring 16-bit mode for now, since we don't yet have
relaxation support for FK_Data_2.

llvm-svn: 198762

They do *different* things to %esp, so they are not equivalent.

Rename PUSHi8 to PUSH32i8 and add the missing PUSH16i8.

llvm-svn: 198761

We can't do a perfect job here. We *have* to allow (%dx) even in 64-bit
mode, for example, because it might be used for an unofficial form of
the in/out instructions. We actually want to do a better job of validation
*later*. Perhaps *instead* of doing it where we are at the moment.

But for now, doing what validation we *can* do in the place that the code
already has its validation, is an improvement.

llvm-svn: 198760

It seems there is no separate instruction class for having AdSize *and*
OpSize bits set, which is required in order to disambiguate between all
these instructions. So add that to the disassembler.

Hm, perhaps we do need an AdSize16 bit after all?

llvm-svn: 198759

Where "where possible" means that it's an immediate value and it's below
0x10000. In fact GAS will either truncate or error with larger values,
and will insist on using the addr32 prefix to get 32-bit addressing. So
perhaps we should do that, in a later patch.

llvm-svn: 198758

JCXZ should have the 0x67 prefix only if we're in 32-bit mode, so make that
appropriately conditional. And JECXZ needs the prefix instead.

llvm-svn: 198757

I couldn't see how to do this sanely without splitting RETQ from RETL.

Eric says: "sad about the inability to roundtrip them now, but...".
I have no idea what that means, but perhaps it wants preserving in the
commit comment.

llvm-svn: 198756

llvm-svn: 198755

llvm-svn: 198754

llvm-svn: 198753

This fixes the bulk of 16-bit output, and the corresponding test case
x86-16.s now looks mostly like the x86-32.s test case that it was
originally based on. A few irrelevant instructions have been dropped,
and there are still some corner cases to be fixed in subsequent patches.

llvm-svn: 198752

llvm-svn: 198751

Convert CMake CLANG_BUILD_EXAMPLES to a boolean value for consumption by
Python, otherwise the raw config string gets passed through which may not be
0/1.

The if/else matches the technique used to solve the problem in LLVM's own
CMakeLists.txt.

llvm-svn: 198750

With a current mingw (gcc 4.8.1) it looks like we hit some variation of

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278

The end result is that off_t is not defined and the build fails without this
patch.

llvm-svn: 198749

With the old use of -std=c89 off_t is not defined and the build fails.

This seems to be another variation of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278.

llvm-svn: 198748

Somehow the entire plugin infrastructure went wholly untested until now.

The only plugins available for use in testing are the examples, so plugin tests
will only be run if CLANG_BUILD_EXAMPLES is enabled in the build.

(The examples should really be enabled by default, not just to aid testing but
also to prevent bitrot in some key user-facing code. I'll propose that
shortly.)

Requires supporting changes in LLVM r198746.

llvm-svn: 198747

This is needed to support the addition of tests for clang loadable plugins.

In clang, plugins are built as modules (bundles on OS X) rather than dynamic
libraries (dylib) so the build system needs to inform lit of the actual
file extension in use, typically '.so' on Unix and '.dll' on Windows.

(LLVM itself should probably switch to this scheme to fix PR14903 once and for
all.)

No change in build output or functionality intended.

llvm-svn: 198746