defined as an internal software error.  This notifies the driver to report
diagnostics information.
rdar://11951540

llvm-svn: 167754

Per discussion on cfe-dev, re-enable suppression of -Wimplicit-fallthrough on C, but also include dialects of C++ earlier than C++11.

There was enough consensus that we *can* get a good language solution
to have an annotation outside of C++11, and without this annotation
this warning doesn't quite mean's completeness criteria for this
kind of warning.  For now, restrict this warning to C++11 (where an
annotation exists), and make this the behavior for the LLVM 3.2 release.
Afterwards, we will hammer out a language solution that we are all
happy with.

llvm-svn: 167749

llvm-svn: 167748

temporary files are removed.
rdar://12282296

llvm-svn: 167741

Post-commit review feedback by Eli Friedman.

llvm-svn: 167739

Patch by Florent Bruneau!

llvm-svn: 167736

llvm-svn: 167735

The 'a', 'c', and 'd' constraints on i386 mean a 32-bit register. We cannot
place a 64-bit value into the 32-bit register. Error out instead of causing the
compiler to spew general badness.
<rdar://problem/12415959>

llvm-svn: 167717

now covered by attribute merging.

llvm-svn: 167714

attributes. In cases where the merged declaration is fully equivalent to the
two original ones, some of the code was getLVForDecl was duplicated.

Cases that are still handled in getLVForDecl are things like

__private_extern__ int N;
int N;

For which we cannot produce a single merged decl with all the information.

llvm-svn: 167703

Some NVVM intrinsics were incorrectly labeled.

llvm-svn: 167700

When recursively visiting the generated matches, the aggregated bindings need
to be copied during the recursion. Otherwise, we they might not be properly
overwritten (which is shown by the test), or there might be bound nodes present
that were bound on a different matching branch.

Review: http://llvm-reviews.chandlerc.com/D112
llvm-svn: 167695

llvm-svn: 167694

llvm-svn: 167692

llvm-svn: 167690

llvm-svn: 167680

llvm-svn: 167679

lower 24bit is currently being used.

llvm-svn: 167678

CXXRecordDecl::forallBases, which does *not* do what I need. Fixes the
failure introduced in r167651.

llvm-svn: 167668

- New options '-mrtm'/'-mno-rtm' are added to enable/disable RTM feature
- Builtin macro '__RTM__' is defined if RTM feature is enabled
- RTM intrinsic header is added and introduces 3 new intrinsics, namely
  '_xbegin', '_xend', and '_xabort'.
- 3 new builtins are added to keep compatible with gcc, namely
  '__builtin_ia32_xbegin', '__builtin_ia32_xend', and '__builtin_ia32_xabort'.
- Test cases for pre-defined macro and new intrinsic codegen are added.

llvm-svn: 167665

llvm-svn: 167664

llvm-svn: 167662

Some holes in testing where discovered while working on the LLVM library
call simplifiers.

llvm-svn: 167661

The rationale is that there is no good workflow to silence the warning
for specific cases, other than using pragmas.  This is because the
attribute to decorate an explicit fall through is only available
in C++11.

By that argument, this should probably also be disabled unless one
is using C++11, but apparently there is an explicit test case for
this warning when using C++98.  This will require further discussion
on cfe-commits.

Fixes:  <rdar://problem/12584746>
llvm-svn: 167655

Previously, RegionStore was being VERY conservative in saying that because
p[i].x and p[i].y have a concrete base region of 'p', they might overlap.
Now, we check the chain of fields back up to the base object and check if
they match.

This only kicks in when dealing with symbolic offset regions because
RegionStore's "base+offset" representation of concrete offset regions loses
all information about fields. In cases where all offsets are concrete
(s.x and s.y), RegionStore will already do the right thing, but mixing
concrete and symbolic offsets can cause bindings to be invalidated that
are known to not overlap (e.g. p[0].x and p[i].y).
This additional refinement is tracked by <rdar://problem/12676180>.

<rdar://problem/12530149>

llvm-svn: 167654

Fix to regression caused by r167650, caught by Richard Smith in code review.

llvm-svn: 167653

would have diagnosed this at instantiation time anyway, if only we
didn't hang on all of these test cases. Fixes <rdar://problem/12629723>

llvm-svn: 167651

C++11 3.3.3/2 "A parameter name shall not be redeclared in the outermost block
of the function definition nor in the outermost block of any handler associated
with a function-try-block."

It's not totally clear to me whether the "FIXME" case is covered by this, but
Richard Smith thinks it probably should be. It's just a bit more involved to
fix that case.

llvm-svn: 167650

Make __LDBL_MAX__ etc. have the correct type on targets where long double/double/etc. have the same format.  PR14285.

Based on patch by Jeroen Dobbelaere.

llvm-svn: 167649

This warning was failing to fire under ARC because of the implicit
lifetime casts added around the object literal expression.

<rdar://problem/11300873>, again.

llvm-svn: 167648

Fixes bug 13354.

llvm-svn: 167647

Document -W in clang --help. Also make the help text more consistent (don't end descriptions in periods, use | to separate possible values).

llvm-svn: 167645

Don't include the help for -mips* in clang --help. These are just aliases for other options, and not common enough to be worth including here.

llvm-svn: 167644

only -W flag which clang --help lists.

llvm-svn: 167643

variable. Previously we didn't notice the type was dependent if the only
dependence came from an array bound.

Patch by Brian Brooks!

llvm-svn: 167642

llvm-svn: 167641

When installed, instead of getting this:

(lldb) p Tok.Loc
(clang::SourceLocation) $0 = {
  (unsigned int) ID = 123582
}

you'll get:

(lldb) p Tok.Loc
(clang::SourceLocation) $4 = "/usr/include/i386/_types.h:37:1" (offset: 123582, file)

This depends on r167629.

llvm-svn: 167640

llvm-svn: 167639

the driver (the options defined in CC1Options.td) and exclude their help from
"clang --help".

llvm-svn: 167638

llvm-svn: 167631