- Aug 08, 2013
-
-
Eric Christopher authored
the type exists. Fix up cases where we weren't checking for optional types and add an assert to addType to make sure we catch this in the future. Fix up a testcase that was using the tag for DW_TAG_array_type when it meant DW_TAG_enumeration_type. llvm-svn: 187963
-
Eric Christopher authored
llvm-svn: 187962
-
Craig Topper authored
llvm-svn: 187961
-
Hal Finkel authored
Making use of the recently-added ISD::FROUND, which allows for custom lowering of round(), the PPC backend will now map frin to round(). Previously, we had been using frin to lower nearbyint() (and rint() via some custom lowering to handle the extra fenv flags requirements), but only in fast-math mode because frin does not tie-to-even. Several users had complained about this behavior, and this new mapping of frin to round is certainly more appropriate (and does not require fast-math mode). In effect, this reverts r178362 (and part of r178337, replacing the nearbyint mapping with the round mapping). llvm-svn: 187960
-
Arnold Schwaighofer authored
Zhihao Yuan: Replace operator& with addressof in reference_wrapper constructor. It breaks a clang bootstrap. llvm-svn: 187959
-
Richard Trieu authored
so that it can be toggled independently of other deprecated warnings. llvm-svn: 187958
-
Arnold Schwaighofer authored
It broke a public build bot. llvm-svn: 187957
-
David Majnemer authored
This reverts commit r77814. We were sticking global constants in the .data section instead of in the .rdata section when emitting for COFF. This fixes PR16831. llvm-svn: 187956
-
Richard Trieu authored
Fixes PR16394. llvm-svn: 187955
-
Eric Christopher authored
llvm-svn: 187954
-
Eric Christopher authored
llvm-svn: 187953
-
Filipe Cabecinhas authored
llvm-svn: 187952
-
Filipe Cabecinhas authored
llvm-svn: 187951
-
Chandler Carruth authored
LLVMConfig.cmake file that is (I think) used in the stand-alone Clang build, and causing link errors there w.r.t. curses. llvm-svn: 187950
-
Alexander Kornienko authored
Summary: This is consistent with MacOSX implementation, and most terminals actually display this character (checked on gnome-terminal, lxterminal, lxterm, Terminal.app, iterm2). Actually, this is in line with the ISO Latin 1 standard (ISO 8859-1), which defines it differently from the Unicode Standard. More information here: http://www.cs.tut.fi/~jkorpela/shy.html Reviewers: gribozavr, jordan_rose CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1310 llvm-svn: 187949
-
Filipe Cabecinhas authored
Summary: UBSan was checking for alignment of the derived class on the pointer to the base class, before converting. With some class hierarchies, this could generate false positives. Added test-case. llvm-svn: 187948
-
Ted Kremenek authored
llvm-svn: 187947
-
Michael Gottesman authored
Revert "[objc-arc] Track if we encountered an additive overflow while computing {TopDown,BottomUp}PathCounts and do nothing if it occured." This reverts commit r187941. The commit was passing on my os x box, but it is failing on some non-osx platforms. I do not have time to look into it now, so I am reverting and will recommit after I figure this out. llvm-svn: 187946
-
Hans Wennborg authored
These flags set some preprocessor macros and injects a dependency on the runtime library into the object file, which later is picked up by the linker. This also adds a new CC1 flag for adding a dependent library. Differential Revision: http://llvm-reviews.chandlerc.com/D1315 llvm-svn: 187945
-
Peter Collingbourne authored
llvm-svn: 187944
-
John Thompson authored
llvm-svn: 187943
-
John Thompson authored
llvm-svn: 187942
-
Michael Gottesman authored
[objc-arc] Track if we encountered an additive overflow while computing {TopDown,BottomUp}PathCounts and do nothing if it occured. rdar://14590914 llvm-svn: 187941
-
Michael Gottesman authored
llvm-svn: 187940
-
Bill Wendling authored
Original commit message: Stop emitting weak symbols into the "coal" sections. The Mach-O linker has been able to support the weak-def bit on any symbol for quite a while now. The compiler however continued to place these symbols into a "coal" section, which required the linker to map them back to the base section name. Replace the sections like this: __TEXT/__textcoal_nt instead use __TEXT/__text __TEXT/__const_coal instead use __TEXT/__const __DATA/__datacoal_nt instead use __DATA/__data <rdar://problem/14265330> llvm-svn: 187939
-
Peter Collingbourne authored
llvm-svn: 187938
-
Peter Collingbourne authored
llvm-svn: 187937
-
Howard Hinnant authored
llvm-svn: 187936
-
Alexander Kornienko authored
Summary: Only works for UTF-8-encoded files. Reviewers: djasper Reviewed By: djasper CC: cfe-commits, klimek Differential Revision: http://llvm-reviews.chandlerc.com/D1311 llvm-svn: 187935
-
Daniel Dunbar authored
llvm-svn: 187934
-
Daniel Dunbar authored
llvm-svn: 187933
-
Daniel Dunbar authored
llvm-svn: 187932
-
Daniel Dunbar authored
llvm-svn: 187931
-
Daniel Dunbar authored
llvm-svn: 187929
-
Daniel Dunbar authored
llvm-svn: 187928
-
Howard Hinnant authored
llvm-svn: 187927
-
Hal Finkel authored
All libm floating-point rounding functions, except for round(), had their own ISD nodes. Recent PowerPC cores have an instruction for round(), and so here I'm adding ISD::FROUND so that round() can be custom lowered as well. For the most part, this is straightforward. I've added an intrinsic and a matching ISD node just like those for nearbyint() and friends. The SelectionDAG pattern I've named frnd (because ISD::FP_ROUND has already claimed fround). This will be used by the PowerPC backend in a follow-up commit. llvm-svn: 187926
-
Peter Collingbourne authored
DataFlowSanitizer is a generalised dynamic data flow analysis. Unlike other Sanitizer tools, this tool is not designed to detect a specific class of bugs on its own. Instead, it provides a generic dynamic data flow analysis framework to be used by clients to help detect application-specific issues within their own code. Differential Revision: http://llvm-reviews.chandlerc.com/D966 llvm-svn: 187925
-
Peter Collingbourne authored
DataFlowSanitizer is a generalised dynamic data flow analysis. Unlike other Sanitizer tools, this tool is not designed to detect a specific class of bugs on its own. Instead, it provides a generic dynamic data flow analysis framework to be used by clients to help detect application-specific issues within their own code. Differential Revision: http://llvm-reviews.chandlerc.com/D967 llvm-svn: 187924
-
Peter Collingbourne authored
DataFlowSanitizer is a generalised dynamic data flow analysis. Unlike other Sanitizer tools, this tool is not designed to detect a specific class of bugs on its own. Instead, it provides a generic dynamic data flow analysis framework to be used by clients to help detect application-specific issues within their own code. Differential Revision: http://llvm-reviews.chandlerc.com/D965 llvm-svn: 187923
-