@@ -367,12 +367,6 @@ bool RedeclarableTemplateDecl::loadLazySpecializationsImpl(
if (!ExternalSource)
return false;
- // If TPL is not null, it implies that we're loading specializations for
- // partial templates. We need to load all specializations in such cases.
-
@@ -21,17 +21,6 @@ using namespace clang;
namespace {
class TemplateArgumentHasher {
- // If we bail out during the process of calculating hash values for
- // template arguments for any reason. We're allowed to do it since
- // TemplateArgumentHasher are only required to g
@@ -367,12 +367,6 @@ bool RedeclarableTemplateDecl::loadLazySpecializationsImpl(
if (!ExternalSource)
return false;
- // If TPL is not null, it implies that we're loading specializations for
- // partial templates. We need to load all specializations in such cases.
-
hahnjo wrote:
> When I have time, I will need to see that I turn the reduced example into
> actual valid code to understand what is going on...
I spent some time turning it into valid code, but then noticed that the `error:
use of overloaded operator '=' is ambiguous` is gone. Going back, the
hahnjo wrote:
> The simplified script: https://pastebin.com/udVTaPYV
Aaaah, the important line is `EXTRA_CFLAGS='-Xclang
-fallow-pcm-with-compiler-errors -ferror-limit=0'`. With that I indeed get the
following diff between logs from `main` and a rebased version of this branch:
```diff
--- main
hahnjo wrote:
> Here's a new reproducer, this time verifying that a semi-fresh
> tip-of-the-tree doesn't trigger the same error:
> https://pastebin.com/7tYfjazz. Apologies for the delay.
Thanks. I gave it a try, but I don't see any `use of overloaded operator '=' is
ambiguous` error. In fact,
hahnjo wrote:
Hi @emaxx-google, any updates on the second minimization run?
https://github.com/llvm/llvm-project/pull/133057
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hahnjo wrote:
> Maybe you can test it with this and land it with different patches. So that
> we can revert one of them if either of them are problematic but other parts
> are fine.
I'm ok with pushing the commits one-by-one after the PR is reviewed, just let
me know.
> > Complete only neede
hahnjo wrote:
### Performance measurements with LLVM
I tested these patches for building LLVM itself with modules
(`LLVM_ENABLE_MODULES=ON`). To work around
https://github.com/llvm/llvm-project/issues/130795, I apply
https://github.com/llvm/llvm-project/pull/131354 before building Clang. In
hahnjo wrote:
> While I may not able to look into them in detail recently, it may be helpful
> to split this into seperate patches to review and to land.
I initially considered this, but @vgvassilev said in
https://github.com/root-project/root/pull/17722#issuecomment-2706555950 he
prefers a s
https://github.com/hahnjo created
https://github.com/llvm/llvm-project/pull/133057
* Hash inner template arguments: The code is applied from `ODRHash::AddDecl`
with the reasoning given in the comment, to reduce collisions. This was
particularly visible with STL types templated on `std::pair`
hahnjo wrote:
I believe
https://github.com/llvm/llvm-project/commit/30ea0f0ce476bf4c12684a9a514af2ca660bbe44
already addresses the cast. The bots are just slow...
https://github.com/llvm/llvm-project/pull/119333
___
cfe-commits mailing list
cfe-commi
https://github.com/hahnjo closed
https://github.com/llvm/llvm-project/pull/104964
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/hahnjo created
https://github.com/llvm/llvm-project/pull/104964
None
>From dc37b356fb9527c3b4cf6b31f55d2dd5067fc29d Mon Sep 17 00:00:00 2001
From: Jonas Hahnfeld
Date: Tue, 20 Aug 2024 16:25:15 +0200
Subject: [PATCH 1/2] [clang-repl] Fix printing preprocessed tokens
---
cl
https://github.com/hahnjo closed
https://github.com/llvm/llvm-project/pull/103028
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hahnjo wrote:
> > BTW, the delayed template parsing is a deprecated technique. Both clang and
> > MSVC won't enable this after C++20 and we think it is the root of many bugs.
>
> I agree. It was needed in the past to parse the MSVC stdlib, let's check if
> we still need it:
> [root-project/ro
https://github.com/hahnjo created
https://github.com/llvm/llvm-project/pull/103028
When instantiating a delayed template, the recorded token stream is passed to
`Parser::ParseLateTemplatedFuncDef` which will append the current token "so it
doesn't get lost". With incremental extensions enabled
hahnjo wrote:
> > Quick question for my understanding: With `spr` we don't get meaningful
> > commit messages anymore? That's quite unfortunate...
>
> Can you please clarify?
The commit messages in this PR are `initial version` and `Update const.cpp`,
which is totally useless if I came across
hahnjo wrote:
Quick question for my understanding: With `spr` we don't get meaningful commit
messages anymore? That's quite unfortunate...
https://github.com/llvm/llvm-project/pull/102859
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:/
https://github.com/hahnjo closed
https://github.com/llvm/llvm-project/pull/102450
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hahnjo wrote:
> Your reasoning sounds right to me. Can we make sure we are not breaking
> `clang -fincremental-extensions`, too?
As far as I can tell, `-fincremental-extensions` should set the language option
`IncrementalExtensions` which in turn is the default for
`Preprocessor::IncrementalP
https://github.com/hahnjo created
https://github.com/llvm/llvm-project/pull/102450
When incremental processing is enabled, the Parser will never report `tok::eof`
but `tok::annot_repl_input_end`. However, that case is already taken care of in
`IncrementalParser::ParseOrWrapTopLevelDecl()` so t
https://github.com/hahnjo closed https://github.com/llvm/llvm-project/pull/76473
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -364,6 +365,19 @@ IncrementalParser::Parse(llvm::StringRef input) {
std::unique_ptr IncrementalParser::GenModule() {
static unsigned ID = 0;
if (CodeGenerator *CG = getCodeGen()) {
+// Clang's CodeGen is designed to work with a single llvm::Module. In many
+// ca
@@ -224,11 +228,8 @@ IncrementalParser::IncrementalParser(Interpreter &Interp,
return; // PTU.takeError();
}
- if (CodeGenerator *CG = getCodeGen()) {
-std::unique_ptr M(CG->ReleaseModule());
-CG->StartModule("incr_module_" + std::to_string(P
Stefan =?utf-8?q?Gr=C3=A4nitz?=
Message-ID:
In-Reply-To:
@@ -14,7 +14,7 @@ struct A { int a; A(int a) : a(a) {} virtual ~A(); };
// PartialTranslationUnit.
inline A::~A() { printf("~A(%d)\n", a); }
-// Create one instance with new and delete it.
+// Create one instance with
Stefan =?utf-8?q?Gränitz?=
Message-ID:
In-Reply-To:
@@ -14,7 +14,7 @@ struct A { int a; A(int a) : a(a) {} virtual ~A(); };
// PartialTranslationUnit.
inline A::~A() { printf("~A(%d)\n", a); }
-// Create one instance with new and delete it.
+// Create one instance with new
Stefan =?utf-8?q?Gränitz?=
Message-ID:
In-Reply-To:
@@ -14,7 +14,7 @@ struct A { int a; A(int a) : a(a) {} virtual ~A(); };
// PartialTranslationUnit.
inline A::~A() { printf("~A(%d)\n", a); }
-// Create one instance with new and delete it.
+// Create one instance with new
@@ -2,56 +2,56 @@
// REQUIRES: nvptx-registered-target
// REQUIRES: zlib
-// RUN: not %clang -### --target=x86_64-linux-gnu -c %s -g -gz 2>&1 \
+// RUN: %clang -### --target=x86_64-linux-gnu --offload-arch=sm_52 -nogpulib
-nogpuinc -c %s -g -gz 2>&1 \
// RUN: | FileCheck %s
hahnjo wrote:
https://github.com/llvm/llvm-project/pull/84017 changed the test in ways that
this isn't needed anymore.
https://github.com/llvm/llvm-project/pull/84008
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
https://github.com/hahnjo closed https://github.com/llvm/llvm-project/pull/84008
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2,56 +2,56 @@
// REQUIRES: nvptx-registered-target
// REQUIRES: zlib
-// RUN: not %clang -### --target=x86_64-linux-gnu -c %s -g -gz 2>&1 \
+// RUN: %clang -### --target=x86_64-linux-gnu --offload-arch=sm_52 -nogpulib
-nogpuinc -c %s -g -gz 2>&1 \
// RUN: | FileCheck %s
hahnjo wrote:
Ok, but that still doesn't change the fact that the Clang driver will search
for a system-wide CUDA installation unless passed `--cuda-path`...
https://github.com/llvm/llvm-project/pull/84008
___
cfe-commits mailing list
cfe-commits@list
hahnjo wrote:
> > > Might need `-nogpulib -nogpuinc` in those cases, we do that in other
> > > `.cu` files in the test suite.
> >
> >
> > No, I already tried that, it doesn't work for me. All
> > `clang/test/Driver/*.cu` that supply `-nocudainc` also pass `--cuda-path`...
>
> The only reason
hahnjo wrote:
> > It definitely doesn't work for the "pure" CUDA invocations, it still finds
> > my local installation and complains. It might work for the OpenMP
> > invocations, but hard to tell for me on a system with CUDA installed. As
> > it's a `.cu` test after all, I think I would prefe
hahnjo wrote:
> We had a lot that were like this previously. Guessing this one slipped
> through because of the `zlib` requirement.
I actually think there are some more left; for example
`clang/test/Driver/cuda-dwarf-2.cu` has many `not %clang` invocations that
don't specify `--cuda-path`. Th
hahnjo wrote:
> But my point is that we can't land that if we don't understand what's going
> wrong without that patch.
We understand that very well and it's described in
https://reviews.llvm.org/D153003 as well as the surrounding discussions:
because of the way that `ODRHash` works, template
hahnjo wrote:
As far as I can tell from
https://github.com/llvm/llvm-project/pull/76774#issuecomment-1914177330 above,
the last push only changed the default value of
`LoadExternalSpecializationsLazily`. In that case, my test results from
https://github.com/llvm/llvm-project/pull/76774#issuec
hahnjo wrote:
The newest version of this patch still doesn't work correctly. Switching the
new `LoadExternalSpecializationsLazily` to disabled by default (somehow the
argument didn't work on its own) instead crashes, most of the cases involving
`MultiOnDiskHashTable`. I suspect some kind of me
hahnjo wrote:
> Would you like to give an reproducer so that I can debug?
Not easily at the moment, unless you want to go through building the entirety
of ROOT :-/
https://github.com/llvm/llvm-project/pull/76774
___
cfe-commits mailing list
cfe-commi
hahnjo wrote:
> > > I tried applying this patch to ROOT/Cling and it fails to build because
> > > something is of the opinion that `std::is_integral::value` is not
> > > true. I don't have time right now to investigate further, but since this
> > > is the only change I did it is highly likely
hahnjo wrote:
> It seems after this change we started to fail on `LLVM ::
> ExecutionEngine/JITLink/RISCV/ELF_ehframe.s` when using debug libgcxx.
First, sorry for the slow response and breaking the builds with expensive
checks in the first place. I believe the report is actually fully correct
hahnjo wrote:
I tried applying this patch to ROOT/Cling and it fails to build because
something is of the opinion that `std::is_integral::value` is not true. I
don't have time right now to investigate further, but since this is the only
change I did it is highly likely that it's caused by this
https://github.com/hahnjo approved this pull request.
Looks good (sorry, this fell through)
https://github.com/llvm/llvm-project/pull/76218
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm
https://github.com/hahnjo closed https://github.com/llvm/llvm-project/pull/69076
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hahnjo wrote:
> Please add a release note
> This change needs a release note. Please add an entry to
> `clang/docs/ReleaseNotes.rst` in the section the most adapted to the change,
> and referencing any Github issue this change fixes. Thanks!
Done.
https://github.com/llvm/llvm-project/pull/69
@@ -15754,10 +15754,18 @@ bool Expr::EvaluateAsInitializer(APValue &Value,
const ASTContext &Ctx,
LValue LVal;
LVal.set(VD);
-if (!EvaluateInPlace(Value, Info, LVal, this,
- /*AllowNonLiteralTypes=*/true) ||
-EStatus.HasSideEffects)
https://github.com/hahnjo updated
https://github.com/llvm/llvm-project/pull/69076
>From a55ca99a373b17501d56d18af9e8aa2dc2cbcea0 Mon Sep 17 00:00:00 2001
From: Jonas Hahnfeld
Date: Sat, 14 Oct 2023 20:10:28 +0200
Subject: [PATCH 1/3] Fix crash with modules and constexpr destructor
With modules
hahnjo wrote:
> address my previous comment: [#69076
> (comment)](https://github.com/llvm/llvm-project/pull/69076#issuecomment-1780327252)
I had already expanded the commit message with the full details, now also
copied to the PR summary. Is that sufficient to address the comment?
https://git
https://github.com/hahnjo edited https://github.com/llvm/llvm-project/pull/69076
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1249,3 +1249,5 @@ void ODRHash::AddQualType(QualType T) {
void ODRHash::AddBoolean(bool Value) {
Bools.push_back(Value);
}
+
+void ODRHash::AddInteger(unsigned Value) { ID.AddInteger(Value); }
hahnjo wrote:
That test does not exercise an alias argument t
hahnjo wrote:
Well, this patch is up since almost three months now (!). Sure, we can keep
carrying a similar fix downstream, but ideally I would really like to get rid
of as many local changes as possible. That's not possible without proper
review, but the current situation is quite unsatisfac
hahnjo wrote:
Ping, is this ok to be accepted and landed?
> So personally I am fine with the current workaround with a `FIXME`.
You mean next to the comment I already added referring to the C++ standard? Can
you formulate what I should put there?
https://github.com/llvm/llvm-project/pull/6907
@@ -1249,3 +1249,5 @@ void ODRHash::AddQualType(QualType T) {
void ODRHash::AddBoolean(bool Value) {
Bools.push_back(Value);
}
+
+void ODRHash::AddInteger(unsigned Value) { ID.AddInteger(Value); }
hahnjo wrote:
The review related to `ODRHash` is this one: ht
hahnjo wrote:
I finally had time to debug this: The reason for modules being involved here is
because the serialization code calls `ParmVarDecl::getDefaultArg()` which
strips the outermost `FullExpr`, such as `ExprWithCleanups`. A potential fix is
in https://github.com/llvm/llvm-project/pull/7
https://github.com/hahnjo updated
https://github.com/llvm/llvm-project/pull/69076
>From a55ca99a373b17501d56d18af9e8aa2dc2cbcea0 Mon Sep 17 00:00:00 2001
From: Jonas Hahnfeld
Date: Sat, 14 Oct 2023 20:10:28 +0200
Subject: [PATCH] Fix crash with modules and constexpr destructor
With modules, se
https://github.com/hahnjo created
https://github.com/llvm/llvm-project/pull/76473
`ParmVarDecl::getDefaultArg()` strips the outermost `FullExpr`, such as
`ExprWithCleanups`. This leads to an `llvm_unreachable` being executed with the
added test `clang/test/Modules/pr68702.cpp`; instead use the
https://github.com/hahnjo closed https://github.com/llvm/llvm-project/pull/73955
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hahnjo wrote:
I tried to craft a test here, but declaration unloading in `clang-repl` is not
powerful enough (yet) to show a (user-visible) consequence of the problem.
On a high level, the problem should be triggered by:
```
clang-repl> template struct A { void f() { } };
clang-repl> A().f();
hahnjo wrote:
I will try, but observing the consequences of this depends on unloading:
Basically it happens if a declaration in `UndefinedButUsed` thas was previously
defined is unloaded, which makes it undefined. For now, it's possible that for
the upstream cases it's only an optimization bec
https://github.com/hahnjo created
https://github.com/llvm/llvm-project/pull/73955
Before, it was only cleared if there were undefined entities. This is important
for Clang's incremental parsing as used by `clang-repl` that might receive
multiple calls to `Sema.ActOnEndOfTranslationUnit`.
>Fro
hahnjo wrote:
ping @shafik @cor3ntin @ChuanqiXu9, how can we make progress here?
https://github.com/llvm/llvm-project/pull/69076
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/hahnjo approved this pull request.
Looks reasonable to me. I know this fixes a test error for MinGW, but if
possible maybe let it sit until early next week in case somebody else has a
different opinion on moving `host=` to `lit`.
https://github.com/llvm/llvm-project/pull/711
https://github.com/hahnjo approved this pull request.
Very interesting... See also https://github.com/llvm/llvm-project/issues/68092,
now I understand even less what the problem is...
https://github.com/llvm/llvm-project/pull/70991
___
cfe-commits mai
hahnjo wrote:
I can add the comment as requested, but for the other questions related to full
expressions and modules I'd really need input from experts...
https://github.com/llvm/llvm-project/pull/69076
___
cfe-commits mailing list
cfe-commits@lists.
https://github.com/hahnjo closed https://github.com/llvm/llvm-project/pull/68253
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hahnjo wrote:
ping @cor3ntin @shafik, could you have a look here?
https://github.com/llvm/llvm-project/pull/69076
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hahnjo wrote:
@mtvec @luxufan ping :)
https://github.com/llvm/llvm-project/pull/68253
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/hahnjo edited https://github.com/llvm/llvm-project/pull/68253
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/hahnjo updated
https://github.com/llvm/llvm-project/pull/68253
>From d44b58748bcc815e151b8d99ab5cbae8b86ed056 Mon Sep 17 00:00:00 2001
From: Jonas Hahnfeld
Date: Wed, 4 Oct 2023 21:27:14 +0200
Subject: [PATCH 1/3] [JITLink][RISCV] Implement eh_frame handling
This requires ad
@@ -0,0 +1,65 @@
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: split-file %s %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-obj -fmodules -fimplicit-module-maps
-fmodules-cache-path=%t %t/main.cpp -o %t/main.o
hahnjo wrote:
No, we don't need it, you are right - the c
https://github.com/hahnjo updated
https://github.com/llvm/llvm-project/pull/69076
>From d149de4d4e00b63e506441b516f35aeb41786408 Mon Sep 17 00:00:00 2001
From: Jonas Hahnfeld
Date: Sat, 14 Oct 2023 20:10:28 +0200
Subject: [PATCH 1/2] Fix crash with modules and constexpr destructor
Closes https
@@ -0,0 +1,65 @@
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: split-file %s %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-obj -fmodules -fimplicit-module-maps
-fmodules-cache-path=%t %t/main.cpp -o %t/main.o
+
+//--- V.h
+#ifndef V_H
+#define V_H
+
+class A {
+public:
+ constexpr A
https://github.com/hahnjo created
https://github.com/llvm/llvm-project/pull/69076
Closes https://github.com/llvm/llvm-project/issues/68702
>From d149de4d4e00b63e506441b516f35aeb41786408 Mon Sep 17 00:00:00 2001
From: Jonas Hahnfeld
Date: Sat, 14 Oct 2023 20:10:28 +0200
Subject: [PATCH] Fix cra
Author: Jonas Hahnfeld
Date: 2023-10-05T12:09:14+02:00
New Revision: abb9eb2778dc68ca3bc2ca786632e65682741469
URL:
https://github.com/llvm/llvm-project/commit/abb9eb2778dc68ca3bc2ca786632e65682741469
DIFF:
https://github.com/llvm/llvm-project/commit/abb9eb2778dc68ca3bc2ca786632e65682741469.diff
Author: Jonas Hahnfeld
Date: 2023-10-05T11:04:07+02:00
New Revision: 3116d60494f219bfcb284d05d9ebed5b6c196ca5
URL:
https://github.com/llvm/llvm-project/commit/3116d60494f219bfcb284d05d9ebed5b6c196ca5
DIFF:
https://github.com/llvm/llvm-project/commit/3116d60494f219bfcb284d05d9ebed5b6c196ca5.diff
hahnjo wrote:
Note that this currently doesn't seem to work on Windows:
https://github.com/llvm/llvm-project/issues/68092
https://github.com/llvm/llvm-project/pull/65257
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cg
Author: Jonas Hahnfeld
Date: 2023-10-03T13:30:01+02:00
New Revision: 4812eecd7106200c0330d6371afbe036f577244a
URL:
https://github.com/llvm/llvm-project/commit/4812eecd7106200c0330d6371afbe036f577244a
DIFF:
https://github.com/llvm/llvm-project/commit/4812eecd7106200c0330d6371afbe036f577244a.diff
Author: Jonas Hahnfeld
Date: 2023-10-03T13:10:31+02:00
New Revision: b6ee41f83c6ea361bfafc2168e9223379b32773f
URL:
https://github.com/llvm/llvm-project/commit/b6ee41f83c6ea361bfafc2168e9223379b32773f
DIFF:
https://github.com/llvm/llvm-project/commit/b6ee41f83c6ea361bfafc2168e9223379b32773f.diff
https://github.com/hahnjo closed https://github.com/llvm/llvm-project/pull/65257
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -794,7 +794,7 @@ void CodeGenModule::Release() {
AddGlobalCtor(ObjCInitFunction);
if (Context.getLangOpts().CUDA && CUDARuntime) {
if (llvm::Function *CudaCtorFunction = CUDARuntime->finalizeModule())
- AddGlobalCtor(CudaCtorFunction);
+ AddGlobalCtor(C
@@ -0,0 +1,29 @@
+// UNSUPPORTED: system-aix
+// RUN: cat %s | clang-repl | FileCheck %s
+// RUN: cat %s | clang-repl -Xcc -O2 | FileCheck %s
+
+extern "C" int printf(const char*, ...);
+
hahnjo wrote:
`const A a(1);` is a file-scope constant, no? We don't need i
hahnjo wrote:
ping @vgvassilev
https://github.com/llvm/llvm-project/pull/65257
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hahnjo wrote:
Ping on the updated patch, which is now also passing downstream testing after I
realized that we were missing a backport of commit
e451d552348bc714614d294e32dfbe7ec2cd4005, which explains why some constructors
were wrongly ordered...
https://github.com/llvm/llvm-project/pull/652
https://github.com/hahnjo review_requested
https://github.com/llvm/llvm-project/pull/65257
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hahnjo wrote:
The original patch worked for `clang-repl` but results in strong linkage which
I found to cause problems with modules downstream in ROOT. Instead the latest
push moves the special case one level higher to `basicGVALinkageForVariable`
and returns `GVA_DiscardableODR` which fixes t
https://github.com/hahnjo updated
https://github.com/llvm/llvm-project/pull/65257:
>From 7b52d2ad531286ca3e14c3f05da51c91fd71bd0d Mon Sep 17 00:00:00 2001
From: Jonas Hahnfeld
Date: Wed, 6 Sep 2023 13:11:57 +0200
Subject: [PATCH] [clang-repl] Emit const variables only once
Disable internal lin
https://github.com/hahnjo review_requested
https://github.com/llvm/llvm-project/pull/65257
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/hahnjo review_requested
https://github.com/llvm/llvm-project/pull/65257
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/hahnjo review_requested
https://github.com/llvm/llvm-project/pull/65257
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/hahnjo created
https://github.com/llvm/llvm-project/pull/65257:
Disable internal linkage for const variables if IncrementalExtensions are
enabled. Otherwise the variables are emitted multiple times, with multiple
constructions at unique memory locations, during every PTU.
>
https://github.com/hahnjo labeled
https://github.com/llvm/llvm-project/pull/65257
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Jonas Hahnfeld
Date: 2023-08-23T11:29:26+02:00
New Revision: 6c274ba4108b07358ebd4e8d607c72d6db8c8100
URL:
https://github.com/llvm/llvm-project/commit/6c274ba4108b07358ebd4e8d607c72d6db8c8100
DIFF:
https://github.com/llvm/llvm-project/commit/6c274ba4108b07358ebd4e8d607c72d6db8c8100.diff
Author: Jonas Hahnfeld
Date: 2023-08-18T09:42:28+02:00
New Revision: c861d32d7c2791bdc058d9d9fbaecc1c2f07b8c7
URL:
https://github.com/llvm/llvm-project/commit/c861d32d7c2791bdc058d9d9fbaecc1c2f07b8c7
DIFF:
https://github.com/llvm/llvm-project/commit/c861d32d7c2791bdc058d9d9fbaecc1c2f07b8c7.diff
Author: Jonas Hahnfeld
Date: 2023-08-17T14:21:39+02:00
New Revision: 0e17372b380467ac8339afdec992fbf887a11feb
URL:
https://github.com/llvm/llvm-project/commit/0e17372b380467ac8339afdec992fbf887a11feb
DIFF:
https://github.com/llvm/llvm-project/commit/0e17372b380467ac8339afdec992fbf887a11feb.diff
Author: Jonas Hahnfeld
Date: 2023-08-17T13:26:22+02:00
New Revision: f8dadefd4afc8e1b7b9a1e69a0ba8df051e03328
URL:
https://github.com/llvm/llvm-project/commit/f8dadefd4afc8e1b7b9a1e69a0ba8df051e03328
DIFF:
https://github.com/llvm/llvm-project/commit/f8dadefd4afc8e1b7b9a1e69a0ba8df051e03328.diff
Author: Jonas Hahnfeld
Date: 2023-08-17T11:54:05+02:00
New Revision: d43a3d6346961e639e29b8083b262416889e78ec
URL:
https://github.com/llvm/llvm-project/commit/d43a3d6346961e639e29b8083b262416889e78ec
DIFF:
https://github.com/llvm/llvm-project/commit/d43a3d6346961e639e29b8083b262416889e78ec.diff
Author: Jonas Hahnfeld
Date: 2023-08-17T10:39:47+02:00
New Revision: b719e410781ce9f3a2b316afea31c156bf99e036
URL:
https://github.com/llvm/llvm-project/commit/b719e410781ce9f3a2b316afea31c156bf99e036
DIFF:
https://github.com/llvm/llvm-project/commit/b719e410781ce9f3a2b316afea31c156bf99e036.diff
Author: Jonas Hahnfeld
Date: 2023-08-17T10:04:38+02:00
New Revision: eeac4321c517ee8afc30ebe62c5b1778efc1173d
URL:
https://github.com/llvm/llvm-project/commit/eeac4321c517ee8afc30ebe62c5b1778efc1173d
DIFF:
https://github.com/llvm/llvm-project/commit/eeac4321c517ee8afc30ebe62c5b1778efc1173d.diff
Author: Jonas Hahnfeld
Date: 2023-08-17T08:28:51+02:00
New Revision: 2f3fe3ed97bcf778d73eda5aae9f166810a4af02
URL:
https://github.com/llvm/llvm-project/commit/2f3fe3ed97bcf778d73eda5aae9f166810a4af02
DIFF:
https://github.com/llvm/llvm-project/commit/2f3fe3ed97bcf778d73eda5aae9f166810a4af02.diff
1 - 100 of 306 matches
Mail list logo
