llvm-svn: 170160

I wasn't sure where to put the test case for this, but this seemed like as good
a place as any. I had to reorder the tests here to make them legible while
still matching the order of metadata output in the IR file (for some reason
making it virtual changed the ordering).

Relevant commit to fix up LLVM to actually respect 'artificial' member
variables is coming once I write up a test case for it.

llvm-svn: 170154

bit-patterns which are not valid values for enumerated or boolean types.
These checks are the ubsan analogue of !range metadata.

llvm-svn: 170108

llvm-svn: 169696

both LE and BE targets.

AFAICT, Clang get's this correct for PPC64. I've compared it to GCC 4.8
output for PPC64 (thanks Roman!) and to my limited ability to read power
assembly, it looks functionally equivalent. It would be really good to
fill in the assertions on this test case for x86-32, PPC32, ARM, etc.,
but I've reached the limit of my time and energy... Hopefully other
folks can chip in as it would be good to have this in place to test any
subsequent changes.

To those who care about PPC64 performance, a side note: there is some
*obnoxiously* bad code generated for these test cases. It would be worth
someone's time to sit down and teach the PPC backend to pattern match
these IR constructs better. It appears that things like '(shr %foo,
<imm>)' turn into 'rldicl R, R, 64-<imm>, <imm>' or some such. They
don't even get combined with other 'rldicl' instructions *immediately
adjacent*. I'll add a couple of these patterns to the README, but
I think it would be better to look at all the patterns produced by this
and other bitfield access code, and systematically build up a collection
of patterns that efficiently reduce them to the minimal code.

llvm-svn: 169693

This was an egregious bug due to the several iterations of refactorings
that took place. Size no longer meant what it original did by the time
I finished, but this line of code never got updated. Unfortunately we
had essentially zero tests for this in the regression test suite. =[

I've added a PPC64 run over the bitfield test case I've been primarily
using. I'm still looking at adding more tests and making sure this is
the *correct* bitfield access code on PPC64 linux, but it looks pretty
close to me, and it is *worlds* better than before this patch as it no
longer asserts! =] More commits to follow with at least additional tests
and maybe more fixes.

Sorry for the long breakage due to this....

llvm-svn: 169691

generally support the C++11 memory model requirements for bitfield
accesses by relying more heavily on LLVM's memory model.

The primary change this introduces is to move from a manually aligned
and strided access pattern across the bits of the bitfield to a much
simpler lump access of all bits in the bitfield followed by math to
extract the bits relevant for the particular field.

This simplifies the code significantly, but relies on LLVM to
intelligently lowering these integers.

I have tested LLVM's lowering both synthetically and in benchmarks. The
lowering appears to be functional, and there are no really significant
performance regressions. Different code patterns accessing bitfields
will vary in how this impacts them. The only real regressions I'm seeing
are a few patterns where the LLVM code generation for loads that feed
directly into a mask operation don't take advantage of the x86 ability
to do a smaller load and a cheap zero-extension. This doesn't regress
any benchmark in the nightly test suite on my box past the noise
threshold, but my box is quite noisy. I'll be watching the LNT numbers,
and will look into further improvements to the LLVM lowering as needed.

llvm-svn: 169489

llvm-svn: 169429

The count attribute is more accurate with regards to the size of an array. It
also obviates the upper bound attribute in the subrange. We can also better
handle an unbound array by setting the count to -1 instead of the lower bound to
1 and upper bound to 0.

llvm-svn: 169311

llvm-svn: 169232

clang/test/CodeGenCXX/debug-info-zero-length-arrays.cpp: Add explicit triple, x86_64-unknown-unknown. It was incompatible to i686.

llvm-svn: 169220

The count field is necessary because there isn't a difference between the 'lo'
and 'hi' attributes for a one-element array and a zero-element array. When the
count is '0', we know that this is a zero-element array. When it's >=1, then
it's a normal constant sized array. When it's -1, then the array is unbounded.

llvm-svn: 169219

llvm-svn: 169114

