summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGenCXX/stmtexpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
* LLVM IR: Generate new-style byval-with-Type from ClangTim Northover2019-06-051-1/+1
| | | | | | | | | | | LLVM IR recently added a Type parameter to the byval Attribute, so that when pointers become opaque and no longer have an element type the information will still be present in IR. For now the Type parameter is optional (which is why Clang didn't need this change at the time), but it will become mandatory soon. llvm-svn: 362652
* PR40642: Fix determination of whether the final statement of a statementRichard Smith2019-02-151-0/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | expression is a discarded-value expression. Summary: We used to get this wrong in three ways: 1) During parsing, an expression-statement followed by the }) ending a statement expression was always treated as producing the value of the statement expression. That's wrong for ({ if (1) expr; }) 2) During template instantiation, various kinds of statement (most statements not appearing directly in a compound-statement) were not treated as discarded-value expressions, resulting in missing volatile loads (etc). 3) In all contexts, an expression-statement with attributes was not treated as producing the value of the statement expression, eg ({ [[attr]] expr; }). Also fix incorrect enforcement of OpenMP rule that directives can "only be placed in the program at a position where ignoring or deleting the directive would result in a program with correct syntax". In particular, a label (be it goto, case, or default) should not affect whether directives are permitted. Reviewers: aaron.ballman, rjmccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57984 llvm-svn: 354090
* Sema: disable implicit conversion from _Complex to real types in C++.Tim Northover2017-08-081-1/+1
| | | | | | | | | | | Converting a _Complex type to a real one simply discards the imaginary part. This can easily lead to loss of information so for safety (and GCC compatibility) this patch disallows that when the conversion would be implicit. The one exception is bool, which actually compares both real and imaginary parts and so is safe. llvm-svn: 310427
* Don't try to spill static allocas when emitting expr cleanups with branchesReid Kleckner2017-05-311-1/+29
| | | | | | | | | | | | | | | | | | Credit goes to Gor Nishanov for putting together the fix in https://reviews.llvm.org/D33733! This patch is essentially me patching it locally and writing some test cases to convince myself that it was necessary for GNU statement expressions with branches as well as coroutines. I'll ask Gor to land his patch with just the coroutines test. During LValue expression evaluation, references can be bound to anything, really: call results, aggregate temporaries, local variables, global variables, or indirect arguments. We really only want to spill instructions that were emitted as part of expression evaluation, and static allocas are not that. llvm-svn: 304335
* Relax stmtexpr.cpp checks for PPC64Reid Kleckner2017-03-061-5/+5
| | | | llvm-svn: 297099
* Don't assume cleanup emission preserves dominance in expr evaluationReid Kleckner2017-03-061-0/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Because of the existence branches out of GNU statement expressions, it is possible that emitting cleanups for a full expression may cause the new insertion point to not be dominated by the result of the inner expression. Consider this example: struct Foo { Foo(); ~Foo(); int x; }; int g(Foo, int); int f(bool cond) { int n = g(Foo(), ({ if (cond) return 0; 42; })); return n; } Before this change, result of the call to 'g' did not dominate its use in the store to 'n'. The early return exit from the statement expression branches to a shared cleanup block, which ends in a switch between the fallthrough destination (the assignment to 'n') or the function exit block. This change solves the problem by spilling and reloading expression evaluation results when any of the active cleanups have branches. I audited the other call sites of enterFullExpression, and they don't appear to keep and Values live across the site of the cleanup, except in ARC code. I wasn't able to create a test case for ARC that exhibits this problem, though. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30590 llvm-svn: 297084
* Remove the -cxx-abi command-line flag.Hans Wennborg2014-01-141-1/+1
| | | | | | | | | | | | | | | This makes the C++ ABI depend entirely on the target: MS ABI for -win32 triples, Itanium otherwise. It's no longer possible to do weird combinations. To be able to run a test with a specific ABI without constraining it to a specific triple, new substitutions are added to lit: %itanium_abi_triple and %ms_abi_triple can be used to get the current target triple adjusted to the desired ABI. For example, if the test suite is running with the i686-pc-win32 target, %itanium_abi_triple will expand to i686-pc-mingw32. Differential Revision: http://llvm-reviews.chandlerc.com/D2545 llvm-svn: 199250
* Prepare for using MS ABI by default for Win32: update CodeGenCXX testsHans Wennborg2013-12-131-1/+1
| | | | llvm-svn: 197281
* Make sure we don't emit invalid IR for StmtExprs with complex cleanups.Eli Friedman2013-06-101-0/+7
| | | | | | Fixes <rdar://problem/14074868>. llvm-svn: 183699
* Whack a bunch of tests in CodeGenCXX to work on ARM (using ARM ABI). Batch ↵Eli Friedman2011-06-141-5/+5
| | | | | | 2 of 3. llvm-svn: 133011
* patch to do array-to-pointer conversion in aFariborz Jahanian2010-10-271-0/+10
| | | | | | statement-expression. // rdar: //8600553 llvm-svn: 117479
* Patch for mis-compile of statement expressions withFariborz Jahanian2010-10-251-0/+65
non-trivial copy constructors. // rdar: //8540501. A test will be added to llvm nightly tests. llvm-svn: 117324
OpenPOWER on IntegriCloud