Should the warning be disabled for LLVM overall, rather than only for
this subproject? (& be good tohave some details in the commit at least
of why this warning is being disabled - how it is noisy/unhelpful/etc)
On Sun, Jul 19, 2020 at 8:20 AM Aaron Ballman via cfe-commits
wrote:
>
>
> Author: Aa
Cool - thanks for the context!
On Tue, Jul 21, 2020 at 5:44 AM Aaron Ballman
wrote:
> On Mon, Jul 20, 2020 at 5:44 PM David Blaikie wrote:
> >
> > Should the warning be disabled for LLVM overall, rather than only for
> > this subproject? (& be good tohave some details in the commit at least
> >
Author: David Blaikie
Date: 2020-07-21T20:57:12-07:00
New Revision: 36036aa70ec1df7b51b5d30b2dd8090ad2b6e783
URL:
https://github.com/llvm/llvm-project/commit/36036aa70ec1df7b51b5d30b2dd8090ad2b6e783
DIFF:
https://github.com/llvm/llvm-project/commit/36036aa70ec1df7b51b5d30b2dd8090ad2b6e783.diff
Author: David Blaikie
Date: 2020-07-21T21:51:59-07:00
New Revision: 6aea36fb98ed1e0c89cd6e3a24b76339a75aef68
URL:
https://github.com/llvm/llvm-project/commit/6aea36fb98ed1e0c89cd6e3a24b76339a75aef68
DIFF:
https://github.com/llvm/llvm-project/commit/6aea36fb98ed1e0c89cd6e3a24b76339a75aef68.diff
Thanks for that! Sorry I was a bit slow to get that cleaned up.
On Wed, Jul 22, 2020 at 12:41 AM Haojian Wu via cfe-commits
wrote:
>
>
> Author: Haojian Wu
> Date: 2020-07-22T09:38:56+02:00
> New Revision: 82dbb1b2b4f1e70ca453cca60a4ba5b856058fc0
>
> URL:
> https://github.com/llvm/llvm-project/c
Author: David Blaikie
Date: 2020-07-22T12:46:12-07:00
New Revision: b198de67e0bab462217db50814b1434796fa7caf
URL:
https://github.com/llvm/llvm-project/commit/b198de67e0bab462217db50814b1434796fa7caf
DIFF:
https://github.com/llvm/llvm-project/commit/b198de67e0bab462217db50814b1434796fa7caf.diff
Author: David Blaikie
Date: 2020-04-05T16:31:30-07:00
New Revision: e9644e6f4f21e6b6177ef9085cdc9ed9f44b7783
URL:
https://github.com/llvm/llvm-project/commit/e9644e6f4f21e6b6177ef9085cdc9ed9f44b7783
DIFF:
https://github.com/llvm/llvm-project/commit/e9644e6f4f21e6b6177ef9085cdc9ed9f44b7783.diff
Is this covered by existing tests?
On Thu, Jun 4, 2020 at 2:52 PM Alexey Bataev via cfe-commits
wrote:
>
>
> Author: Alexey Bataev
> Date: 2020-06-04T17:52:06-04:00
> New Revision: 4e3d4622b1e7bd419815510e5f7cd0f96595b2a3
>
> URL:
> https://github.com/llvm/llvm-project/commit/4e3d4622b1e7bd41981
I don't think the comment's adding value here - it should be fairly
clear from the context that the whole loop only exists for some
assertions.
Also: Could you remove the "(void)" casts now that the whole thing's
wrapped in NDEBUG?
(an alternative way of phrasing this that doesn't require the #if
On Tue, Jun 16, 2020 at 8:17 AM Kristóf Umann wrote:
>
> Apologies for the inconvenience, though I wonder why I haven't gotten
> builtbot mails :/
>
> On Tue, 16 Jun 2020 at 09:54, Haojian Wu wrote:
>>
>> On Mon, 15 Jun 2020 at 18:29, David Blaikie wrote:
>>>
>>> I don't think the comment's add
Author: Logan Smith
Date: 2020-07-12T16:05:24-07:00
New Revision: 67895d47558989f9f3a593a82527b016c7e7
URL:
https://github.com/llvm/llvm-project/commit/67895d47558989f9f3a593a82527b016c7e7
DIFF:
https://github.com/llvm/llvm-project/commit/67895d47558989f9f3a593a82527b016c7e7.diff
L
Author: David Blaikie
Date: 2020-07-12T19:43:24-07:00
New Revision: 49e5f603d40083dce9c05796e3cde3a185c3beba
URL:
https://github.com/llvm/llvm-project/commit/49e5f603d40083dce9c05796e3cde3a185c3beba
DIFF:
https://github.com/llvm/llvm-project/commit/49e5f603d40083dce9c05796e3cde3a185c3beba.diff
Author: David Blaikie
Date: 2020-07-12T20:29:19-07:00
New Revision: c94332919bd922032e979b3ae3ced5ca5bdf9650
URL:
https://github.com/llvm/llvm-project/commit/c94332919bd922032e979b3ae3ced5ca5bdf9650
DIFF:
https://github.com/llvm/llvm-project/commit/c94332919bd922032e979b3ae3ced5ca5bdf9650.diff
Author: David Blaikie
Date: 2020-06-23T15:18:49-07:00
New Revision: 4935419d779bdc6cc2f1c2f9e78821ad550d3b56
URL:
https://github.com/llvm/llvm-project/commit/4935419d779bdc6cc2f1c2f9e78821ad550d3b56
DIFF:
https://github.com/llvm/llvm-project/commit/4935419d779bdc6cc2f1c2f9e78821ad550d3b56.diff
Generally it'd be helpful to describe what the change is in the
subject line ("Add braces around initialization of a subobject
[-Wmissing-braces]") as that's more informative than "Silence compiler
warning [-Wmissing braces]", the latter doesn't say how it was
silenced, which might make a differenc
"Remove gold linker support from the PS4 toolchain" might've been a
more precise commit message - "Remove gold linker" seems a bit too
vague.
On Tue, Jun 16, 2020 at 1:03 PM Yuanfang Chen via cfe-commits
wrote:
>
>
> Author: Yuanfang Chen
> Date: 2020-06-16T13:03:31-07:00
> New Revision: 719c87ed
(ah, sorry, saw the follow-up commit where this was reverted/committed
by accident)
On Wed, Jun 24, 2020 at 1:50 PM David Blaikie wrote:
>
> "Remove gold linker support from the PS4 toolchain" might've been a
> more precise commit message - "Remove gold linker" seems a bit too
> vague.
>
> On Tue
Could/should this test be testing something more than "does not
crash"? I'd expect here's some specific behavior that would be
tested/desired rather than "anything other than crashing" - but I
understand if it's not practical to test, or perhap insufficiently
interesting with the new rephrased/fixe
Author: David Blaikie
Date: 2020-06-29T18:02:12-07:00
New Revision: 31c689e69404bb8208de9599626f60c77b6fa81d
URL:
https://github.com/llvm/llvm-project/commit/31c689e69404bb8208de9599626f60c77b6fa81d
DIFF:
https://github.com/llvm/llvm-project/commit/31c689e69404bb8208de9599626f60c77b6fa81d.diff
Author: David Blaikie
Date: 2020-06-29T22:08:20-07:00
New Revision: 11cd9770174603aa62deabbe96c7d0db64d07058
URL:
https://github.com/llvm/llvm-project/commit/11cd9770174603aa62deabbe96c7d0db64d07058
DIFF:
https://github.com/llvm/llvm-project/commit/11cd9770174603aa62deabbe96c7d0db64d07058.diff
Author: David Blaikie
Date: 2020-04-28T17:45:07-07:00
New Revision: c98a7e9bcc26a13d5e0b3fd199a7d0298777d85e
URL:
https://github.com/llvm/llvm-project/commit/c98a7e9bcc26a13d5e0b3fd199a7d0298777d85e
DIFF:
https://github.com/llvm/llvm-project/commit/c98a7e9bcc26a13d5e0b3fd199a7d0298777d85e.diff
Author: David Blaikie
Date: 2020-04-28T17:59:45-07:00
New Revision: d9485dfbc12b277e4ba222f4c0e371c5914fe51e
URL:
https://github.com/llvm/llvm-project/commit/d9485dfbc12b277e4ba222f4c0e371c5914fe51e
DIFF:
https://github.com/llvm/llvm-project/commit/d9485dfbc12b277e4ba222f4c0e371c5914fe51e.diff
Author: David Blaikie
Date: 2020-04-28T18:05:28-07:00
New Revision: 409df3987cb8d6c4a9005b2e633d0116c315375d
URL:
https://github.com/llvm/llvm-project/commit/409df3987cb8d6c4a9005b2e633d0116c315375d
DIFF:
https://github.com/llvm/llvm-project/commit/409df3987cb8d6c4a9005b2e633d0116c315375d.diff
Author: David Blaikie
Date: 2020-04-28T22:31:16-07:00
New Revision: fcee80737c3272dc9de2dfd9635a1e90db215c7a
URL:
https://github.com/llvm/llvm-project/commit/fcee80737c3272dc9de2dfd9635a1e90db215c7a
DIFF:
https://github.com/llvm/llvm-project/commit/fcee80737c3272dc9de2dfd9635a1e90db215c7a.diff
Author: David Blaikie
Date: 2020-04-28T22:31:16-07:00
New Revision: 9b77242c9a0089dca1ac4f80420b29492c5ed555
URL:
https://github.com/llvm/llvm-project/commit/9b77242c9a0089dca1ac4f80420b29492c5ed555
DIFF:
https://github.com/llvm/llvm-project/commit/9b77242c9a0089dca1ac4f80420b29492c5ed555.diff
Author: David Blaikie
Date: 2020-04-28T22:31:16-07:00
New Revision: e265f92b6e5e56b21fefdb83aec90f6e39c94857
URL:
https://github.com/llvm/llvm-project/commit/e265f92b6e5e56b21fefdb83aec90f6e39c94857
DIFF:
https://github.com/llvm/llvm-project/commit/e265f92b6e5e56b21fefdb83aec90f6e39c94857.diff
Author: David Blaikie
Date: 2020-04-28T22:31:15-07:00
New Revision: 4bd5fbec4bef71d79cbcd916237c8c7b467fb782
URL:
https://github.com/llvm/llvm-project/commit/4bd5fbec4bef71d79cbcd916237c8c7b467fb782
DIFF:
https://github.com/llvm/llvm-project/commit/4bd5fbec4bef71d79cbcd916237c8c7b467fb782.diff
Author: David Blaikie
Date: 2020-04-28T22:31:16-07:00
New Revision: cbae0d8221c7a5de229913754d4a6bf562a7db67
URL:
https://github.com/llvm/llvm-project/commit/cbae0d8221c7a5de229913754d4a6bf562a7db67
DIFF:
https://github.com/llvm/llvm-project/commit/cbae0d8221c7a5de229913754d4a6bf562a7db67.diff
Author: David Blaikie
Date: 2020-04-28T22:31:17-07:00
New Revision: 628829254d35bd3dfd1bff29f8afeaf464aafde9
URL:
https://github.com/llvm/llvm-project/commit/628829254d35bd3dfd1bff29f8afeaf464aafde9
DIFF:
https://github.com/llvm/llvm-project/commit/628829254d35bd3dfd1bff29f8afeaf464aafde9.diff
Would be helpful to document in the commit message why a change is being made.
On Wed, Aug 5, 2020 at 6:13 AM Bruno Ricci via cfe-commits
wrote:
>
>
> Author: Bruno Ricci
> Date: 2020-08-05T14:13:05+01:00
> New Revision: 4dcbb9cef71afa549afe8f6b4d335b1c996f8079
>
> URL:
> https://github.com/llvm
On Mon, May 11, 2020 at 12:21 AM Haojian Wu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
> Author: Haojian Wu
> Date: 2020-05-11T09:20:48+02:00
> New Revision: d82538b3f691f3ba1cb7a945a5f8594f71816fdf
>
> URL:
> https://github.com/llvm/llvm-project/commit/d82538b3f691f3ba1cb7a945a5f8594f
+Mr. Smith for visibility.
I'm /guessing/ the right path might be to change the implementation of
getFullyQualifiedName to use the type printing/pretty printer approach with
the extra feature you're suggesting. That way all users get the desired
behavior
+Sam McCall who (if I understand correct
On Tue, May 12, 2020 at 12:40 PM Jean-Baptiste Lespiau
wrote:
> Hi,
>
> thanks for your answer.
>
> Just a few remarks:
>
> 1. I imagine that we cannot know if people are using
> getFullyQualifiedName. In particular, people could have developed their own
> internal tools, thus we cannot be aware
ping
On Mon, Sep 12, 2016 at 5:20 PM David Blaikie wrote:
> On Mon, Sep 12, 2016 at 5:09 PM Reid Kleckner via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: rnk
> Date: Mon Sep 12 19:01:23 2016
> New Revision: 281278
>
> URL: http://llvm.org/viewvc/llvm-project?rev=281278&view=re
Do you have some data on the true/false positive rate for this warning?
On Fri, Sep 23, 2016 at 6:12 AM Daniel Marjamäki <
daniel.marjam...@evidente.se> wrote:
> danielmarjamaki created this revision.
> danielmarjamaki added reviewers: dblaikie, rtrieu.
> danielmarjamaki added a subscriber: cfe-c
I'd still wonder if this meets the bar for false positives (generally we
try to only add warnings that would be enabled by default, even in new
codebases - where most of what they find in a newcodebase are latent bugs,
not noise (so the cleanup is at least fairly justified as being beneficial
in it
dblaikie added inline comments.
> debug-options.c:21-22
>
> +// RUN: %clang -### -c -Og -g %s -target x86_64-linux-gnu 2>&1 \
> +// RUN: | FileCheck -check-prefix=G -check-prefix=G_GDB %s
> +
I don't think we need this test case: -Og doesn't actually have anything to do
with -g me
On Thu, Oct 6, 2016 at 6:16 AM Alex Lorenz wrote:
> arphaman created this revision.
> arphaman added reviewers: dblaikie, krememek.
> arphaman added a subscriber: cfe-commits.
> arphaman set the repository for this revision to rL LLVM.
>
> This patch fixes the issue of clang emitting an unreachab
Could you explain how/why there's a null size expr? I would've thought it
must have /some/ size for code generation purposes...
On Fri, Oct 7, 2016 at 11:33 AM Erich Keane wrote:
> erichkeane created this revision.
> erichkeane added reviewers: cfe-commits, dblaikie, majnemer, gbenyei.
> erichke
Ping - I have a pretty clear workaround internally, but still would be
happy to remove any workarounds given the opportunity.
As for layering. For now the issue is that libAST depends on libBasic, and
libraries can't have circular dependencies. Modular builds (well,
especially modular codegen, but
Thanks!
On Wed, Dec 6, 2017 at 2:12 AM Sven van Haastregt via Phabricator <
revi...@reviews.llvm.org> wrote:
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rC319883: [OpenCL] Fix layering violation by
> getOpenCLTypeAddrSpace (authored by svenvh).
>
My bet would be: warn and ignore it, but probably Richard's & John might
have stronger thoughts/justifications/etc.
On Mon, Dec 11, 2017 at 1:38 PM Akira Hatanaka via Phabricator <
revi...@reviews.llvm.org> wrote:
> ahatanak added a comment.
>
> I had a discussion with Duncan today and he pointed
On Mon, Dec 11, 2017 at 3:16 PM John McCall via Phabricator <
revi...@reviews.llvm.org> wrote:
> rjmccall added a comment.
>
> In https://reviews.llvm.org/D41039#951648, @ahatanak wrote:
>
> > I had a discussion with Duncan today and he pointed out that perhaps we
> shouldn't allow users to annota
On Mon, Dec 11, 2017 at 5:38 PM John McCall wrote:
> On Mon, Dec 11, 2017 at 6:19 PM, David Blaikie wrote:
>
>> On Mon, Dec 11, 2017 at 3:16 PM John McCall via Phabricator <
>> revi...@reviews.llvm.org> wrote:
>>
>>> rjmccall added a comment.
>>>
>>> In https://reviews.llvm.org/D41039#951648, @a
Mixed feelings here - Kazu's made a lot of cleanup/stylistic changes
across the LLVM project for a while now, most, at least I think, are
quite welcome (things like switching to range-based-for, std
algorithms over llvm ones, llvm algorithms over manually written
loops, etc). But yeah, there's some
On Fri, Aug 26, 2022 at 2:10 PM Christopher Di Bella via cfe-commits
wrote:
>
>
> Author: Abraham Corea Diaz
> Date: 2022-08-26T21:09:39Z
> New Revision: 0e5813b88e50576940070003e093d696390a6959
>
> URL:
> https://github.com/llvm/llvm-project/commit/0e5813b88e50576940070003e093d696390a6959
> DIFF
On Sat, Sep 10, 2022 at 3:01 PM Kazu Hirata wrote:
>
> Thank you Aaron and David for your inputs.
>
> First and foremost, I apologize if I made your job harder by increasing the
> number of commits you have to peel to get to the real author.
>
> I hear that we are moving toward github pull reques
Author: Azat Khuzhin
Date: 2022-09-13T22:33:56Z
New Revision: 6bf6730ac55e064edf46915ebba02e9c716f48e8
URL:
https://github.com/llvm/llvm-project/commit/6bf6730ac55e064edf46915ebba02e9c716f48e8
DIFF:
https://github.com/llvm/llvm-project/commit/6bf6730ac55e064edf46915ebba02e9c716f48e8.diff
LOG:
dwblaikie wrote:
Please don't commit changes that have been sent for review, but have not been
reviewed.
https://github.com/llvm/llvm-project/pull/71031
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
dwblaikie wrote:
We probably (pretty sure) don't want to add a virtual dtor to SmallVector -
that'd add a vtable pointer, increasing the size in ways that are probably
unacceptable given the pervasive use of the data structure.
We should make the Impl dtor protected so it can't be polymorphica
dwblaikie wrote:
The words probably don't need to be short.
Interface BMI
Implementation BMI
Seem like fine, accurate terms. I guess we could say "BMInterface" and
"BMImplementation" but probably best to jus tgloss over "I" being "interface"
and have "interface BMI" and "implementation BMI"
Any chance this could/should reference the length by name, rather than by
casts and pointer math? (so it's resilient to at least some changes to
StringLiteral/StringRef?) Or is this the preferred way to write Natvis
visualizers, so they're resilient to missing debug info or something?
On Sun, Nov
On Mon, Nov 13, 2023 at 4:28 AM Aaron Ballman
wrote:
> On Sun, Nov 12, 2023 at 11:42 PM David Blaikie wrote:
> >
> > Any chance this could/should reference the length by name, rather than
> by casts and pointer math? (so it's resilient to at least some changes to
> StringLiteral/StringRef?) Or i
dwblaikie wrote:
Might be worth cconsidering the points in "Contributing Extensions to Clang"
here: https://clang.llvm.org/get_involved.html
It'd be great if there were some numbers/metrics associated with the benefit,
ideally on some open source/commonly accessible codebase.
https://github.c
dwblaikie wrote:
I'd still like to know more about what other implementations do - see ongoing
discussion on the original issue.
https://github.com/llvm/llvm-project/pull/74419
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm
dwblaikie wrote:
> To support access to such constants from LLDB we'll most likely have to have
> to make LLDB find the constants by looking at the containing class first.
Tangentially related to:
https://discourse.llvm.org/t/rfc-improve-dwarf-5-debug-names-type-lookup-parsing-speed/74151/31?u
dwblaikie wrote:
Probably would be good to introduce the `-v1` version and require it first,
then eventually change the default - so people don't get a silent behavior
change? Even the existing users only using `*` and `.` need to change their
syntax to migrate to v2, right? They'll need to ch
dwblaikie wrote:
> > Probably would be good to introduce the `-v1` version and require it first,
> > then eventually change the default - so people don't get a silent behavior
> > change? Even the existing users only using `*` and `.` need to change their
> > syntax to migrate to v2, right? Th
dwblaikie wrote:
Still seems like an unfortunate and subtle silent change in behavior to me. But
*shrug* if folks who own these features think it's fine, so be it.
https://github.com/llvm/llvm-project/pull/74809
___
cfe-commits mailing list
cfe-commit
https://github.com/dwblaikie approved this pull request.
Sounds good to me, thanks!
https://github.com/llvm/llvm-project/pull/75022
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dwblaikie approved this pull request.
SGTM
https://github.com/llvm/llvm-project/pull/72235
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -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
@@ -0,0 +1,48 @@
+// RUN: %clang_cl --target=x86_64-windows-msvc /c /Z7 -o %t.obj -- %s
dwblaikie wrote:
Generally clang tests don't test end-to-end. If the code change only affects
clang IR generation, the test should only test clang IR generation, not all the
dwblaikie wrote:
Hmm, I can't quite tell from the test case updates in the patch, at least at a
glance: How does this get encoded at the IR level? Do we end up with two
DIGlobalVariableExpressions? One with the constant value expresison, and one
that references the actual global variable? Or s
https://github.com/dwblaikie approved this pull request.
Looks plausible to me, thanks!
https://github.com/llvm/llvm-project/pull/71564
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
> My understanding was that the DIExpression parameter to
> DIGlobalVariableExpression was empty for global variables with locations. So
> the patch just encodes the constant into that expression if it's otherwise
> empty.
I think in theory it can be non-empty (see what happe
dwblaikie wrote:
https://github.com/llvm/llvm-project/blob/abd85cd473afedf112bf00630a22382fee4a7853/llvm/lib/CodeGen/GlobalMerge.cpp#L531
- this is around where I think we'd get a global with a location and a
non-empty expression
https://github.com/llvm/llvm-project/pull/72730
dwblaikie wrote:
(patches like this should probably be broken up - test changes to the defaults
in lld and llvm for instance don't depend on the change to the clang driver
which is the only real semantic change in this patch, right? So probably only
change the semantics of clang, and the tests
dwblaikie wrote:
I'm still really hesitant about this direction.
One starting concern: what happens if someone adds an overload, or other
interesting name resolution to the module? The downstream caller hasn't
textually changed, but it should be rebuilt because it should be calling a
differen
https://github.com/dwblaikie closed
https://github.com/llvm/llvm-project/pull/71564
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4708,12 +4708,12 @@ defm amdgpu_ieee : BoolOption<"m", "amdgpu-ieee",
NegFlag>, Group;
def mcode_object_version_EQ : Joined<["-"], "mcode-object-version=">,
Group,
- HelpText<"Specify code object ABI version. Defaults to 4. (AMDGPU only)">,
+ HelpText<"Specify code ob
@@ -2402,7 +2402,7 @@ void tools::checkAMDGPUCodeObjectVersion(const Driver &D,
unsigned tools::getAMDGPUCodeObjectVersion(const Driver &D,
const llvm::opt::ArgList &Args) {
- unsigned CodeObjVer = 4; // default
+ unsigned CodeObjVe
https://github.com/dwblaikie closed
https://github.com/llvm/llvm-project/pull/73000
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
Generally when we split things up, they're separate reviews and separate
commits. fixups are for necessary changes that need to be applied atomically
(fixes to the base patch in a pull request, etc).
https://github.com/llvm/llvm-project/pull/73000
dwblaikie wrote:
(part of the point is so that patches can be reverted as needed without having
to revert/reapply huge patches when they aren't actually dependent)
https://github.com/llvm/llvm-project/pull/73000
___
cfe-commits mailing list
cfe-commit
dwblaikie wrote:
> This commit also fixes commit
> https://github.com/llvm/llvm-project/commit/d3676d4b666ead794fc58bbc7e07aa406dcf487a
> that caused all headers to have NameAsWritten set to a 0-length string
> without adapting compareModuleHeaders() to the new field.
Sorry, I don't quite und
Does this diagnostic have test coverage, could it be expanded to check the
spelling here? (mostly as a motivation to ensure this diagnostic is
actually tested... )
On Mon, Nov 20, 2023 at 3:04 AM via cfe-commits
wrote:
>
> Author: Utkarsh Saxena
> Date: 2023-11-20T12:04:32+01:00
> New Revision:
dwblaikie wrote:
> Splitting it wouldn't help with bisect, as we would continue having a broken
> commit.
Not sure I understand - presumably this bug has existed for a while, separate
from the qsort issue? So fixing it separately seems good so that patches do one
thing clearly - makes it easy
@@ -0,0 +1,87 @@
+// RUN: %clangxx -target arm64-apple-macosx11.0.0 -g %s -emit-llvm -S -o - |
FileCheck --check-prefixes=CHECK %s
+
+enum class Enum : int {
+ VAL = -1
+};
+
+struct Empty {};
+
+constexpr auto func() { return 25; }
+
+struct Foo {
+static constexpr int cexp
dwblaikie wrote:
> Should not we remove constant initializer from the type definition if we have
> a DW_TAG_variable with a DW_AT_const_value now?
Yep, +1 to this. This is where the type normalization benefit would come from -
no longer having this const value on the member declaration, but on
dwblaikie wrote:
> Summing the size of all *.o files in my local debug Clang build increased by
> 0.7% with this patch
That's a bit significant. Any chance you could get a per-section
breakdown/growth on that? (& exact flags - is this with compressed debug info,
for instance? Or not?) I use `
@@ -5935,3 +5918,29 @@ llvm::DINode::DIFlags
CGDebugInfo::getCallSiteRelatedAttrs() const {
return llvm::DINode::FlagAllCallsDescribed;
}
+
+llvm::DIExpression *
+CGDebugInfo::createConstantValueExpression(const clang::ValueDecl *VD,
+
@@ -5935,3 +5918,29 @@ llvm::DINode::DIFlags
CGDebugInfo::getCallSiteRelatedAttrs() const {
return llvm::DINode::FlagAllCallsDescribed;
}
+
+llvm::DIExpression *
+CGDebugInfo::createConstantValueExpression(const clang::ValueDecl *VD,
+
@@ -5935,3 +5918,29 @@ llvm::DINode::DIFlags
CGDebugInfo::getCallSiteRelatedAttrs() const {
return llvm::DINode::FlagAllCallsDescribed;
}
+
+llvm::DIExpression *
+CGDebugInfo::createConstantValueExpression(const clang::ValueDecl *VD,
+
dwblaikie wrote:
> > > Should not we remove constant initializer from the type definition if we
> > > have a DW_TAG_variable with a DW_AT_const_value now?
> >
> >
> > Yep, +1 to this. This is where the type normalization benefit would come
> > from - no longer having this const value on the m
dwblaikie wrote:
size report sounds generally OK - but there's a bunch of what look like
unrelated or strange results in there, perhaps they weren't compared at exactly
the same version? (like why did the apple_names size go down? How did the .text
and .debuG_line size change at all? )
https:
https://github.com/dwblaikie approved this pull request.
Looks great - thanks!
https://github.com/llvm/llvm-project/pull/70674
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -67,15 +67,15 @@ int C::a = 4;
// CHECK-NOT:size:
// CHECK-NOT:align:
// CHECK-NOT:offset:
-// CHECK-SAME: flags: DIFlagStaticMember,
-// CHECK-SAME: extraData: i1 true)
+// CHECK-SAME: flags: DIFlagStaticMemb
@@ -5883,6 +5907,18 @@ void CGDebugInfo::finalize() {
DBuilder.replaceTemporary(std::move(FwdDecl), cast(Repl));
}
+ for (auto const *VD : StaticDataMemberDefinitionsToEmit) {
+assert(VD->isStaticDataMember());
+
+if (auto It = DeclCache.find(VD); It != DeclCach
@@ -0,0 +1,87 @@
+// RUN: %clangxx -target arm64-apple-macosx11.0.0 -g %s -emit-llvm -S -o - |
FileCheck --check-prefixes=CHECK %s
+
+enum class Enum : int {
+ VAL = -1
+};
+
+struct Empty {};
+
+constexpr auto func() { return 25; }
+
+struct Foo {
+static constexpr int cexp
https://github.com/dwblaikie approved this pull request.
Few minor issues, but looks good to me.
(you metnioned somewhere an lldb issue I think with this patch when the value
is removed from the static member declaration inside the class? If that's a
problem - probably hold off on committing th
dwblaikie wrote:
> That's true, if defined in a header, we'll emit a DW_TAG_variable for the
> constant in each compile unit the header is included in. GCC does do the
> right thing and only emit the definition DIE in a single CU. We should
> probably do the same. Though not sure at which leve
dwblaikie wrote:
> 2) always put DW_AT_const_value in DW_TAG_member.
My understanding is that this is not possible. Dependent initializer
expressions can't be evaluated in all cases - we're only allowed to evaluate
them in the places the language allows us to, otherwise we might produce the
w
dwblaikie wrote:
FWIW, we saw failures at Google (where, to the best of my knowledge, we aren't
using named modules at all) that look like this:
```
error: '#include ' attaches the declarations to the named module
'.get', which is not usually intended; consider moving that directive before
the
https://github.com/dwblaikie approved this pull request.
SGTM
https://github.com/llvm/llvm-project/pull/75142
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,50 @@
+// REQUIRES: !system-windows
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+//
+// RUN: %clang_cc1 -std=c++20 %t/layer1.cppm -triple %itanium_abi_triple \
+// RUN: -emit-module-interface -o %t/foo-layer1.pcm
+// RUN: %clang_cc1 -std=c++20 %t/l
@@ -0,0 +1,50 @@
+// REQUIRES: !system-windows
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+//
+// RUN: %clang_cc1 -std=c++20 %t/layer1.cppm -triple %itanium_abi_triple \
+// RUN: -emit-module-interface -o %t/foo-layer1.pcm
+// RUN: %clang_cc1 -std=c++20 %t/l
@@ -0,0 +1,50 @@
+// REQUIRES: !system-windows
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+//
+// RUN: %clang_cc1 -std=c++20 %t/layer1.cppm -triple %itanium_abi_triple \
+// RUN: -emit-module-interface -o %t/foo-layer1.pcm
+// RUN: %clang_cc1 -std=c++20 %t/l
@@ -0,0 +1,50 @@
+// REQUIRES: !system-windows
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+//
+// RUN: %clang_cc1 -std=c++20 %t/layer1.cppm -triple %itanium_abi_triple \
+// RUN: -emit-module-interface -o %t/foo-layer1.pcm
+// RUN: %clang_cc1 -std=c++20 %t/l
https://github.com/dwblaikie approved this pull request.
Sounds reasonable to me, thanks!
https://github.com/llvm/llvm-project/pull/73146
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
201 - 300 of 1480 matches
Mail list logo
