[Resending with cfe-commits@, whoops]
Hi Kirill,
We believe this patch might be breaking one of the buildbots:
http://lab.llvm.org:8011/builders/clang-x86_64-linux-
abi-test/builds/29719
Which is complaining about the std::unique_ptr copy constructor being
called in DexIndexTests.cpp. It s
Author: jmorse
Date: Tue Jun 5 02:18:26 2018
New Revision: 333989
URL: http://llvm.org/viewvc/llvm-project?rev=333989&view=rev
Log:
Detect an incompatible VLA pointer assignment
For pointer assignments of VLA types, Clang currently detects when array
dimensions _lower_ than a variable dimension
Hi Sam,
Unfortunately this trips up a variety of buildbots:
http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/22376
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/15053
http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/22376
http://lab.llvm.org:801
We do rather need this working for our downstream merging to continue, and
to clear up the buildbots -- without objection I'll drop the "REQUIRES:
system-darwin" line in there. Depending on what's actually supposed to be
tested that might be sufficient, but please do follow up.
--
Thanks,
Jeremy
Author: jmorse
Date: Wed Jan 16 09:41:29 2019
New Revision: 351360
URL: http://llvm.org/viewvc/llvm-project?rev=351360&view=rev
Log:
Add a REQUIRES: darwin line for a mac test.
This test, apparently for macs, fails on Windows as lit can't emulate
the shell subprocess $(which...) correctly. Some o
Platform REQUIRES added in r351360, please do revert & fix if this test is
supposed to work elsewhere.
--
Thanks,
Jeremy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Hi Reid,
On Wed, Sep 11, 2019 at 9:55 PM Reid Kleckner via cfe-commits
wrote:
> +// XFAIL: windows
Looks like this should be system-windows, the PS4 buildbots [0] have a
windows host but target x86_64-scei-ps4, and croak on this change.
Assuming no-one else is looking at this, I'll commit a fix
Author: jmorse
Date: Thu Sep 12 04:19:12 2019
New Revision: 371726
URL: http://llvm.org/viewvc/llvm-project?rev=371726&view=rev
Log:
Switch "windows" to "system-windows" in some XFAILs
The test failure mode appears to be due to the host machine rather than the
target. The PS4 buildbots are window
On Thu, Sep 12, 2019 at 11:24 AM Jeremy Morse
wrote:
> Assuming no-one else is looking at this, I'll commit a fix in ~30 mins.
r371726
--
Thanks,
Jeremy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
Hi Kadir,
I'm seeing a couple of windows buildbots failing to build
FileIndexTests.cpp, even after the follow up in 0dedb43153e6:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/32109
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/15
https://github.com/jmorse closed https://github.com/llvm/llvm-project/pull/79345
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jmorse wrote:
Landed in ddc4935
https://github.com/llvm/llvm-project/pull/79345
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jmorse wrote:
I see what you're saying about the metadata being incorrect; I feel like I've
seen it before, but can't pin it down. For the record, all the builds where we
saw this assertion were thin/full LTO.
I've kicked off a reduction of a large reproducer that I have to hand; I'm not
imme
https://github.com/jmorse updated
https://github.com/llvm/llvm-project/pull/80991
>From 0d03870ef82fac51387c353bbe4e095e431d7ce8 Mon Sep 17 00:00:00 2001
From: Paul Semel
Date: Wed, 7 Feb 2024 13:59:40 +
Subject: [PATCH] [dataflow] CXXOperatorCallExpr equal operator might not be a
glvalue
jmorse wrote:
```
https://github.com/llvm/llvm-project/pull/75385
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jmorse wrote:
Several decades later; I applied this check to the verifier and reduced around
it:
```
diff --git a/llvm/lib/IR/Verifier.cpp b/llvm/lib/IR/Verifier.cpp
index b1cf81a3dbdc..9e2250b584b1 100644
--- a/llvm/lib/IR/Verifier.cpp
+++ b/llvm/lib/IR/Verifier.cpp
@@ -1421,6 +1421,9 @@ void V
jmorse wrote:
Rats; we should be able to pin down where the problem originates from -- would
you be able to describe what's malformed about the metadata, as it's not clear
to us (sorry). We'll probably be able to llvm-reduce (or similar) around that
description.
Unfortunately IIRC it comes fr
jmorse wrote:
...ah, actually is it malformed because there's a DICompositeType in the
retainedNodes list for a DISubprogram? I remember that the verifier considered
that illegal before your patch landed, but not after.
https://github.com/llvm/llvm-project/pull/75385
__
https://github.com/jmorse updated
https://github.com/llvm/llvm-project/pull/79345
>From 0620bf77b4a8586dc1aa96d72bd088a3e601edd4 Mon Sep 17 00:00:00 2001
From: Jeremy Morse
Date: Wed, 24 Jan 2024 16:33:16 +
Subject: [PATCH 1/4] [DebugInfo][RemoveDIs] Don't allocate one DPMarker per
instruc
jmorse wrote:
(Note that I've merged main into this branch for various reasons,)
I've adjusted `adoptDbgValues` to always clean up the `DPMarker` that it
adopts, so that there's no return value for people to accidentally miss. This
means that we have to test in `adoptDbgValues` whether we're a
https://github.com/jmorse closed https://github.com/llvm/llvm-project/pull/77930
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jmorse wrote:
Hi,
We're seeing a crash with this reproducer
https://gist.github.com/jmorse/b0248c3c9f9195487ffd7c7431a8d15e
llc: llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:2338: virtual void
llvm::DwarfDebug::endFunctionImpl(const llvm::MachineFunction *): Assertion
`LScopes.getAbstractScope
jmorse wrote:
Hmmm, that's unexpected -- I reverted the revert (tree here, contains one
unrelated commit:
https://github.com/jmorse/llvm-project/tree/reapply-localvars-patch) and
rebuilt. The assertion-failure occurs just with `llc foobar.ll -o out.o
-filetype=obj`, where foobar.ll is the con
jmorse wrote:
Thanks -- I'm going to land this manually seeing how I don't trust githubs
handling of squashing merge commits
https://github.com/llvm/llvm-project/pull/75228
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org
https://github.com/jmorse closed https://github.com/llvm/llvm-project/pull/75228
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jmorse wrote:
Committed in 087172258a50d5
https://github.com/llvm/llvm-project/pull/75228
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Jeremy Morse
Date: 2020-08-25T14:58:48+01:00
New Revision: 121a49d839d79f5a72be3e22a9d156c9e4b219dc
URL:
https://github.com/llvm/llvm-project/commit/121a49d839d79f5a72be3e22a9d156c9e4b219dc
DIFF:
https://github.com/llvm/llvm-project/commit/121a49d839d79f5a72be3e22a9d156c9e4b219dc.diff
Hi Sam,
It looks like some Windows buildbots fail to build this, for example:
http://lab.llvm.org:8011/#/builders/119/builds/349
In the build step,
[Big long cl.exe command line for]
C:\buildbot\as-builder-2\x-aarch64\llvm-project\clang\lib\Tooling\Syntax\ComputeReplacements.cpp
C:\build
Author: Jeremy Morse
Date: 2021-11-30T12:40:59Z
New Revision: 651122fc4ac92b93f36aab3b194de21065a0c48e
URL:
https://github.com/llvm/llvm-project/commit/651122fc4ac92b93f36aab3b194de21065a0c48e
DIFF:
https://github.com/llvm/llvm-project/commit/651122fc4ac92b93f36aab3b194de21065a0c48e.diff
LOG:
Author: Jeremy Morse
Date: 2020-03-04T15:23:48Z
New Revision: 16c6e0f387e957d21ab90c8694c11cd269ec7719
URL:
https://github.com/llvm/llvm-project/commit/16c6e0f387e957d21ab90c8694c11cd269ec7719
DIFF:
https://github.com/llvm/llvm-project/commit/16c6e0f387e957d21ab90c8694c11cd269ec7719.diff
LOG:
Author: Jeremy Morse
Date: 2020-03-04T17:12:48Z
New Revision: d4f9675b5509e26573058318682a9ed5d7aaf320
URL:
https://github.com/llvm/llvm-project/commit/d4f9675b5509e26573058318682a9ed5d7aaf320
DIFF:
https://github.com/llvm/llvm-project/commit/d4f9675b5509e26573058318682a9ed5d7aaf320.diff
LOG:
Author: Jeremy Morse
Date: 2019-10-30T13:29:47Z
New Revision: 6c0a160c2d33e54aecf1538bf7c85d8da92051be
URL:
https://github.com/llvm/llvm-project/commit/6c0a160c2d33e54aecf1538bf7c85d8da92051be
DIFF:
https://github.com/llvm/llvm-project/commit/6c0a160c2d33e54aecf1538bf7c85d8da92051be.diff
LOG:
FYI, in llvmorg-10-init-8612-g6c0a160c2d3 [0] I've renamed one of the
two files, Windows too has a case-insensitive filesystem layer and
this broke our CI. (I think I've preserved the original intention of
the tests).
[0]
https://github.com/llvm/llvm-project/commit/6c0a160c2d33e54aecf1538bf7c85d8
Author: Jeremy Morse
Date: 2019-11-08T12:07:42Z
New Revision: 6b45e1bc11e91ea7b57a6ab1c19461a86dba33f8
URL:
https://github.com/llvm/llvm-project/commit/6b45e1bc11e91ea7b57a6ab1c19461a86dba33f8
DIFF:
https://github.com/llvm/llvm-project/commit/6b45e1bc11e91ea7b57a6ab1c19461a86dba33f8.diff
LOG:
Hi Jan,
As the dfsan tests have been failing for a bit, I've reverted this in
6b45e1bc, and the follow-up patch in d6be9273c, to clear the
buildbots.
--
Thanks,
Jeremy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
Hi Jan,
The x86_64 sanitizer was failing:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/24326
And then immediately after the reverts landed:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/24327
check-dfsan passes. I don't have any explanation as to wh
Author: Jeremy Morse
Date: 2020-03-05T10:55:24Z
New Revision: 737394c490444e968a6f640b99a6614567ca7f28
URL:
https://github.com/llvm/llvm-project/commit/737394c490444e968a6f640b99a6614567ca7f28
DIFF:
https://github.com/llvm/llvm-project/commit/737394c490444e968a6f640b99a6614567ca7f28.diff
LOG:
Hi Matt,
FYI several build bots tripped on this commit:
http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/24703/
http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/13465/
http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/15994/
https://github.com/jmorse approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/106463
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jmorse wrote:
(I can't replicate the buildkite windows failure locally, will commit and see
what actually goes wrong)
https://github.com/llvm/llvm-project/pull/102006
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
https://github.com/jmorse closed
https://github.com/llvm/llvm-project/pull/102006
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Jeremy Morse
Date: 2024-08-12T09:49:55+01:00
New Revision: d12250ca7bea22ed12caf44fe80b203d83db75bb
URL:
https://github.com/llvm/llvm-project/commit/d12250ca7bea22ed12caf44fe80b203d83db75bb
DIFF:
https://github.com/llvm/llvm-project/commit/d12250ca7bea22ed12caf44fe80b203d83db75bb.diff
jmorse wrote:
Clang-formatted the declaration I touched in d12250ca7be, the other matters
were already present in the code so I've shied away from addressing them.
https://github.com/llvm/llvm-project/pull/102006
___
cfe-commits mailing list
cfe-commi
https://github.com/jmorse approved this pull request.
In lieu of Paul for a bit of time, LGTM.
I feel like the check for matching the linker-line could be made even stronger
(one wonders how many options end with 'ld"', but it's probably good enough.
https://github.com/llvm/llvm-project/pull/1
jmorse wrote:
G'day -- we've got some tests for -O0 that, with this patch applied, generate
different code with-and-without the `-g` flag, if `-fdebug-info-for-profiling`
is enabled. Example godbolt: https://godbolt.org/z/qooo5Eah1 .
It seems the intention of this patch is generating additiona
jmorse wrote:
dblaikie wrote:
> I hope that isn't the intent, I thought the intent was just [...]
Ah, by which I mean "it's not an accident",
> By just specifying -g Even without -fdebug-info-for-profiling it is going to
> introduce debug variables as a sequence of alloca-store-load too, so i
https://github.com/jmorse commented:
Looks good in principle, with a couple of nits.
https://github.com/llvm/llvm-project/pull/95298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -5746,6 +5746,57 @@ void
CGDebugInfo::EmitExternalVariable(llvm::GlobalVariable *Var,
Var->addDebugInfo(GVE);
}
+void CGDebugInfo::EmitPseudoVariable(CGBuilderTy &Builder,
+ llvm::Instruction *Value, QualType Ty) {
+ // Only when -g2
@@ -5746,6 +5746,57 @@ void
CGDebugInfo::EmitExternalVariable(llvm::GlobalVariable *Var,
Var->addDebugInfo(GVE);
}
+void CGDebugInfo::EmitPseudoVariable(CGBuilderTy &Builder,
+ llvm::Instruction *Value, QualType Ty) {
+ // Only when -g2
https://github.com/jmorse edited https://github.com/llvm/llvm-project/pull/95298
___
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, thanks for rapidly rewriting this. I think dereferencing the insertion
iterator with `&**` will eventually need addressing with the move away from
intrinsics and insertion, but that can be a matter for when the DIBuilder APIs
get depr
https://github.com/jmorse approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/95637
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jmorse wrote:
@huangjd Thanks for the fix -- FYI it's acceptable to commit patches like this
without review (and leave a comment on the original PR) if you wanted to. Given
that it's just the format of the test changing, not any of the meaning, it's an
"obvious" fix.
https://github.com/llvm/l
jmorse wrote:
I think I've nailed down the source of this problem, and it's the matter to do
with `LLVMContext::enableDebugTypeODRUniquing` that aeubanks mentioned on
https://reviews.llvm.org/D144006. LLVM will unique DICompositeTypes via their
ODR-name, which isn't always safe with function-l
@@ -36,9 +35,6 @@
// RUN: env SCE_ORBIS_SDK_DIR=.. %clang -Winvalid-or-nonexistent-directory
-### -emit-ast -isysroot foo -target x86_64-scei-ps4 %s 2>&1 | FileCheck
-check-prefix=WARN-ISYSROOT -check-prefix=NO-WARN %s
// RUN: env SCE_ORBIS_SDK_DIR=.. %clang -Winvalid-or-nonex
https://github.com/jmorse created
https://github.com/llvm/llvm-project/pull/102006
As part of the LLVM effort to eliminate debug-info intrinsics, we're moving to
a world where only iterators should be used to insert instructions. This isn't
a problem in clang when instructions get generated be
https://github.com/jmorse updated
https://github.com/llvm/llvm-project/pull/102006
>From cf967317327aa3971da62a15f357ee5b29268f14 Mon Sep 17 00:00:00 2001
From: Jeremy Morse
Date: Mon, 5 Aug 2024 16:21:53 +0100
Subject: [PATCH 1/2] [DebugInfo][RemoveDIs] Use iterator-inserters in clang
As part
https://github.com/jmorse updated
https://github.com/llvm/llvm-project/pull/102006
>From cf967317327aa3971da62a15f357ee5b29268f14 Mon Sep 17 00:00:00 2001
From: Jeremy Morse
Date: Mon, 5 Aug 2024 16:21:53 +0100
Subject: [PATCH 1/3] [DebugInfo][RemoveDIs] Use iterator-inserters in clang
As part
Author: Jeremy Morse
Date: 2021-04-26T10:07:22+01:00
New Revision: 3c9bcf0e3549d89b31e19e67a5a16babdee2c72d
URL:
https://github.com/llvm/llvm-project/commit/3c9bcf0e3549d89b31e19e67a5a16babdee2c72d
DIFF:
https://github.com/llvm/llvm-project/commit/3c9bcf0e3549d89b31e19e67a5a16babdee2c72d.diff
Author: Jeremy Morse
Date: 2021-12-22T16:30:05Z
New Revision: ea22fdd120aeb1bbb9ea96670d70193dc02b2c5f
URL:
https://github.com/llvm/llvm-project/commit/ea22fdd120aeb1bbb9ea96670d70193dc02b2c5f
DIFF:
https://github.com/llvm/llvm-project/commit/ea22fdd120aeb1bbb9ea96670d70193dc02b2c5f.diff
LOG:
On Wed, Dec 22, 2021 at 4:34 PM David Blaikie via cfe-commits
wrote:
> Is there a way to turn this off now, if it's broken for some user/use case? I
> guess using an -mllvm flag, instead of an -Xclang flag?
Yup, that should be achieved by "-mllvm
-experimental-debug-variable-locations=false", th
https://github.com/jmorse created
https://github.com/llvm/llvm-project/pull/111836
These DenseMaps all appear as some of the most frequent sources of
memory-allocations that could otherwise be accomodated with an initial stack
allocation. For simplicity, I've typedef'd one map-type to be Block
https://github.com/jmorse updated
https://github.com/llvm/llvm-project/pull/111836
>From d2b935e3a537e065b00f543a1792d1979ba413d9 Mon Sep 17 00:00:00 2001
From: Jeremy Morse
Date: Thu, 10 Oct 2024 14:17:34 +0100
Subject: [PATCH 1/2] [NFC] Replace more DenseMaps with SmallDenseMaps
These DenseM
jmorse wrote:
Undid the format-changes in this PR. For context: I've been building profiles
of all DenseMap allocations across a build of the CTMark suite to find
DenseMaps that a) are frequently used and b) usually have a small number of
elements, making them good candidates for initial stack
https://github.com/jmorse updated
https://github.com/llvm/llvm-project/pull/111836
>From d2b935e3a537e065b00f543a1792d1979ba413d9 Mon Sep 17 00:00:00 2001
From: Jeremy Morse
Date: Thu, 10 Oct 2024 14:17:34 +0100
Subject: [PATCH 1/3] [NFC] Replace more DenseMaps with SmallDenseMaps
These DenseM
jmorse wrote:
Hadn't realised lambda types will pop up everywhere, the cost might be too
high. I'll test with building clang and our internal codebases to see if the
fix works and what the cost is.
> Surely if we can compute a unique mangled name for this local class, we
> should use it as th
https://github.com/jmorse closed
https://github.com/llvm/llvm-project/pull/110134
___
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/113162
___
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/113595
___
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/114546
___
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/115009
___
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 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.
LGTM
https://github.com/llvm/llvm-project/pull/114060
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -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 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
jmorse wrote:
[This keeps on slipping to the back of my TODO list,]
I've been enlightened by the comments on #68929 about ODR rules, and that there
isn't a violation in the example; it does at least exercise the code path of
interest, my summary of which is that the ODR-uniquing of types is ha
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 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
@@ -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
@@ -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
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
@@ -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
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
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
@@ -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
@@ -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,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
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
@@ -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 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
@@ -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,
@@ -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
@@ -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
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
1 - 100 of 155 matches
Mail list logo
