@@ -5055,6 +5055,7 @@ void ItaniumCXXABI::emitBeginCatch(CodeGenFunction &CGF,
// Emit the local.
CodeGenFunction::AutoVarEmission var = CGF.EmitAutoVarAlloca(*CatchParam);
+ ApplyAtomGroup Grp(CGF.getDebugInfo());
InitCatchParam(CGF, *CatchParam, var.getObjectAddress(
https://github.com/jmorse approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/134643
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,51 @@
+// RUN: %clang_cc1 -gkey-instructions -x c++ -std=c++17 %s
-debug-info-kind=line-tables-only -emit-llvm -o - \
+// RUN: | FileCheck %s --implicit-check-not atomGroup --implicit-check-not
atomRank --check-prefixes=CHECK,CHECK-CXX
+
+// RUN: %clang_cc1 -gkey-inst
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/134643
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse approved this pull request.
(LGTM with the braces)
https://github.com/llvm/llvm-project/pull/134641
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/134638
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse approved this pull request.
Much clearer, LGTM thanks!
https://github.com/llvm/llvm-project/pull/134632
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse commented:
I suppose what this is encoding is a (subtle?) assumption about how
definition-subprograms are modelled: they're created once and are immutable.
Wheras declaration-functions can be forwarded declared and then have extra
information added to them when a def
https://github.com/jmorse approved this pull request.
LGTM then, in practice we always get bitten by commandlines + LTO sooner or
later, so I'm confident we'll end up doing-the-right-thing anyway after
breaking our internal CI a few times.
https://github.com/llvm/llvm-project/pull/134627
_
https://github.com/jmorse commented:
On the whole this looks fine to me with a final nit
https://github.com/llvm/llvm-project/pull/130255
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/130255
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1816,6 +1816,15 @@ class CodeGenModule : public CodeGenTypeCache {
void requireVectorDestructorDefinition(const CXXRecordDecl *RD);
bool classNeedsVectorDestructor(const CXXRecordDecl *RD);
+ // Helper to get the alignment for a variable.
+ unsigned getGlobalVarAlign
jmorse wrote:
It sounds like there's agreement that the "before" approach was
better/acceptable, i.e. having a CU-level variable that refers by
`DW_AT_specification` to a variable in the class type. Doing so would also
avoid the customisation for vtable-addresses in the latest patch with the
https://github.com/jmorse closed
https://github.com/llvm/llvm-project/pull/111836
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jmorse wrote:
/me squints -- this was a minor improvement and I've lost all the context
behind it, abandoning as it's not worth revisiting IMO
https://github.com/llvm/llvm-project/pull/111836
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
htt
jmorse wrote:
> To solve this problem in general, it would probably(?) be best to make SROA
> create fragment #dbg_value records if it decomposes an alloca into multiple
> IR values but I have no idea how difficult that would be to accomplish.
An example of this happening today with C++ struct
jmorse wrote:
There's precedent for splitting the debug-info into fragments early, we do
something similar for C++ structured-bindings in SROA and a very similar
process happens when the i128 argument is split up in instruction-selection.
Split-up locations become brittle to optimisations thou
https://github.com/jmorse approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/126967
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse approved this pull request.
LGTM too; thanks for running with this!
https://github.com/llvm/llvm-project/pull/126059
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-c
@@ -1708,19 +1706,9 @@ static void insertDbgValueOrDbgVariableRecord(DIBuilder
&Builder, Value *DV,
static void insertDbgValueOrDbgVariableRecordAfter(
DIBuilder &Builder, Value *DV, DILocalVariable *DIVar, DIExpression
*DIExpr,
-const DebugLoc &NewLoc, BasicBlock::i
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/126059
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse commented:
This looks great, thanks for putting this all together, one nit inline,
Is this intended to be cherry-picked into the release branch or not? Seeing how
the original motivation was to ease downstream compatibilities, I'd assumed
there'd be the need for somet
https://github.com/jmorse approved this pull request.
LGTM on the belief that `-fextend-this-ptr-liveness` hasn't been in the driver
for very long at all -- if that isn't the case, we end up having to ask
questions about supporting it.
https://github.com/llvm/llvm-project/pull/124767
_
https://github.com/jmorse closed
https://github.com/llvm/llvm-project/pull/124288
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jmorse wrote:
Merged in 285009f202ca as it was composing with a workaround in an earlier
commit.
https://github.com/llvm/llvm-project/pull/124288
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
Author: Jeremy Morse
Date: 2025-01-27T20:30:45Z
New Revision: 285009f202ca8bfcc6b607eba0e919867559e725
URL:
https://github.com/llvm/llvm-project/commit/285009f202ca8bfcc6b607eba0e919867559e725
DIFF:
https://github.com/llvm/llvm-project/commit/285009f202ca8bfcc6b607eba0e919867559e725.diff
LOG:
https://github.com/jmorse updated
https://github.com/llvm/llvm-project/pull/124288
>From b60342427447c46d646d3de5b91fcbdbcb8585d3 Mon Sep 17 00:00:00 2001
From: Jeremy Morse
Date: Thu, 23 Jan 2025 17:06:04 +
Subject: [PATCH 1/2] [NFC][DebugInfo] Rewrite more call-sites to insert with
itera
@@ -823,7 +823,16 @@ static void updateScopeLine(Instruction *ActiveSuspend,
if (!ActiveSuspend)
return;
- auto *Successor = ActiveSuspend->getNextNonDebugInstruction();
+ // No subsequent instruction -> fallback to the location of ActiveSuspend.
+ if (!ActiveSuspend-
https://github.com/jmorse closed
https://github.com/llvm/llvm-project/pull/124291
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jmorse wrote:
Ta; fixed some of the clang-format errors that are on lines that I've touched,
however I'm leaving the clang-format errors that are adjacent (there are some
pre-existing indentation issues too it seems).
https://github.com/llvm/llvm-project/pull/124291
___
https://github.com/jmorse updated
https://github.com/llvm/llvm-project/pull/124291
>From 8bafca72573c7ba5e7b7711c5168e0609571661f Mon Sep 17 00:00:00 2001
From: Jeremy Morse
Date: Thu, 23 Jan 2025 14:18:55 +
Subject: [PATCH 1/2] [NFC][DebugInfo] Use iterators for instruction insertion
in m
https://github.com/jmorse commented:
This looks good, but I'd like to reword some of it
https://github.com/llvm/llvm-project/pull/118026
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -412,6 +412,20 @@ New Compiler Flags
only for thread-local variables, and none (which corresponds to the
existing ``-fno-c++-static-destructors`` flag) skips all static
destructors registration.
+- The ``-fextend-variable-liveness`` flag has been added to allow for imp
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/118026
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4298,6 +4298,26 @@ def stack_usage_file : Separate<["-"],
"stack-usage-file">,
Visibility<[CC1Option]>,
HelpText<"Filename (or -) to write stack usage output to">,
MarshallingInfoString>;
+def fextend_variable_liveness_EQ : Joined<["-"], "fextend-variable-liveness=">
@@ -412,6 +412,20 @@ New Compiler Flags
only for thread-local variables, and none (which corresponds to the
existing ``-fno-c++-static-destructors`` flag) skips all static
destructors registration.
+- The ``-fextend-variable-liveness`` flag has been added to allow for imp
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3595,15 +3595,26 @@ static llvm::StoreInst
*findDominatingStoreToReturnValue(CodeGenFunction &CGF) {
llvm::BasicBlock *IP = CGF.Builder.GetInsertBlock();
if (IP->empty()) return nullptr;
-// Look at directly preceding instruction, skipping bitcasts and lifetim
https://github.com/jmorse approved this pull request.
LGTM with an inline question that's probably me misunderstanding something.
https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llv
https://github.com/jmorse created
https://github.com/llvm/llvm-project/pull/124291
As part of the "RemoveDIs" work to eliminate debug intrinsics, we're replacing
methods that use Instruction*'s as positions with iterators. This patch changes
some more complex call-sites, those crossing file bo
https://github.com/jmorse created
https://github.com/llvm/llvm-project/pull/124288
As part of the "RemoveDIs" work to eliminate debug intrinsics, we're replacing
methods that use Instruction*'s as positions with iterators. The call-sites
updated in this patch are those where the dyn_cast_or_nu
https://github.com/jmorse closed
https://github.com/llvm/llvm-project/pull/123737
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse updated
https://github.com/llvm/llvm-project/pull/123737
>From 36f969cc26363da7a6a109538d27af2c1d4f59f8 Mon Sep 17 00:00:00 2001
From: Jeremy Morse
Date: Fri, 17 Jan 2025 17:49:05 +
Subject: [PATCH 1/3] [NFC][DebugInfo] Use iterator-flavour getFirstNonPHI at
many
jmorse wrote:
> Regarding the direction of the patch, it seems a little unfortunate to
> completely remove getFirstNonPHI() - sometimes we want the instruction and
> sometimes we want the iterator, and forcing all of them to go through
> getFirstNonPHIIt() may increase the chances that the it
https://github.com/jmorse updated
https://github.com/llvm/llvm-project/pull/123737
>From f88945b08138e01601121bcdf4dd4893bed21a90 Mon Sep 17 00:00:00 2001
From: Jeremy Morse
Date: Fri, 17 Jan 2025 17:49:05 +
Subject: [PATCH 1/3] [NFC][DebugInfo] Use iterator-flavour getFirstNonPHI at
many
https://github.com/jmorse updated
https://github.com/llvm/llvm-project/pull/123737
>From f88945b08138e01601121bcdf4dd4893bed21a90 Mon Sep 17 00:00:00 2001
From: Jeremy Morse
Date: Fri, 17 Jan 2025 17:49:05 +
Subject: [PATCH 1/2] [NFC][DebugInfo] Use iterator-flavour getFirstNonPHI at
many
https://github.com/jmorse closed
https://github.com/llvm/llvm-project/pull/123583
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jmorse wrote:
If it's alright, I'll deal with the comment and different-arg-name matters in a
follow up commit -- I've got rewrite those areas for deprecation anyway. Also
force pushing a rebased commit because I don't trust what github will do with
merging main into this.
https://github.com/
@@ -448,7 +448,7 @@ void IRPromoter::ExtendSources() {
if (isa(V))
I->moveBefore(InsertPt);
else
-I->moveAfter(InsertPt);
+I->moveAfter(&*InsertPt);
jmorse wrote:
Good question on this and the other item; I think the most im
https://github.com/jmorse approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/123930
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -174,25 +174,26 @@
// Test implicit library search paths are supplied to the linker, after any
// search paths specified by the user. /target/lib is implicitly
-// added if it exists and no --sysroot is specified. CRT objects are found
-// there. "." is always implicitly ad
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/123350
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse approved this pull request.
LGTM with a comment inline
https://github.com/llvm/llvm-project/pull/123350
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -174,25 +174,26 @@
// Test implicit library search paths are supplied to the linker, after any
// search paths specified by the user. /target/lib is implicitly
-// added if it exists and no --sysroot is specified. CRT objects are found
-// there. "." is always implicitly ad
https://github.com/jmorse created
https://github.com/llvm/llvm-project/pull/123737
(NB: this will fail CI as it composes with #123583, but I'm not gluing them
together or it'll be too hard to review).
As part of the "RemoveDIs" project, BasicBlock::iterator now carries a
debug-info bit that's
jmorse wrote:
(" it lacks the DW_AT_abstract_origin that gcc produces..." for the
DW_TAG_lexical_scopes referring back to the abstract/declaration subprogram).
https://github.com/llvm/llvm-project/pull/119001
___
cfe-commits mailing list
cfe-commits@l
jmorse wrote:
Indeed @ the language, it's difficult to know that this is definitely going to
work when I don't have a full understanding of the patch series, thus the
caution,
I've studied a bit further and even with the full patch series we seem to be
missing an important link. Here's a gist
jmorse wrote:
> Ah, fair enough, because the subprogram will contian a list of these local
> types, then the local type's scope will be a (potentially series of) lexical
> scope - so the lexical scopes are preserved?
That's certainly the outcome that the original patch series is aiming for --
jmorse wrote:
> Maybe it's too big/complex a problem to try to think about, and incremental
> development should overrule here - but may be worth thinking about?
Urgh. I'll admit that I hadn't thought that far ahead, I just wanted to get the
patch-series going again now that the root problem i
jmorse wrote:
I've placed a re-application of this code in #119001, along with a commit that
attempts to fix the matter discovered here. To avoid multiple DICompositeTypes
in multiple DISubprograms being ODRUnique'd, we instead put them in the
declaration DISubprogram which should be unique'd
@@ -112,11 +112,11 @@ void EHScopeStack::deallocate(size_t Size) {
StartOfData += llvm::alignTo(Size, ScopeStackAlignment);
}
-bool EHScopeStack::containsOnlyLifetimeMarkers(
+bool EHScopeStack::containsOnlyNoopCleanups(
EHScopeStack::stable_iterator Old) const {
for
@@ -1353,6 +1353,19 @@ void CodeGenFunction::EmitLifetimeEnd(llvm::Value *Size,
llvm::Value *Addr) {
C->setDoesNotThrow();
}
+void CodeGenFunction::EmitFakeUse(Address Addr) {
+ // We do not emit a fake use if we want to apply optnone to this function,
+ // even if we mig
@@ -1664,6 +1710,17 @@ CodeGenFunction::EmitAutoVarAlloca(const VarDecl &D) {
emission.getOriginalAllocatedAddress(),
emission.getSizeForLifetimeMarkers());
+ // Analogous to lifetime markers,
@@ -1664,6 +1710,17 @@ CodeGenFunction::EmitAutoVarAlloca(const VarDecl &D) {
emission.getOriginalAllocatedAddress(),
emission.getSizeForLifetimeMarkers());
+ // Analogous to lifetime markers,
https://github.com/jmorse commented:
Looking good, some comments and questions.
Having to fiddle with `findDominatingStoreToReturnValue` to make it skip
fake-uses is slightly worrying, but it also says it's a heuristic and thus
probably not fundamental for correctness?
https://github.com/llvm
@@ -1412,6 +1425,39 @@ void
CodeGenFunction::EmitAndRegisterVariableArrayDimensions(
}
}
+/// Return the maximum size of an aggregate for which we generate a fake use
+/// intrinsic when -fextend-lifetimes is in effect.
+static uint64_t maxFakeUseAggregateSize(const ASTCont
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,50 @@
+// RUN: %clang_cc1 %s -O0 -emit-llvm -fextend-this-ptr -o - | FileCheck %s \
+// RUN: --implicit-check-not="call void (...) @llvm.fake.use"
+// RUN: %clang_cc1 %s -O0 -emit-llvm -fextend-lifetimes -o - | FileCheck %s \
+// RUN: --implicit-check-not="ca
@@ -0,0 +1,27 @@
+// RUN: %clang %s -S -emit-llvm -fextend-lifetimes -O2 -o -
-fno-discard-value-names | FileCheck %s
+//
+// Check we can correctly produce fake uses for function-level variables even
+// when we have a return in a nested conditional and there is no code at the
@@ -0,0 +1,61 @@
+// RUN: %clang_cc1 %s -O0 -disable-O0-optnone -emit-llvm -fextend-lifetimes
-fsanitize=null -fsanitize-trap=null -o - | FileCheck
--check-prefixes=CHECK,NULL --implicit-check-not=ubsantrap %s
+// RUN: %clang_cc1 %s -O0 -disable-O0-optnone -emit-llvm -fextend-li
https://github.com/jmorse commented:
Tests are looking better (and github has helpfully thrown away most of my
comments). I'll look at the code too now.
https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.ll
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jmorse wrote:
The additions here look fine; however I think there's generally precedent that
anything we add needs to have /some/ kind of test, or be covered by something
already existing, otherwise we're vulnerable to:
* Patch lands,
* Someone refactors clang switch handling,
* Other patche
@@ -1834,6 +1834,14 @@ bool CompilerInvocation::ParseCodeGenArgs(CodeGenOptions
&Opts, ArgList &Args,
Opts.setInlining(CodeGenOptions::NormalInlining);
}
+ // If we have specified -Og and have not set any explicit -fextend-lifetimes
+ // value, then default to -fexten
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/118026
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -441,6 +441,10 @@ Modified Compiler Flags
``memset`` and similar functions for which it is a documented undefined
behavior. It is implied by ``-Wnontrivial-memaccess``
+- The ``-Og`` optimization flag now sets ``-fextend-lifetimes``, a new compiler
+ flag, resulting in
@@ -0,0 +1,30 @@
+/// Check that we generate fake uses only when -fextend-lifetimes is set and we
+/// are not setting optnone, or when we have optimizations set to -Og and we
have
+/// not passed -fno-extend-lifetimes.
+// RUN: %clang_cc1 -emit-llvm -disable-llvm-passes -O0 -fex
https://github.com/jmorse commented:
Some minor test comments, otherwise looking good,
https://github.com/llvm/llvm-project/pull/118026
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse commented:
Behold, I've added a bunch of pedantic comments about the tests.
I think a significant matter is that they all run an LLVM optimisation
pipeline, which I believe means they cover too much of the project to be
"clang" tests, they're more end-to-end or cross
@@ -0,0 +1,43 @@
+// RUN: %clang_cc1 %s -triple=%itanium_abi_triple -O1 -emit-llvm
-fextend-lifetimes -o - | FileCheck %s
+// Make sure we don't crash compiling a lambda that is not nested in a
function.
+// We also check that fake uses are properly issued in lambdas.
+
+int glo
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 %s -O2 -emit-llvm -fextend-lifetimes -o - | FileCheck %s
+// Make sure we don't generate fake.use for non-scalar variables.
+// Make sure we don't generate fake.use for volatile variables
+// and parameters even when they are scalar.
+
+struct
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/110102
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,27 @@
+// RUN: %clang %s -S -emit-llvm -fextend-lifetimes -O2 -o -
-fno-discard-value-names | FileCheck %s
+//
+// Check we can correctly produce fake uses for function-level variables even
+// when we have a return in a nested conditional and there is no code at the
@@ -0,0 +1,34 @@
+// RUN: %clang_cc1 %s -O2 -emit-llvm -fextend-lifetimes -fcxx-exceptions
-fexceptions -o - | FileCheck %s
+// REQUIRES: x86-registered-target
jmorse wrote:
Requires x86 as a target, but doesn't specify a triple?
https://github.com/llvm/llvm-pr
@@ -0,0 +1,43 @@
+// RUN: %clang_cc1 %s -triple=%itanium_abi_triple -O1 -emit-llvm
-fextend-lifetimes -o - | FileCheck %s
+// Make sure we don't crash compiling a lambda that is not nested in a
function.
+// We also check that fake uses are properly issued in lambdas.
+
+int glo
@@ -0,0 +1,18 @@
+// RUN: %clang -S -O2 -emit-llvm -fextend-lifetimes %s -o - | FileCheck %s
+// REQUIRES: asserts
jmorse wrote:
Is this REQUIRES a proxy for needing value-names, as above?
https://github.com/llvm/llvm-project/pull/110102
@@ -0,0 +1,37 @@
+// RUN: %clang_cc1 %s -O1 -emit-llvm -fextend-lifetimes -fsanitize=null
-fsanitize-trap=null -o - | FileCheck --check-prefix TRAP %s
+// RUN: %clang_cc1 %s -O1 -emit-llvm -fextend-lifetimes -o - | FileCheck
--check-prefix FAKEUSE %s
+
+// With -fextend-lifetime
@@ -0,0 +1,37 @@
+// RUN: %clang_cc1 %s -O1 -emit-llvm -fextend-lifetimes -fsanitize=null
-fsanitize-trap=null -o - | FileCheck --check-prefix TRAP %s
+// RUN: %clang_cc1 %s -O1 -emit-llvm -fextend-lifetimes -o - | FileCheck
--check-prefix FAKEUSE %s
+
+// With -fextend-lifetime
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 %s -O2 -emit-llvm -fextend-lifetimes -o - | FileCheck %s
+// Make sure we don't generate fake.use for non-scalar variables.
+// Make sure we don't generate fake.use for volatile variables
+// and parameters even when they are scalar.
+
+struct
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 %s -O3 -emit-llvm -fextend-lifetimes -fexceptions -o - |
FileCheck %s
+
+// Check that fake uses do not mistakenly cause a landing pad to be generated
when
+// exceptions are enabled.
+
+extern void bar(int);
+void foo(int p) {
+ int a = 17;
@@ -0,0 +1,43 @@
+// RUN: %clang_cc1 %s -triple=%itanium_abi_triple -O1 -emit-llvm
-fextend-lifetimes -o - | FileCheck %s
+// Make sure we don't crash compiling a lambda that is not nested in a
function.
+// We also check that fake uses are properly issued in lambdas.
+
+int glo
@@ -0,0 +1,37 @@
+// RUN: %clang_cc1 %s -O1 -emit-llvm -fextend-lifetimes -fsanitize=null
-fsanitize-trap=null -o - | FileCheck --check-prefix TRAP %s
+// RUN: %clang_cc1 %s -O1 -emit-llvm -fextend-lifetimes -o - | FileCheck
--check-prefix FAKEUSE %s
+
+// With -fextend-lifetime
@@ -0,0 +1,34 @@
+// RUN: %clang_cc1 %s -O2 -emit-llvm -fextend-lifetimes -fcxx-exceptions
-fexceptions -o - | FileCheck %s
+// REQUIRES: x86-registered-target
+// This test checks that the fake_use concept works with exception handling
and that we
+// can handle the __int128 da
https://github.com/jmorse approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/116074
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse approved this pull request.
> I don't find its current state especially offensive, but I could have a go at
> moving the new stuff to some helper functions, perhaps?
If it's manageable then it's manageable,
> I have a very slight preference to revert this particular
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/115497
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jmorse commented:
Just to check my understanding, things like CHECK-MAIN-CRT-SAME are going to
shift the match-position that FileCheck is looking at forwards, so that we have
to match in the correct order, yes?
I get the feeling that given how much of the construct-a-job log
@@ -97,6 +97,60 @@
// Check the default library name.
// CHECK-JMC: "--push-state" "--whole-archive" "-lSceJmc_nosubmission"
"--pop-state"
+// Test that CRT objects and libraries are supplied to the linker and can be
+// omitted with -noxxx options. These switches have some i
https://github.com/jmorse approved this pull request.
LGTM, although maybe CHECK_JMC instead of CHECK_LIB as it seems very JMC
specific? No strong opinion.
https://github.com/llvm/llvm-project/pull/115181
___
cfe-commits mailing list
cfe-commits@lists
https://github.com/jmorse approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/115009
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 172 matches
Mail list logo