scope when dealing with nested blocks. Fixes <rdar://problem/12778708>.

llvm-svn: 169065

Note: the ":" goes into the regex because FileCheck wrongly complains about
unbalanced brackets otherwise.

llvm-svn: 168934

llvm-svn: 168862

decayed to a pointer type. Patch by WenHan Gu, with a little tweaking and
additional testcases by me.

llvm-svn: 168822

Introduces new sanitizer "unsigned-integer-overflow".

llvm-svn: 168701

llvm-svn: 168698

llvm-svn: 168583

non-trivial if they would not call a move operation, even if they would in fact
call a trivial copy operation. A proper fix is to follow, but this small
directed fix is intended for porting to the 3.2 release branch.

llvm-svn: 167920

This corrects the mangling and linkage of classes (& their member functions) in
cases like this:

  struct foo {
    struct {
      void func() { ... }
    } x;
  };

we were accidentally giving this nested unnamed struct 'no' linkage where it
should've had the linkage of the outer class. The mangling was incorrecty too,
mangling as TU-wide unnamed type mangling of $_X rather than class-scoped
mangling of UtX_.

This also fixes -Wunused-member-function which would incorrectly diagnose
'func' as unused due to it having no linkage & thus appearing to be TU-local
when in fact it might be correctly used in another TU.

Similar mangling should be applied to function local classes in similar cases
but I've deferred that for a subsequent patch.

Review/discussion by Richard Smith, John McCall, & especially Eli Friedman.

llvm-svn: 167906

test was whether the /selected/ operator= was trivial, not whether the class
had any trivial (or any non-trivial) operator=s.

llvm-svn: 167897

temporarily since it breaks the gdb bots.

This reverts commit r167807/30305bec25cac981c6d4a3b8be004401310a82a7.

llvm-svn: 167887

If we have a type 'int a[1]' and a type 'int b[0]', the generated DWARF is the
same for both of them because we use the 'upper_bound' attribute. Instead use
the 'count' attrbute, which gives the correct number of elements in the array.
<rdar://problem/12566646>

llvm-svn: 167807

 - In C++11, perform overload resolution over all assignment operators, rather than just looking for copy/move assignment operators.
 - Clean up after temporaries produced by operator= immediately, rather than accumulating them until the end of the function.

llvm-svn: 167798

llvm-svn: 167767

internal linkage, no uses, trivial construction, and nontrivial destruction
were not emitted.

llvm-svn: 167756

Do this by making the mangleNumber(APSInt) overload look like
the int64_t version. (The latter should probably just delegate
to the former).

Test from Evgeny Eltsin!

llvm-svn: 167599

at whether the *selected* constructor would be trivial rather than considering
whether the array's element type has *any* non-trivial constructors of the
relevant kind.

llvm-svn: 167562

works between the modules.
No functionality change on Darwin/Windows.
This fixes PR11480.

llvm-svn: 167496

checks to enable. Remove frontend support for -fcatch-undefined-behavior,
-faddress-sanitizer and -fthread-sanitizer now that they don't do anything.

llvm-svn: 167413

llvm-svn: 167336

llvm-svn: 167308

test/CodeGenCXX/member-alignment.cpp.  The test succeeds for
powerpc64-unknown-linux-gnu.  If other flavors of powerpc are
shown by buildbots to still be broken, we can adjust the test
at that time.

llvm-svn: 167143

doesn't include padding up to the alignment of the record, take this
as a cue that the alignment of the record should (conservatively) be
set to 1. This is similar to other the other cues we use to determine
that the record has a lower alignment, e.g., that the
externally-supplied layout places fields at lower offsets than we
would. Fixes <rdar://problem/12582052>; test case in LLDB.

llvm-svn: 166824

llvm-svn: 166758

llvm-svn: 166735

LLVM's hashing routines produce a size_t, and thus generate different values for 32- and 64-bit host compilers. This really needs to be fixed -- the IR generated should not depend on the host -- but this change will get the bots green again. Proper fix to follow.

llvm-svn: 166731

llvm-svn: 166727