llvm-svn: 192015

llvm-svn: 192014

llvm-svn: 192013

llvm-svn: 192012

pointed to by a dbg_value belonging to a function argument is eliminated
during instruction selection.
rdar://problem/15094721.

llvm-svn: 192011

 
I've changed it so we don't set highest level warnings (all) for MSVC when building projects using cmake and instead leave the default. That's /W4 on my machine and seems to be ok.
 
With all warnings on for msvc, we see literally thousands of warnings. 99.99% aren't relevant and just obscure the ones that are.
I think the user can still override things if they want something different from the command line when using cmake.

llvm-svn: 192010

llvm-svn: 192009

Several CF* data formatters were in the AppKit category
This puts them back where they belong, i.e. in category CoreFoundation

llvm-svn: 192008

G M: The attached patch is for libcxx's new.cpp and __config files. The patch's intent is to make new.cpp compile using MS's cl.exe compiler without changing the meaning of anything for any other compiler.

The issue this patch seeks to address is that MS's compiler (cl.exe) doesn't support the __attribute__((__weak__)) or __atribute__((__visibility__("default")) syntax; so a solution must be found where cl.exe doesn't see this syntax.

This patch seeks to solve this problem by changing code patterned like this:
__attribute__((__weak__, __visibility__("default")))
void* operator new(size_t size, const std::nothrow_t&) _NOEXCEPT { /*snip*/; return p; }

to code like this:
_LIBCPP_WEAK
void* operator new(size_t size, const std::nothrow_t&) _NOEXCEPT { return p; }

Howard:  Thanks for all the comments regarding the default visibility
tag on the definition.  I agree it isn't needed, and that there are lots
of other places where it is missing.  That being said, I'm not wanting
to rock the boat on that issue right now.  So I've added it back to the
definition via _LIBCPP_FUNC_VIS.  A later pass dedicated just to this
issue can bring things in to a consistent state one way or the other. 
Note that we do not want to have the exact same attributes on the
declaration and defintion in this case.  The declaration should not be
marked weak, whereas the definition should (which is what G M's patch
did). I've fully tested on OS X to ensure that the resultant attribute
syntax actually works.

llvm-svn: 192007

llvm-svn: 192006

llvm-svn: 192005

llvm-svn: 192004

llvm-svn: 192003

scope, pass a scope.

llvm-svn: 192002

UpdatePHINodes has an optimization to reuse an existing PHI node, where it
first deletes all of its entries and then replaces them. Unfortunately, in the
case where we had duplicate predecessors (which are allowed so long as the
associated PHI entries have the same value), the loop removing the existing PHI
entries from the to-be-reused PHI would assert (if that PHI was not the one
which had the duplicates).

llvm-svn: 192001

llvm-svn: 192000

llvm-svn: 191999

* two actually due to some weird template thing... investigating that.

llvm-svn: 191998

llvm-svn: 191997

This radar extends the notion of one-liner summaries to automagically apply in a few interesting cases

More specifically, this checkin changes the printout of ValueObjects to print on one-line (as if type summary add -c had been applied) iff:
this ValueObject does not have a summary
its children have no synthetic children
its children are not a non-empty base class without a summary
its children do not have a summary that asks for children to show up
the aggregate length of all the names of all the children is <= 50 characters
you did not ask to see the types during a printout
your pointer depth is 0

This is meant to simplify the way LLDB shows data on screen for small structs and similarly compact data types (e.g. std::pair<int,int> anyone?)

Feedback is especially welcome on how the feature feels and corner cases where we should apply this printout and don't (or viceversa, we are applying it when we shouldn't be)

llvm-svn: 191996

llvm-svn: 191995

llvm-svn: 191994

llvm-svn: 191993

llvm-svn: 191992

This has the side effect of using DW_FORM_flag_present on dwarf4 and above.

llvm-svn: 191991

a flag. No functional change.

llvm-svn: 191990

DAGCombiner::visitFP_EXTEND will apply the following transformation:

  fold (fpext (load x)) -> (fpext (fptrunc (extload x)))

but the implementation does not handle indexed loads (pre/post inc.), but did
not specifically ignore them either (unlike for extending loads, which it
already ignored), causing an assert when the transformation was applied to an
indexed load. This is the minimal fix for correctness (causing the
transformation to be skipped for indexed loads).

Unfortunately, I don't have an in-tree test case.

llvm-svn: 191989

G M: A small patch to fix a couple of warnings in stdexcept.cpp for cl.exe which does not support #pragma visibility.

llvm-svn: 191988

G M: Changes all references to "x inline" to "inline x" where x = _libcpp_always_inline or _libcpp_inline_visibility macros.

The patch touches these files:

locale
array
deque
new
string
utility
vector
__bit_reference
__split_buffer
locale_win32.h
 
There is no intended functionality change and it is expected that reversing the position of the inline keyword with regard to the other keywords does not change the meaning of anything, least not for apple/Linux etc.
 
It is intended to make libcxx more consistent with itself and to prevent the 1000 or so
"inline.cpp(3) : warning C4141: 'inline' : used more than once" warnings that MS's cl.exe compiler emits without this patch, i.e. if inline is not the first keyword before a function name etc.
 
Prefer "inline [other inline related keyword]" over "[other related keyword] inline".
After this patch, libcxx should be consistent to this pattern.

llvm-svn: 191987

llvm-svn: 191986

We were writing in text mode.

Patch by Greg Bedwell.

llvm-svn: 191985

that all clients use them explicitly.  This will hopefully
prevent any future confusion where things get cast to types
we don't expect.

<rdar://problem/15146458>

llvm-svn: 191984

that a function can be called in.  This reduced the total number of annotations
needed and makes writing more complicated behaviour less burdensome.
Patch by chriswails@gmail.com.

llvm-svn: 191983

This patch handles LLVM standalone assembler (llvm-mc) ELF flag setting based on input file
directive processing.

Mips assembly requires processing inline directives that directly and
indirectly affect the output ELF header flags. This patch handles one
".abicalls".

To process these directives we are following the model the code generator
uses by storing state in a container as we go through processing and when
we detect the end of input file processing, AsmParser is notified and we
update the ELF header flags through a MipsELFStreamer method with a call from
MCTargetAsmParser::emitEndOfAsmFile(MCStreamer &OutStreamer).

This patch will allow other targets the same functionality.

Jack

llvm-svn: 191982

G M: Fix libcxx's detection of rtti disablement for g++.exe and cl.exe. When RTTI is NOT enabled, _LIBCPP_NO_RTTI is defined.

llvm-svn: 191981

G M: Provides the _LIBCPP_WARNING macro, to be used for MSVC only, since that compiler doesn't support #warning.

llvm-svn: 191980

llvm-svn: 191979

instructions in delay slots along with the original branch instructions.

llvm-svn: 191978

Sort the operands of the other entries in the current vectorization root
according to the first entry's operands opcodes.

%conv0 = uitofp ...
%load0 = load float ...

= fmul %conv0, %load0
= fmul %load0, %conv1
= fmul %load0, %conv2

Make sure that we recursively vectorize <%conv0, %conv1, %conv2> and <%load0,
%load0, %load0>.

This makes it more likely to obtain vectorizable trees. We have to be careful
when we sort that we don't destroy 'good' existing ordering implied by source
order.

radar://15080067

llvm-svn: 191977

llvm-svn: 191976