This allows the ObjFW runtime to correctly implement message forwarding
for messages which return a struct.

Patch by Jonathan Schleifer.

llvm-svn: 187174

Refine the fix in r187094 to only distrust the StackID comparision when we are starting from an address with no symbols.
If we don't do that "nexti" will stop too soon when stepping past a tail call jump.

rdar://problem/14516227

llvm-svn: 187173

It turns out that Plum Hall depends on us not emitting an error on
integer literals which fit into long long, but fit into
unsigned long long.  So C99 conformance requires not conforming to C99. :)

llvm-svn: 187172

Also, fix the wording to reflect this.

llvm-svn: 187171

llvm-svn: 187170

- First, the watchpoint size was being cast to the
  wrong type.  This is primarily cosmetic, but
  annoying.

- Second, the options for the watchpoint command
  were not being initialized correctly, which led
  to the watchpoint size sometimes having absurdly
  large values.  This caused watchpoints to fail to
  be set in some cases.

<rdar://problem/12658775>

llvm-svn: 187169

They seemed to have the same implications, and this makes for one
less flag to worry about.

Differential Revision: http://llvm-reviews.chandlerc.com/D1219

llvm-svn: 187168

sufficient to only consider names visible at the point of instantiation,
because that may not include names that were visible when the template was
defined. More generally, if the instantiation backtrace goes through a module
M, then every declaration visible within M should be available to the
instantiation. Any of those declarations might be part of the interface that M
intended to export to a template that it instantiates.

The fix here has two parts:

1) If we find a non-visible declaration during name lookup during template
instantiation, check whether the declaration was visible from the defining
module of all entities on the active template instantiation stack. The defining
module is not the owning module in all cases: we look at the module in which a
template was defined, not the module in which it was first instantiated.

2) Perform pending instantiations at the end of a module, not at the end of the
translation unit. This is general goodness, since it significantly cuts down
the amount of redundant work that is performed in every TU importing a module,
and also implicitly adds the module containing the point of instantiation to
the set of modules checked for declarations in a lookup within a template
instantiation.

There's a known issue here with template instantiations performed while
building a module, if additional imports are added later on. I'll fix that
in a subsequent commit.

llvm-svn: 187167

llvm-svn: 187166

llvm-svn: 187165

llvm-svn: 187164

llvm-svn: 187163

llvm-svn: 187162

llvm-svn: 187161

Previously, we tried to avoid creating new temporary object regions if
the value to be materialized itself came from a temporary object region.
However, once we became more strict about lvalues vs. rvalues (months
ago), this optimization became dead code, because the input to this
function will always be an rvalue (i.e. a symbolic value or compound
value rather than a region, at least for structs).

This would be a nice optimization to keep, but removing it makes it
simpler to reason about temporary regions.

llvm-svn: 187160

Using a different loop induction variable than the enclosing scope.  No functional changes intended.

llvm-svn: 187159

structure not just a pointer. This implements that and thus fixes va_copy
on PPC32. Fixes #15286. Both bug and patch by Florian Zeitz!

llvm-svn: 187158

llvm-svn: 187157

Use the same filtering for assembly arguments to -cc1as as we do for
-cc1, this allows a consistent (& more useful) diagnostic experience for
users (rather than getting an error from -cc1as (which a user shouldn't
really be thinking about) about --foo, they get an error from clang
about --foo in -Wa,)

I'm sort of surprised by the separation of -cc1as & the separate
argument handling, etc, but at least this removes a little bit of the
duplication.

llvm-svn: 187156

llvm-svn: 187155

Back in r140220 we removed the autoconf code that would set LLVMCC_OPTION
since it was only used by the test-suite. This patch now removes code
that would only be used if LLVMCC_OPTION was set.

llvm-svn: 187154

Recent failures on a freebsd buildbot indicated a weakness in the
Reformatting.cpp lit test. Tweaking the test to avoid false negatives and
hopefully make the buildbot happy.

llvm-svn: 187153

llvm-svn: 187152

llvm-svn: 187151

Make sure the context field of DIType is MDNode.
Fix testing cases to make them pass the verifier.

llvm-svn: 187150

Also move the logic to shorten thread names from linux/Host.cpp to a new
SetShortThreadName as both FreeBSD and Linux need the functionality.

llvm-svn: 187149

llvm-svn: 187148

- ReadLocker constructors that take a lock
- Unconditional Lock::ReadLock and ReadLocker::Lock
  (all consumers use TryLock)
- Make Unlock protected, as it has no external consumers

llvm-svn: 187147

llvm-svn: 187146

Approval in here http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064169.html

llvm-svn: 187145

Approval in here http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064169.html

llvm-svn: 187143

FreeBSD's Host class doesn't yet return a list of running processes,
so 'platform process list' fails and attach by process name does not
work.

llvm-svn: 187142

llvm-svn: 187141

The previous change to local live range allocation also suppressed
eviction of local ranges. In rare cases, this could result in more
expensive register choices. This commit actually revives a feature
that I added long ago: check if live ranges can be reassigned before
eviction. But now it only happens in rare cases of evicting a local
live range because another local live range wants a cheaper register.

The benefit is improved code size for some benchmarks on x86 and armv7.

I measured no significant compile time increase and performance
changes are noise.

llvm-svn: 187140

Also avoid locals evicting locals just because they want a cheaper register.

Problem: MI Sched knows exactly how many registers we have and assumes
they can be colored. In cases where we have large blocks, usually from
unrolled loops, greedy coloring fails. This is a source of
"regressions" from the MI Scheduler on x86. I noticed this issue on
x86 where we have long chains of two-address defs in the same live
range. It's easy to see this in matrix multiplication benchmarks like
IRSmk and even the unit test misched-matmul.ll.

A fundamental difference between the LLVM register allocator and
conventional graph coloring is that in our model a live range can't
discover its neighbors, it can only verify its neighbors. That's why
we initially went for greedy coloring and added eviction to deal with
the hard cases. However, for singly defined and two-address live
ranges, we can optimally color without visiting neighbors simply by
processing the live ranges in instruction order.

Other beneficial side effects:

It is much easier to understand and debug regalloc for large blocks
when the live ranges are allocated in order. Yes, global allocation is
still very confusing, but it's nice to be able to comprehend what
happened locally.

Heuristics could be added to bias register assignment based on
instruction locality (think late register pairing, banks...).

Intuituvely this will make some test cases that are on the threshold
of register pressure more stable.

llvm-svn: 187139

llvm-svn: 187138

llvm-svn: 187137

llvm-svn: 187135

Watchpoints are not yet working on FreeBSD

llvm-svn: 187134

This goes with r186925, which reverted Pavel's commit in r186498.

Also, add a correctness test for the future.

llvm-svn: 187133