llvm-svn: 84723

llvm-svn: 84063

llvm-svn: 84025

llvm-svn: 84019

llvm-svn: 83933

producing any stores at all for a long time, but ".store." was in some
IR instruction names until recently.  This removal caused the test to
start failing.  Just make it reject any stores.

llvm-svn: 83895

llvm-svn: 83234

llvm-svn: 82731

llvm-svn: 82658

llvm-svn: 81432

of using llvm-as, now that opt supports this.

llvm-svn: 81226

(%llvmgcc includes a '-w' argument, and this test looks for warnings).

llvm-svn: 81152

although I don't think anyone cares about this
feature except Darwin.  PR 4825.

llvm-svn: 80596

llvm-svn: 79992

llvm-svn: 79614

llvm-svn: 79607

llvm-svn: 79598

llvm-svn: 78763

llvm-svn: 78758

llvm-svn: 78703

testing mode it won't test much).

llvm-svn: 78325

llvm-gcc checks the static asm variable is valid in ValidateRegisterVariable. Make this work for PPC.

llvm-svn: 78051

llvm-svn: 78042

llvm-svn: 78038

on darwin with ".cstring" instead of ".section  __TEXT,__cstring".  They
are the same and the former is better.  Remove this because this is no longer
magic pixie dust in the frontend.

llvm-svn: 77055

llvm-svn: 76920

llvm-svn: 76868

llvm-svn: 76174

llvm-svn: 75827

llvm-svn: 75824

llvm-svn: 75777

llvm-svn: 75655

different for ppc; add another version of the test.

llvm-svn: 73983

generating LLVM IR; it is correct in the code as written
to use 8-byte-aligned operations to copy Key in bar.  Formerly
the gcc inliner was run, now it isn't.  I don't think it's
possible to preserve this as a pure FE test.  Adding -O2 lets
the llvm optimizers get rid of the 8-byte-aligned stores, at least.

llvm-svn: 73981

generated code was apparently doing stores directly into the return value
aggregate; now, it's doing a copy from a compiler-generated static object.
That object is initialized using [4 x i8] which breaks the test.  I believe
this change preserves the original point of the test.

Of course it would be better for the code to do stores directly into the
return aggregate, but that is not what happens at -O0; the llvm optimizers
seem to do that on x86 but not on ppc32, possibly because of the explicit
padding (which is unavoidable).  I think it must have been being done by
a gcc optimizer pass before.

llvm-svn: 73972

llvm-svn: 73729

llvm-svn: 73353

of the target's pointer size. This avoids the need for -m32 on
the llvm-gcc command-line, which some targets may not support.

llvm-svn: 73270

on systems which default to a 64-bit target.

llvm-svn: 73265

llvm-svn: 73239