which will appear in the vtable as used, not just those ones which were
declared within the class itself. Fixes an issue reported as comment#3 in
PR12763 -- we sometimes assert in codegen if we try to emit a reference to a
function declaration which we've not marked as referenced. This also matches
gcc's observed behavior.

llvm-svn: 159895

in the ABI arrangement, and leave a hook behind so that we can easily
tweak CCs on platforms that use different CCs by default for C++
instance methods.

llvm-svn: 159894

Enhance 'diagtool list-warnings' to report number of diagnostics covered directly under -Wpedantic, and enhance warning-flags.c test to test that this set does not grow.

llvm-svn: 159893

- Split pedantic driver flag test into separate test file, and XFAIL on cygwin,mingw32
- Fix bug in tablegen logic where a missing '{' caused errors to be included in -Wpedantic.

llvm-svn: 159892

subtarget CPU descriptions and support new features of
MachineScheduler.

MachineModel has three categories of data:
1) Basic properties for coarse grained instruction cost model.
2) Scheduler Read/Write resources for simple per-opcode and operand cost model (TBD).
3) Instruction itineraties for detailed per-cycle reservation tables.

These will all live side-by-side. Any subtarget can use any
combination of them. Instruction itineraries will not change in the
near term. In the long run, I expect them to only be relevant for
in-order VLIW machines that have complex contraints and require a
precise scheduling/bundling model. Once itineraries are only actively
used by VLIW-ish targets, they could be replaced by something more
appropriate for those targets.

This tablegen backend rewrite sets things up for introducing
MachineModel type #2: per opcode/operand cost model.

llvm-svn: 159891

llvm-svn: 159890

llvm-svn: 159889

It is safe if EFLAGS is killed or re-defined.
When we are done with the basic block, check whether EFLAGS is live-out.
Do not optimize away cmp if EFLAGS is live-out.

llvm-svn: 159888

Thanks to Kai.

llvm-svn: 159887

Revert rr159875, "Implement -Wpedantic and --no-pedantic to complement -Weverything." It broke several builds.

I suspect FileCheck might match assertion failure, even if clang/test/Misc/warning-flags.c passed the test.

> 0. Program arguments: bin/./clang -### -pedantic -Wpedantic clang/test/Driver/warning-options.cpp

llvm-svn: 159886

context is not returning valid registers yet.  Don't
crash in these situations.

<rdar://problem/11650335>

llvm-svn: 159885

Fixed a crasher where the section load list was not thread safe.

llvm-svn: 159884

Modified the heap.py to be able to correctly indentify the exact ivar for the "ptr_refs" command no matter how deep the ivar is in a class hierarchy. Also fixed the ability for the heap command to symbolicate the stack backtrace when MallocStackLogging is set in the environment and the "--stack" option was specified.

llvm-svn: 159883

a NULL symbol file.

<rdar://problem/11795939>

llvm-svn: 159882

llvm-svn: 159881

didn't check if the two classes had the same number
of members.

<rdar://problem/11678873>

llvm-svn: 159880

llvm-svn: 159879

llvm-svn: 159878

should be camel case, and start with a lower case letter.

llvm-svn: 159877

teach instcombine to remove allocated buffers even if there are stores, memcpy/memmove/memset, and objectsize users.
This means we can do cheap DSE for heap memory.
Nothing is done if the pointer excapes or has a load.

The churn in the tests is mostly due to objectsize, since we want to make sure we
don't delete the malloc call before evaluating the objectsize (otherwise it becomes -1/0)

llvm-svn: 159876

This patch introduces some magic in tablegen to create a "Pedantic" diagnostic
group which automagically includes all warnings that are extensions.  This
allows a user to suppress specific warnings traditionally under -pedantic used
an ordinary warning flag.  This also allows users to use #pragma to silence
specific -pedantic warnings, or promote them to errors, within blocks of text
(just like any other warning).

-Wpedantic is NOT an alias for -pedantic.  Instead, it provides another way
to (a) activate -pedantic warnings and (b) disable them.  Where they differ
is that -pedantic changes the behavior of the preprocessor slightly, whereas
-Wpedantic does not (it just turns on the warnings).

The magic in the tablegen diagnostic emitter has to do with computing the minimal
set of diagnostic groups and diagnostics that should go into -Wpedantic, as those
diagnostics that already members of groups that themselves are (transitively) members
of -Wpedantic do not need to be included in the Pedantic group directly.  I went
back and forth on whether or not to magically generate this group, and the invariant
was that we always wanted extension warnings to be included in -Wpedantic "some how",
but the bookkeeping would be very onerous to manage by hand.

-no-pedantic (and --no-pedantic) is included for completeness, and matches many of the
same kind of flags the compiler already supports.  It does what it says: cancels out
-pedantic.  One discrepancy is that if one specifies --no-pedantic and -Weverything or
-Wpedantic the pedantic warnings are still enabled (essentially the -W flags win).  We
can debate the correct behavior here.

Along the way, this patch nukes some code in TextDiagnosticPrinter.cpp and CXStoredDiagnostic.cpp
that determine whether to include the "-pedantic" flag in the warning output.  This is
no longer needed, as all extensions now have a -W flag.

This patch also significantly reduces the number of warnings not under flags from 229
to 158 (all extension warnings).  That's a 31% reduction.

llvm-svn: 159875

llvm-svn: 159874

llvm-svn: 159873

llvm-svn: 159869

This allows SourceLocations to be stored in generic "data" fields
that are typed as "const void *" and are also used to point to
const objects.

Really we should probably be returning a const pointer from
getPtrEncoding as well, but in some places we want to store
SourceLocations in the same generic "data" field as proper
pointers to /mutable/ objects. Oh well.

llvm-svn: 159868

No functionality change.

llvm-svn: 159867

We use LazyCompoundVals to avoid copying the contents of structs and arrays
around in the store, and when we need to pass a struct around that already
has a LazyCompoundVal we just use the original one. However, it's possible
that the first field of a struct may have a LazyCompoundVal of its own, and
we currently can't distinguish a LazyCompoundVal for the first element of a
struct from a LazyCompoundVal for the entire struct. In this case we should
just drop the optimization and make a new LazyCompoundVal that encompasses
the old one.

PR13264 / <rdar://problem/11802440>

llvm-svn: 159866

llvm-svn: 159865

llvm-svn: 159864

llvm-svn: 159860

a 'weak' property just as we do the same for
'weak' variables. // rdar://11814185

llvm-svn: 159859

As a conforming extension give tuple a noexcept default constructor conditionalized on its held types.

llvm-svn: 159858

llvm-svn: 159857

llvm-svn: 159856

llvm-svn: 159854

llvm-svn: 159852

Include file MipsGenRegisterInfo.inc.

llvm-svn: 159851

llvm-svn: 159850

llvm-svn: 159849

llvm-svn: 159848