- Sep 19, 2013
-
-
Andrew Trick authored
Working on a better solution to this. This reverts commit 7d4e9934e7ca83094c5cf41346966c8350179ff2. llvm-svn: 190990
-
Dmitry Vyukov authored
WARNING: ThreadSanitizer: data race (pid=29103) Write of size 8 at 0x7d64003bbf00 by main thread: #0 free tsan_interceptors.cc:477 #1 __run_exit_handlers <null>:0 (libc.so.6+0x000000050cb7) Previous write of size 8 at 0x7d64003bbf00 by thread T78 (mutexes: write M9896): #0 calloc tsan_interceptors.cc:449 #1 ... llvm-svn: 190989
-
Dmitry Vyukov authored
llvm-svn: 190988
-
Dmitry Vyukov authored
llvm-svn: 190987
-
Rui Ueyama authored
llvm-svn: 190986
-
Reid Kleckner authored
llvm-svn: 190985
-
Eli Friedman authored
llvm-svn: 190984
-
Rui Ueyama authored
Test is coming after submitting http://llvm-reviews.chandlerc.com/D1719. llvm-svn: 190983
-
Craig Topper authored
llvm-svn: 190982
-
Eli Friedman authored
We don't really need to perform semantic analysis on the dependent expression anyway, so just call the cast dependent. <rdar://problem/15012610> llvm-svn: 190981
-
Eli Friedman authored
Before this patch, Lex() would recurse whenever the current lexer changed (e.g. upon entry into a macro). This patch turns the recursion into a loop: the various lex routines now don't return a token when the current lexer changes, and at the top level Preprocessor::Lex() now loops until it finds a token. Normally, the recursion wouldn't end up being very deep, but the recursion depth can explode in edge cases like a bunch of consecutive macros which expand to nothing (like in the testcase test/Preprocessor/macro_expand_empty.c in this patch). <rdar://problem/14569770> llvm-svn: 190980
-
Reid Kleckner authored
llvm-svn: 190979
-
Reid Kleckner authored
Test that intrin.h at least parses in C++ TUs. llvm-svn: 190978
-
Craig Topper authored
llvm-svn: 190977
-
Andrew Trick authored
This puts all the global PassManager debugging flags, like -print-after-all and -time-passes, behind a managed static. This eliminates their static initializers and, more importantly, exit-time destructors. The only behavioral change I anticipate is that tools need to initialize the PassManager before parsing the command line in order to export these options, which makes sense. Tools that already initialize the standard passes (opt/llc) don't need to do anything new. llvm-svn: 190974
-
Andrew Trick authored
llvm-svn: 190973
-
Eli Friedman authored
This patch adds the following, more specific warning flags: gnu-anonymous-struct gnu-compound-literal-initializer gnu-empty-struct gnu-flexible-array-initializer gnu-flexible-array-union-member gnu-folding-constant redeclared-class-member gnu-redeclared-enum gnu-union-cast gnu-variable-sized-type-not-at-end Patch by Peter Lewis. llvm-svn: 190972
-
Eli Friedman authored
Patch by Eelis van der Weegen. llvm-svn: 190971
-
Richard Smith authored
defined with no initializer. llvm-svn: 190970
-
Adrian Prantl authored
llvm-svn: 190969
-
Sean Callanan authored
have a type. It does warn, though. llvm-svn: 190968
-
Adrian Prantl authored
llvm-svn: 190967
-
Reed Kotler authored
1) make sure that the first two instructions of the sequence cannot separate from each other. The linker requires that they be sequential. If they get separated, it can still work but it will not work in all cases because the first of the instructions mostly involves the hi part of the pc relative offset and that part changes slowly. You would have to be at the right boundary for this to matter. 2) make sure that this sequence begins on a longword boundary. There appears to be a bug in binutils which makes some of these calculations get messed up if the instruction sequence does not begin on a longword boundary. This is being investigated with the appropriate binutils folks. llvm-svn: 190966
-
Eric Christopher authored
llvm-svn: 190965
-
Hans Wennborg authored
I put in the warnings because MSVC has them, but I don't think they're very useful. Clang does not warn about overriding flags in general, e.g. it's perfectly fine to have -fomit-frame-pointer followed by -fno-omit-frame-pointer. We should focus on warning where things get confusing, such as with the /TP and /TC options. In "clang-cl /TC a.c /TP b.cc", the user might not realize that the /TP flag will apply to both files, and we warn about that. Differential Revision: http://llvm-reviews.chandlerc.com/D1718 llvm-svn: 190964
-
Eric Christopher authored
llvm-svn: 190963
-
Adrian Prantl authored
llvm-svn: 190962
-
Adrian Prantl authored
Use the DIVariable::isIndirect() flag set by the frontend instead of guessing whether to set the machine location's indirection bit. Paired commit with CFE. llvm-svn: 190961
-
Adrian Prantl authored
This allows us to get rid of an ugly hack in the backend. Paired commit with LLVM. llvm-svn: 190960
-
- Sep 18, 2013
-
-
Richard Smith authored
llvm-svn: 190959
-
Preston Gurd authored
-march=x86 to SLM test. llvm-svn: 190958
-
Preston Gurd authored
Atom Silvermont. Patch by Sriram Murali. llvm-svn: 190957
-
Fariborz Jahanian authored
'instancetype' for known family of methods with related result type; such as 'init' methods. // rdar://14987948 llvm-svn: 190956
-
Greg Clayton authored
Fixed a logic error in Module::ResolveSymbolContextForAddress(). Asking an address if its offet is greater than zero doesn't actually correctly tell us wether the address is section offset or not. A symbol could be the first symbol in a section and its offset can be zero. Also, a non-section offset lldb_private::Address can have a NULL section and calling GetOffset() will return the absolute address. To really test if an address is section offset clients should use Address::IsSectionOffset(). Also simplified the code that backs the address up by one to use the Address::Slide() function. llvm-svn: 190955
-
Ed Maste authored
llvm-svn: 190954
-
Jordan Rose authored
We now have symbols with floating-point type to make sure that (double)x == (double)x comes out true, but we still can't do much with these. For now, don't even bother trying to create a floating-point zero value; just give up on conversion to bool. PR14634, C++ edition. llvm-svn: 190953
-
Galina Kistanova authored
llvm-svn: 190952
-
Rui Ueyama authored
Base relocation block should be aligned on a 32-bit boundary. While the PECOFF spec mentions only aligning the blocks, and not padding them, link.exe seems to add an extra IMAGE_REL_I386_ABSOLUTE entry (just a zeroed WORD) in order to pad the blocks. Patch by Ron Ofir. llvm-svn: 190951
-
John Thompson authored
llvm-svn: 190950
-
Rui Ueyama authored
llvm-svn: 190949
-