llvm-svn: 175166

Before:
aaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa()
                              .aaaaaaaaaaaaaaaaa());

After:
aaaaaaaaaaaaaaaaaaaaaaaaa(
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa().aaaaaaaaaaaaaaaaa());

Not sure which of the formattings above is better, but we should not pick
one by accident.

llvm-svn: 175165

The parser will now accept instructions with alignment specifiers written like
    vld1.8  {d16}, [r0:64]
, while also still accepting the incorrect syntax
    vld1.8  {d16}, [r0, :64]

llvm-svn: 175164

/proc/$PID/cmdline is clipped to 4Kb.
Locate argv and envp on the main thread stack.

llvm-svn: 175163

This gives a clearer separation of the context, e.g. in GMOCK
statements.

Before:
EXPECT_CALL(SomeObject,
            SomeFunction(Parameter)).WillRepeatedly(Return(SomeValue));

After:
EXPECT_CALL(SomeObject, SomeFunction(Parameter))
    .WillRepeatedly(Return(SomeValue));

Minor format cleanups.

llvm-svn: 175162

llvm-svn: 175161

llvm-svn: 175160

llvm-svn: 175159

llvm-svn: 175158

llvm-svn: 175157

llvm-svn: 175156

The test may hang now if a regression occurs.

llvm-svn: 175155

llvm-svn: 175153

So far, clang-format has always assumed the whitespace belonging to the
subsequent token. This has the negative side-effect that when
clang-format formats a line, it does not remove its trailing whitespace,
as it belongs to the next token.

Thus, this patch fixes most of llvm.org/PR15062.

We are not zapping a file's trailing whitespace so far, as this does not
belong to any token we see during formatting. We need to fix this in a
subsequent patch.

llvm-svn: 175152

The formatter can now format:
void aaaaaaaaaaaaaaaaaa(int level,
                        double *min_x,
                        double *max_x,
                        double *min_y,
                        double *max_y,
                        double *min_z,
                        double *max_z, ) {
}

Although this is invalid code, it frequently happens during development and
clang-format should be nicer :-).

llvm-svn: 175151

llvm-svn: 175150

Add some legality checks for SETCC before introducing it in the DAG combiner post-operand legalization.

llvm-svn: 175149

llvm-svn: 175148

This fixes llvm.org/PR15179.

Before:
class ColorChooserMac : public content::ColorChooser,
    public content::WebContentsObserver {
};

After:
class ColorChooserMac : public content::ColorChooser,
                        public content::WebContentsObserver {
};

llvm-svn: 175147

llvm-svn: 175146

We are still limited by /proc/*/cmdline size (4Kb max on Linux!).

llvm-svn: 175145

Added a test.

llvm-svn: 175144

llvm-svn: 175143

[asan] use short path for sanitizer_common/tests/sanitizer_test_utils.h, add -I sanitizer_common/tests to asan/tests/CMakeLists.txt

llvm-svn: 175142

The code generation stuff is going to set attributes on the functions it
generates. To do that it needs the target options. Pass them through.

llvm-svn: 175141

llvm-svn: 175140

Fixes assertion failure in newly added lit test. Might just be a bandaid that
needs to be revisited.

llvm-svn: 175139

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 175138

llvm-svn: 175137

"watchpoint set expression" fails if "--" is present without any option. Made this command match exactly what "expression" does.

llvm-svn: 175136

When launching in the shell, make sure if you specify a relative path, and if the current working directory has a space in it, that we don't hose the shell invocation.

Currently if we launch with a relative path, we prepend the current working directory to the PATH using:

PATH=`cwd`:$PATH a.out ...

We needed to add quotes around the value for PATH to make sure if any paths in PATH contained spaces, that we don't hose the shell command. Now we do a:

PATH="`cwd`:$PATH" a.out ...

llvm-svn: 175135

This reverts commit fd1335e982bbf93c5f450ed4fd29f9f787435c85.

Use a triple this time.

llvm-svn: 175134

llvm-svn: 175133

static functions in extern "C" contexts are mangled. Should fix the
bootstrap.

llvm-svn: 175132

When dumping instructions, resolve the address specified as a file address if the target doesn't have anything loaded.

llvm-svn: 175131

register class to match the defining instruction.

llvm-svn: 175130

llvm-svn: 175129

'and' instructions. This is a pattern that shows up a lot in ubsan binaries.

llvm-svn: 175128

<rdar://problem/13183944>

llvm-svn: 175127

up so that we can apply the direct object emitter patch. This patch
should be a nop right now and it's test is to not break what is already
there.
 

llvm-svn: 175126