- Jun 19, 2012
-
-
Marshall Clow authored
llvm-svn: 158730
-
Chad Rosier authored
llvm-svn: 158729
-
Bill Wendling authored
llvm-svn: 158728
-
Chad Rosier authored
filed, but still missing the preprocessed source and associated run script. rdar://11684107 llvm-svn: 158727
-
Bill Wendling authored
llvm-svn: 158726
-
Chandler Carruth authored
StringMap suffered from the same bug as DenseMap: when you explicitly construct it with a small number of buckets, you can arrange for the tombstone-based growth path to be followed when the number of buckets was less than '8'. In that case, even with a full map, it would compare '0' as not less than '0', and refuse to grow the table, leading to inf-loops trying to find an empty bucket on the next insertion. The fix is very simple: use '<=' as the comparison. The same fix was applied to DenseMap as well during its recent refactoring. Thanks to Alex Bolz for the great report and test case. =] llvm-svn: 158725
-
Chandler Carruth authored
GoogleTest already prints errors with all the information about which test case contained the error. llvm-svn: 158724
-
Benjamin Kramer authored
Should silence warnings when compiling the X86 disassembler. llvm-svn: 158723
-
Jan Wen Voung authored
The condition code didn't actually matter for arm "b" instructions, unlike "bl". It should just use the R_ARM_JUMP24 reloc. llvm-svn: 158722
-
Hal Finkel authored
For processors with the G5-like instruction-grouping scheme, this helps avoid early group termination due to a write-after-write dependency within the group. It should also help on pipelined embedded cores. On POWER7, over the test suite, this gives an average 0.5% speedup. The largest speedups are: SingleSource/Benchmarks/Stanford/Quicksort - 33% MultiSource/Applications/d/make_dparser - 21% MultiSource/Benchmarks/FreeBench/analyzer/analyzer - 12% MultiSource/Benchmarks/MiBench/telecomm-FFT/telecomm-fft - 12% Largest slowdowns: SingleSource/Benchmarks/Stanford/Bubblesort - 23% MultiSource/Benchmarks/Prolangs-C++/city/city - 21% MultiSource/Benchmarks/BitBench/uuencode/uuencode - 16% MultiSource/Benchmarks/mediabench/mpeg2/mpeg2dec/mpeg2decode - 13% llvm-svn: 158719
-
Aaron Ballman authored
llvm-svn: 158718
-
Aaron Ballman authored
Improves parsing and semantic analysis for MS __declspec attributes. This includes support for the align (which fixes PR12631). llvm-svn: 158717
-
Alexis Hunt authored
I've also removed the duplicate check for PARSED_ATTR since it seems unnecessary, and would have made the code more complicated. llvm-svn: 158716
-
Bill Wendling authored
llvm-svn: 158715
-
Bill Wendling authored
llvm-svn: 158714
-
Bill Wendling authored
llvm-svn: 158713
-
Bill Wendling authored
llvm-svn: 158712
-
Bill Wendling authored
llvm-svn: 158711
-
Alexey Samsonov authored
llvm-svn: 158710
-
Bill Wendling authored
llvm-svn: 158709
-
Alexey Samsonov authored
[TSan] Add a comment that tsan_flags.h may be included in the user code, and therefore shouldn't include other headers from TSan or common sanitizer runtime. User may need tsan_flags.h to provide its implementation of __tsan::OverrideFlags llvm-svn: 158708
-
Alexey Samsonov authored
[Sanitizer] State that sanitizer_libc.h header can be included in the user code (and therefore it shouldn't include other sanitizer runtime headers). llvm-svn: 158707
-
Alexey Samsonov authored
llvm-svn: 158706
-
Alexey Samsonov authored
llvm-svn: 158705
-
Michael J. Spencer authored
llvm-svn: 158704
-
Anna Zaks authored
(Fixes radar://11691035 PR13140) llvm-svn: 158703
-
Akira Hatanaka authored
llvm-svn: 158702
-
Akira Hatanaka authored
MipsCodeEmitter.cpp. llvm-svn: 158701
-
Alexis Hunt authored
Note that this is mostly a structural patch that handles the change from the old spelling style to the new one. One consequence of this is that all AT_foo_bar enum values have changed to not be based off of the first spelling, but rather off of the class name, so they are now AT_FooBar and the like (a straw poll on IRC showed support for this). Apologies for code churn. Most attributes have GNU spellings as a temporary solution until everything else is sorted out (such as a Keyword spelling, which I intend to add if someone else doesn't beat me to it). This is definitely a WIP. I've also killed BaseCheckAttr since it was unused, and I had to go through every attribute anyway. llvm-svn: 158700
-
Jordan Rose authored
It turns out SourceManager treating the "one-past-the-end" location as invalid, but then failing to set the invalid flag properly. llvm-svn: 158699
-
Hal Finkel authored
PPC will now generate STWUX and friends. llvm-svn: 158698
-
Argyrios Kyrtzidis authored
ObjCInterfaceDec::lookupInstanceMethod to make sure we check categories as well and update related tests. rdar://11695288 llvm-svn: 158697
-
Rafael Espindola authored
llvm-svn: 158696
-
Rafael Espindola authored
llvm-svn: 158695
-
Rafael Espindola authored
option. On the driver, check if we are using libraries from gcc 4.7 or newer and if so pass -fuse-init-array to the frontend. The crtbegin*.o files in gcc 4.7 no longer call the constructors listed in .ctors, so we have to use .init_array. llvm-svn: 158694
-
Johnny Chen authored
lldb confused by single quote in executable path Also add a test case. llvm-svn: 158693
-
Rafael Espindola authored
TargetLoweringObjectFileELF. Use this to support it on X86. Unlike ARM, on X86 it is not easy to find out if .init_array should be used or not, so the decision is made via TargetOptions and defaults to off. Add a command line option to llc that enables it. llvm-svn: 158692
-
Kaelyn Uhrain authored
because it expects a reference and receives a non-l-value. For example, given: int foo(int &); template<int x> void b() { foo(x); } clang will now print "expects an l-value for 1st argument" instead of "no known conversion from 'int' to 'int &' for 1st argument". The change in wording (and associated code to detect the case) was prompted by comment #5 in PR3104, and should be the last bit of work needed for the bug. llvm-svn: 158691
-
Ted Kremenek authored
the compiler predefines buffer. These are essentially part of the Objective-C language. llvm-svn: 158690
-
Jordan Rose authored
Per post-commit review, it's not appropriate to use ExtWarn in C++, because we can't prove that the inline function will actually be defined in more than one place (and thus we can't prove that this violates the ODR). This removes the warning entirely from uses in the main source file in C++. llvm-svn: 158689
-