llvm-svn: 169401

For most cases where a conversion specifier doesn't match an argument,
we usually guess that the conversion specifier is wrong. However, if
the argument is an integer type and the specifier is %C, it's likely
the user really did mean to print the integer as a character.

(This is more common than %c because there is no way to specify a unichar
literal -- you have to write an integer literal, such as '0x2603',
and then cast it to unichar.)

This does not change the behavior of %S, since there are fewer cases
where printing a literal Unicode *string* is necessary, but this could
easily be changed in the future.

<rdar://problem/11982013>

llvm-svn: 169400

No functionality change (the test change is a comment only, and the new
functionality can't be tested using the current test).

llvm-svn: 169399

The type of a character literal is 'int' in C, but if the user writes a
character /as/ a literal, we should assume they meant it to be a
character and not a numeric value, and thus offer %c as a correction
rather than %d.

There's a special case for multi-character literals (like 'MooV'), which
have implementation-defined value and usually cannot be printed with %c.
These still use %d as the suggestion.

In C++, the type of a character literal is 'char', and so this problem
doesn't exist.

<rdar://problem/12282316>

llvm-svn: 169398

We tried to account for 'uint8_t' by saying that /typedefs/ of 'char'
should be corrected as %hhd rather than %c, but the condition was wrong.

llvm-svn: 169397

Also use the portable (ugly) format string macros, for MSVC compatibility.

llvm-svn: 169396

A MachineInstr can only ever be constructed by CreateMachineInstr() and
CloneMachineInstr(), and those factories don't use the removed
constructors.

llvm-svn: 169395

llvm-svn: 169394

This is for the lldb team so most of but not all of the values are
to be printed as hex with this option.  Some small values like the
scale in an X86 address were requested to printed in decimal
without the leading 0x.

There may be some tweaks need to places that may still be in
decimal that they want in hex.  Specially for arm.  I made my best
guess.  Any tweaks from here should be simple.

I also did the best I know now with help from the C++ gurus
creating the cleanest formatImm() utility function and containing
the changes.  But if someone has a better idea to make something
cleaner I'm all ears and game for changing the implementation.

rdar://8109283

llvm-svn: 169393

llvm-svn: 169392

- Added calls to doInitialization/doFinalization to immutable passes
- fixed ordering of calls to doFinalization to be the reverse of the pass run order due to potential dependencies
- fixed machine module info to operate in the doInitialization/doFinalization model, also fixes some FIXMEs

reviewed by Evan Cheng <evan.cheng@apple.com>

llvm-svn: 169391

llvm-svn: 169390

Summary: Adds support for formatting for and while loops.

Reviewers: djasper, klimek

Reviewed By: klimek

CC: cfe-commits

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

llvm-svn: 169387

- Fix behavior of memoization together with optimization
- Correctly attribute the PenaltyIndentLevel (breaking directly after "(" did
  not count towards the inner level)
- Recognize more tokens as assignments

Review: http://llvm-reviews.chandlerc.com/D172
llvm-svn: 169384

llvm-svn: 169383

Follow-up to r169286, addresses comments in http://llvm-reviews.chandlerc.com/D164#comment-4 : comments and a method rename

llvm-svn: 169382

llvm-svn: 169381

Add a diagnosting for -fsanitize=memory conflicting with other sanitizers.
Extend tests.

llvm-svn: 169380

llvm-svn: 169379

This mirrors the change in ASan & TSan done in r168864.

llvm-svn: 169378

LinkOnceODRLinkage globals may be removed in GlobalOpt if not used in the
current module.

llvm-svn: 169377

that way we allow static linking of libstdc++

llvm-svn: 169376

llvm-svn: 169375

Our error recovery path may have made the class anonymous, and that has a pretty
disastrous impact on any attempt to parse a class body containing constructors.

llvm-svn: 169374

the LHS of a token paste. Use "expanded from here" instead when we're not sure
it's actually a macro.

llvm-svn: 169373

llvm-svn: 169371

llvm-svn: 169370

llvm-svn: 169369

[tsan] get rid of *allocator64* files, moving everything to *allocator* files. This will help with the 32-bit allocator implementation and testing

llvm-svn: 169368

llvm-svn: 169367

Generate VPBLENDD for AVX2 and VPBLENDW for v16i16 type on AVX2.

llvm-svn: 169366

llvm-svn: 169365

Reads a single source range (offset, length) as well as the style guide
as parameters and then reformats everything it receives from stdin.

llvm-svn: 169364

Recognize '!=' as a binary operator and assume that there are no
type definitions on the RHS of an assignment.

llvm-svn: 169363

llvm-svn: 169362

[tsan] make the 64-bit allocator build (but not work) in 32-bit mode to simplify the code and test structure and allow further refactoring

llvm-svn: 169361

At build-time register pressure was always computed in terms of
register units. But the compile-time API was expressed in terms of
register classes because it was intended for virtual registers (and
physical register units weren't yet used anywhere in codegen).

Now that the codegen uses physreg units consistently, prepare for
tracking register pressure also in terms of live units, not live
registers.

llvm-svn: 169360

llvm-svn: 169359

llvm-svn: 169358

diagnostic from the emission of macro backtraces. Incidentally, we now get the
displayed source location for a diagnostic and the location for the caret from
the same place, rather than computing them separately. No functionality change.

llvm-svn: 169357