summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGenCXX
Commit message (Collapse)AuthorAgeFilesLines
...
* Disable caching of visibility.Rafael Espindola2013-01-122-1/+60
| | | | | | | | | | | | | | The testcase in pr14929 shows that this is extremely hard to do. If we choose to apply the attribute, that causes the visibility of some decls to change and that can happen really late (during codegen). Current gcc warns and ignores the attribute in this testcase with a warning. This suggest that the correct solution is to find a point in the compilation where we can compute the visibility and * assert it was never computed before * reject any attempts to compute it again in the future (with warnings). llvm-svn: 172305
* Add -std=c++98 to the test and minor improvment in addition.Fariborz Jahanian2013-01-111-2/+2
| | | | llvm-svn: 172221
* Improve on my last test for patch for // rdar://12897704Fariborz Jahanian2013-01-111-0/+3
| | | | llvm-svn: 172154
* c++ IRGen. In trivial cases that object is going into staticFariborz Jahanian2013-01-101-0/+18
| | | | | | | | | | storage and thus is implicitly zero-initialized, no need to do C++11 memory model. This patch unconditionally detects such condition and zeroinitializer's the variable. Patch has been commented on and OKed by Doug off-line. // rdar://12897704 llvm-svn: 172144
* Don't assert in codegen on static data members which have NoLinkage. FixesNick Lewycky2013-01-101-0/+20
| | | | | | PR14825! llvm-svn: 172031
* Add [artificial] debug info annotation to test matching r171826David Blaikie2013-01-081-1/+1
| | | | llvm-svn: 171830
* PR14759: Improve/correct support for debug info for C++ member pointers.David Blaikie2013-01-071-0/+5
| | | | | | | | | | Using added LLVM functionality in r171698. This works in GDB for member variable pointers but not member function pointers. See the LLVM commit and GDB bug 14998 for details. Un-xfailing cases in the GDB 7.5 test suite will follow. llvm-svn: 171699
* Make checking for 'protected' access in debug info more legible.David Blaikie2013-01-051-1/+1
| | | | | | | Based on code review feedback for r171604 from Chandler Carruth & Eric Christopher. Enabled by improvements to LLVM made in r171636. llvm-svn: 171637
* PR14573: Unnamed parameters in debug info, Part 2David Blaikie2013-01-051-4/+11
| | | | | | | | Catch some cases I'd missed in r171605 related to unnamed parameters of record type. This resolves all remaining cases of PR14573 suppression in the GDB 7.5 test suite. Fix to the test suite to follow. llvm-svn: 171633
* Emit debug info for unnamed parameters.David Blaikie2013-01-051-2/+7
| | | | | | LLVM ignores this data for now - patch for that to follow. llvm-svn: 171605
* Change test/CodeGenCXX/debug-info-method.cpp an IR (rather than asm) test.David Blaikie2013-01-051-2/+2
| | | | | | | | Referring back to the original commit (r115090) which was a frontend only test I adjusted this test to verify the frontend change that was made, to emit the protected access value in the flags metadata field. llvm-svn: 171604
* FileCheck-ize test/CodeGenCXX/debug-info-method.cppDavid Blaikie2013-01-051-1/+2
| | | | llvm-svn: 171602
* Don't assert/crash on reference variables in lambdas bound to aEli Friedman2013-01-031-2/+13
| | | | | | static local variable from the parent scope. PR14773. llvm-svn: 171433
* [ubsan] Recover by default, use -fno-sanitize-recover to disable.Will Dietz2012-12-301-6/+6
| | | | llvm-svn: 171264
* Add 171048 back but invalidate the cache of all redeclarations when settingRafael Espindola2012-12-251-0/+12
| | | | | | | | | | | | | | | | | | the body of a functions. The problem was that hasBody looks at the entire chain and causes problems to -fvisibility-inlines-hidden if the cache was not invalidated. Original message: Cache visibility of decls. This unifies the linkage and visibility caching. I first implemented this when working on pr13844, but the previous fixes removed the performance advantage of this one. This is still a step in the right direction for making linkage and visibility cheap to use. llvm-svn: 171053
* Reinstate r170806, reverted in r170835, with a fix use i1 instead of i8 for ↵Richard Smith2012-12-212-0/+46
| | | | | | a value-initialized bool! llvm-svn: 170837
* Revert r170806, "Fix some bugs where we would sometimes use 0, not -1, when ↵NAKAMURA Takumi2012-12-211-40/+0
| | | | | | | | emitting a null constant of type pointer-to-data-member." It broke stage2. llvm-svn: 170835
* Fix some bugs where we would sometimes use 0, not -1, when emitting a null ↵Richard Smith2012-12-201-0/+40
| | | | | | constant of type pointer-to-data-member. llvm-svn: 170806
* Make sure CodeGen uses a value of the correct type as the result ofEli Friedman2012-12-191-0/+14
| | | | | | of assignment to a bool bitfield. PR14638. llvm-svn: 170480
* Rein ubsan's vptr sanitizer back a bit. Per core issue 453, binding a referenceRichard Smith2012-12-181-7/+11
| | | | | | to an object outside its lifetime does not have undefined behavior. llvm-svn: 170387
* Don't hit an assertion failure when calculating the __PRETTY_FUNCTION__Argyrios Kyrtzidis2012-12-141-1/+1
| | | | | | | | | | | | | | of a member function with parenthesized declarator. Like this test case: class Foo { const char *(baz)() { return __PRETTY_FUNCTION__; } }; llvm-svn: 170233
* clang/test/CodeGenCXX/lambda-expressions.cpp: Relax expression for -Asserts.NAKAMURA Takumi2012-12-141-2/+2
| | | | | | "entry:" is not met in -Asserts build. llvm-svn: 170175
* Make the test less sensitive to the inline threshold.Nadav Rotem2012-12-141-1/+1
| | | | llvm-svn: 170164
* Make sure the __invoke function for lambdas returns properly. Per bug ↵Eli Friedman2012-12-131-0/+9
| | | | | | report on IRC> llvm-svn: 170160
* Debug Info: Emit vtables pointer members as artificial.David Blaikie2012-12-131-2/+7
| | | | | | | | | | | | 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
* ubsan: Add -fsanitize=bool and -fsanitize=enum, which check for loads ofRichard Smith2012-12-131-1/+34
| | | | | | | bit-patterns which are not valid values for enumerated or boolean types. These checks are the ubsan analogue of !range metadata. llvm-svn: 170108
* Add a triple to this test. It depends on little-endian bitfield layout.Chandler Carruth2012-12-091-1/+1
| | | | llvm-svn: 169696
* Add a test case that I've been using to clarify the bitfield layout forChandler Carruth2012-12-091-0/+147
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix the bitfield record layout in codegen for big endian targets.Chandler Carruth2012-12-091-76/+162
| | | | | | | | | | | | | | | | | | 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
* Rework the bitfield access IR generation to address PR13619 andChandler Carruth2012-12-063-7/+205
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix name. The array is unboundED.Bill Wendling2012-12-051-1/+1
| | | | llvm-svn: 169429
* Use the 'count' attribute to calculate the upper bound of an array.Bill Wendling2012-12-042-2/+2
| | | | | | | | | 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
* Don't test for ASM output but for IR output.Bill Wendling2012-12-041-9/+6
| | | | llvm-svn: 169232
* clang/test/CodeGenCXX/debug-info-zero-length-arrays.cpp: Add explicit ↵NAKAMURA Takumi2012-12-041-1/+1
| | | | | | triple, x86_64-unknown-unknown. It was incompatible to i686. llvm-svn: 169220
* Add a 'count' field to the DWARF subrange.Bill Wendling2012-12-042-1/+17
| | | | | | | | | 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
* [ubsan] Add flag to enable recovery from checks when possible.Will Dietz2012-12-021-2/+6
| | | | llvm-svn: 169114
* Fix the determination of whether a capture refers to an enclosingDouglas Gregor2012-12-011-1/+12
| | | | | | scope when dealing with nested blocks. Fixes <rdar://problem/12778708>. llvm-svn: 169065
* Make the test less sensitive to DWARF emission implementation details.Eli Bendersky2012-11-291-2/+2
| | | | | | | Note: the ":" goes into the regex because FileCheck wrongly complains about unbalanced brackets otherwise. llvm-svn: 168934
* [-cxx-abi microsoft] Also spill the argument-back-references context when ↵Timur Iskhodzhanov2012-11-291-0/+2
| | | | | | mangling templates llvm-svn: 168862
* PR14388: An array or function type in an exception specification should beRichard Smith2012-11-281-0/+33
| | | | | | | decayed to a pointer type. Patch by WenHan Gu, with a little tweaking and additional testcases by me. llvm-svn: 168822
* Add -fsanitize=integer for reporting suspicious integer behaviors.Will Dietz2012-11-271-1/+1
| | | | | | Introduces new sanitizer "unsigned-integer-overflow". llvm-svn: 168701
* Remove outdated FIXME; should have removed that in r160782Timur Iskhodzhanov2012-11-271-2/+0
| | | | llvm-svn: 168698
* Fix PR14413 - incorrect mangling of anonymous namespaces with -cxx-abi microsoftTimur Iskhodzhanov2012-11-261-2/+9
| | | | llvm-svn: 168583
* PR14279: Work around this major miscompilation by treating move operations asRichard Smith2012-11-141-0/+32
| | | | | | | | 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
* Provide the correct mangling and linkage for certain unnamed nested classes.David Blaikie2012-11-142-9/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove another questionable use of hasTrivial*. The relevant thing for thisRichard Smith2012-11-141-1/+25
| | | | | | | test was whether the /selected/ operator= was trivial, not whether the class had any trivial (or any non-trivial) operator=s. llvm-svn: 167897
* Revert "Use the 'count' attribute instead of the 'upper_bound' attribute."Eric Christopher2012-11-131-1/+1
| | | | | | | | temporarily since it breaks the gdb bots. This reverts commit r167807/30305bec25cac981c6d4a3b8be004401310a82a7. llvm-svn: 167887
* Use the 'count' attribute instead of the 'upper_bound' attribute.Bill Wendling2012-11-131-1/+1
| | | | | | | | | 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
* Fix some wrong-code bugs in implicitly-defined assignment operators:Richard Smith2012-11-131-0/+21
| | | | | | | - 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
* Remove duplicated line.Rafael Espindola2012-11-121-1/+0
| | | | llvm-svn: 167767
OpenPOWER on IntegriCloud