- 17 Oct, 2011 7 commits
-
-
Bill Wendling authored
```--------------------------------------------------------------------- r142243 | void | 2011-10-17 13:28:54 -0700 (Mon, 17 Oct 2011) | 1 line Remove mention of llvm-gcc and add mention of dragonegg. ``` --------------------------------------------------------------------- llvm-svn: 142244
-
Bill Wendling authored
llvm-svn: 142181
-
Bill Wendling authored
llvm-svn: 142180
-
Bill Wendling authored
llvm-svn: 142178
-
Bill Wendling authored
```--------------------------------------------------------------------- r142134 | chandlerc | 2011-10-16 04:05:04 -0700 (Sun, 16 Oct 2011) | 1 line Fix a silly bug introduced in r142133. ``` --------------------------------------------------------------------- llvm-svn: 142175
-
Bill Wendling authored
```--------------------------------------------------------------------- r142133 | chandlerc | 2011-10-16 03:54:30 -0700 (Sun, 16 Oct 2011) | 30 lines Clean up some cruft in the library path searching logic by making 'libdir' mean the actual library directory, not the GCC subdirectory of the library directory. That was just a confusing pattern. Instead, supply proper GCC subdirectories when scanning for various triple-based subdirectories with a GCC installation in them. This also makes it much more obvious how multiarch installations, which have a triple-based prefix as well as suffix work. Also clean up our handling of these triple-prefixed trees by using them in both a multiarch pattern and a non-multiarch pattern whenever they exist. Note that this *does not* match what GCC does on Debian, the only truly multiarch installation I've been able to get installed and test on. GCC appears to have a bug, and ends up searching paths like '/lib/../../lib32' which makes no sense what-so-ever. Instead, I've tried to encode the rational logic that seems clearly intended by GCC's pattern. GCC ends up with patterns like: /lib/../../lib32 /usr/lib/../../lib32 /usr/lib/x86_64-linux-gnu/../..lib32 Only the last one makes any sense having a '/../..' in it, so in Clang, that's the only one which gets a '/../..' in it. I *think* this will fix Debian multiarch links. I'm committing without baking this logic into our test suite so I can test on a few different systems. If all goes well (and no one screams) I'll check in some more comprehensive tests for multiarch behavior tomorrow. ``` --------------------------------------------------------------------- llvm-svn: 142174
-
Bill Wendling authored
PR11143: Save the old diagnostic handler and call it when munging diagnostics for #line directives. This reenables proper inline asm diagnostics in clang llvm-svn: 142169
-
- 16 Oct, 2011 12 commits
-
-
Bill Wendling authored
```--------------------------------------------------------------------- r142165 | void | 2011-10-16 15:44:08 -0700 (Sun, 16 Oct 2011) | 5 lines Overhaul the 'test-release' script. This removes support for building llvm-gcc. It will eventually add support for building other projects. ``` --------------------------------------------------------------------- llvm-svn: 142166
-
Bill Wendling authored
--- Reverse-merging r142156 into '.': U include/llvm/Support/SourceMgr.h U lib/MC/MCParser/AsmParser.cpp llvm-svn: 142161
-
Bill Wendling authored
```--------------------------------------------------------------------- r142132 | d0k | 2011-10-16 03:48:29 -0700 (Sun, 16 Oct 2011) | 3 lines PR11143: Save the old diagnostic handler and call it when munging diagnostics for #line directives. This reenables proper inline asm diagnostics in clang ``` --------------------------------------------------------------------- llvm-svn: 142156
-
Bill Wendling authored
```--------------------------------------------------------------------- r142125 | void | 2011-10-16 01:24:30 -0700 (Sun, 16 Oct 2011) | 1 line Install the PNG file as well. PR4780. ``` --------------------------------------------------------------------- llvm-svn: 142126
-
Bill Wendling authored
```--------------------------------------------------------------------- r142123 | void | 2011-10-16 01:06:54 -0700 (Sun, 16 Oct 2011) | 4 lines Update tutorial to reflect the current APIs. Also correct a small omission in LangImpl6.html (it needed to defined the 'binary :' operator). PR9052 ``` --------------------------------------------------------------------- llvm-svn: 142124
-
Bill Wendling authored
```--------------------------------------------------------------------- r142113 | void | 2011-10-15 23:43:18 -0700 (Sat, 15 Oct 2011) | 1 line Enable CREATE_SUBDIRS for a performance win, because there are a lot of files being generated. ``` --------------------------------------------------------------------- llvm-svn: 142115
-
Bill Wendling authored
```--------------------------------------------------------------------- r142112 | void | 2011-10-15 23:43:10 -0700 (Sat, 15 Oct 2011) | 1 line Enable CREATE_SUBDIRS for a performance win, because there are a lot of files being generated. ``` --------------------------------------------------------------------- llvm-svn: 142114
-
Bill Wendling authored
llvm-svn: 142099
-
Bill Wendling authored
```--------------------------------------------------------------------- r142055 | chapuni | 2011-10-14 21:29:36 -0700 (Fri, 14 Oct 2011) | 5 lines Revert r142046, "Fix for llvm::sys::getHostTriple on Windows. Instead of relying on the triple" It extremely breaks builds when optimization is enabled. Twine should not hold temporary objects. By the way, I might feel sad if I saw "i786-" "i1586-" or "iF86-". ``` --------------------------------------------------------------------- llvm-svn: 142096
-
Bill Wendling authored
```--------------------------------------------------------------------- r142039 | chapuni | 2011-10-14 18:58:16 -0700 (Fri, 14 Oct 2011) | 3 lines Windows/Memory.inc: Support the ability to allocate memory "near" another block of memory on Win32. It has fixed FIXME. Thanks to Aaron Ballman! ``` --------------------------------------------------------------------- llvm-svn: 142095
-
Bill Wendling authored
r142058 | atrick | 2011-10-14 23:19:55 -0700 (Fri, 14 Oct 2011) | 7 lines Fix SCEVExpander assert during LSR: "argument of incompatible type". Just because we're dealing with a GEP doesn't mean we can assert the SCEV has a pointer type. The fix is simply to ignore the SCEV pointer type, which we really didn't need. Fixes PR11138 webkit crash. ------------------------------------------------------------------------ llvm-svn: 142094
-
Bill Wendling authored
llvm-svn: 142093
-
- 15 Oct, 2011 17 commits
-
-
Bill Wendling authored
llvm-svn: 142043 llvm-svn: 142042 llvm-svn: 142041
-
Bill Wendling authored
llvm-svn: 142038 llvm-svn: 142037
-
NAKAMURA Takumi authored
Windows/Memory.inc: Support the ability to allocate memory "near" another block of memory on Win32. It has fixed FIXME. Thanks to Aaron Ballman! llvm-svn: 142039
-
Andrew Trick authored
I rewrote the algorithm a while back so it doesn't require map lookup, but neglected to change the data structure. This was caught by llvm-gcc self host, not because there's anything special about llvm-gcc, but because it is the only test for nondeterminism we currently have. Unit tests don't work well for everything; we should always try to have a nondeterminism stress test running. Fixes PR11133: llvm-gcc self host .o mismatch after enable-iv-rewrite=false llvm-svn: 142036
-
Chandler Carruth authored
Also note that it is actually doing much more than it should. This paves the way for building a more generic 'Emit' routine that is the real entry point here. llvm-svn: 142035
-
Richard Smith authored
This also adds a -Wc++98-compat-pedantic for warning on constructs which would be diagnosed by -std=c++98 -pedantic (that is, it warns even on C++11 features which we enable by default, with no warning, in C++98 mode). llvm-svn: 142034
-
Sean Callanan authored
llvm-svn: 142033
-
Bill Wendling authored
This isn't put into the 'clear()' method because the information needs to stick around (at least for a little bit) after the selection DAG is built. llvm-svn: 142032
-
Jim Ingham authored
llvm-svn: 142031
-
Jakob Stoklund Olesen authored
It really doesn't, but when r141929 removed the hasSideEffects flag from this instruction, it caused miscompilations. I am guessing that it got moved across a stack pointer update. Also clear isRematerializable after checking that this instruction is in fact never rematerialized in the nightly test suite. llvm-svn: 142030
-
Douglas Gregor authored
llvm-svn: 142029
-
Chad Rosier authored
rdar://10288916 is tracking this fix. In the past, instcombine and other passes were promoting alloca alignment past the natural alignment, resulting in dynamic stack realignment. Lang's work now prevents this from happening (LLVM commit r141599). Now that this really shouldn't happen report a fatal error rather than silently generate bad code. llvm-svn: 142028
-
Bill Wendling authored
llvm-svn: 142027
-
Jim Ingham authored
Make the step range plans capable of supporting multiple ranges. Also make their constructors public, there isn't any good reason why you shouldn't be able to make these plans. llvm-svn: 142026
-
Jim Ingham authored
llvm-svn: 142025
-
Jim Ingham authored
llvm-svn: 142024
-
Douglas Gregor authored
avoids loading data from an external source, since those lookups were causing some "interesting" recursion in LLDB. This code is not efficient. I plan to remedy this inefficiency in a follow-up commit. llvm-svn: 142023
-
- 14 Oct, 2011 4 commits
-
-
Eli Friedman authored
llvm-svn: 142022
-
Bill Wendling authored
llvm-svn: 142021
-
Peter Collingbourne authored
llvm-svn: 142020
-
Douglas Gregor authored
Tweak the C++11 status prose a bit. We still need better user guidance on the standard library issue llvm-svn: 142019
-