https://github.com/ldionne closed
https://github.com/llvm/llvm-project/pull/85097
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne updated
https://github.com/llvm/llvm-project/pull/94791
>From 61a434bae9f3787122e123540b7c379f410e037b Mon Sep 17 00:00:00 2001
From: Louis Dionne
Date: Fri, 31 May 2024 10:55:53 -0700
Subject: [PATCH 1/2] [libc++] Fix deployment target Lit features
We were not makin
https://github.com/ldionne created
https://github.com/llvm/llvm-project/pull/94791
We were not making any distinction between e.g. the "Apple-flavored" libc++
built from trunk and the system-provided standard library on Apple platforms.
For example, any test that would be XFAILed on a back-dep
https://github.com/ldionne approved this pull request.
This patch isn't blocked by libc++, thanks for fixing the incorrect usage. This
isn't a review of the patch itself, just unblocking for libcxx-reviewers.
https://github.com/llvm/llvm-project/pull/92957
__
https://github.com/ldionne approved this pull request.
https://github.com/llvm/llvm-project/pull/93354
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne edited
https://github.com/llvm/llvm-project/pull/93354
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ldionne wrote:
Not pursuing anymore, closing to clean up the queue.
https://github.com/llvm/llvm-project/pull/66265
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne closed
https://github.com/llvm/llvm-project/pull/66265
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne closed
https://github.com/llvm/llvm-project/pull/93558
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ldionne wrote:
CI failure is an android fluke, merging!
https://github.com/llvm/llvm-project/pull/93558
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne closed
https://github.com/llvm/llvm-project/pull/93542
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ldionne wrote:
Can we either finish this up or close it, please? I'd like to tidy up the
libc++ review queue.
https://github.com/llvm/llvm-project/pull/86806
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
https://github.com/ldionne approved this pull request.
libcxx/ changes LGTM.
https://github.com/llvm/llvm-project/pull/93417
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne updated
https://github.com/llvm/llvm-project/pull/93542
>From 95ca5b389506f0a2e32abd0af632af5a87d3c356 Mon Sep 17 00:00:00 2001
From: Louis Dionne
Date: Tue, 28 May 2024 07:43:34 -0400
Subject: [PATCH 1/2] [runtimes] Reintroduce a way to select the compiler used
for
https://github.com/ldionne created
https://github.com/llvm/llvm-project/pull/93558
Instead of using FOO_TEST_DEPS global variables that don't get updated properly
from subdirectories, use targets to propagate the dependencies across
directories.
>From 1681e650b2fa0f0efab760eec341d2372873218b
https://github.com/ldionne created
https://github.com/llvm/llvm-project/pull/93542
A while back, the cxx_under_test Lit parameter was removed. This patch
reintroduces a Lit parameter called "compiler" which controls the value of the
%{cxx} substitution used in the test suite.
To run the test
@@ -1,82 +0,0 @@
-#===--===##
ldionne wrote:
I did check and it can be removed. I wrote that script so hopefully I’m not
mistaken!
I will also go and clean up (remove the clang-ci pipeline on B
@@ -1,82 +0,0 @@
-#===--===##
ldionne wrote:
`clang/utils/ci/run-buildbot` can be removed too, I think.
https://github.com/llvm/llvm-project/pull/93318
__
@@ -54,3 +54,68 @@ cmake -S "${MONOREPO_ROOT}"/llvm -B "${BUILD_DIR}" \
echo "--- ninja"
# Targets are not escaped as they are passed as separate arguments.
ninja -C "${BUILD_DIR}" -k 0 ${targets}
+
ldionne wrote:
It seems that we disagree on the approach take
@@ -54,3 +54,68 @@ cmake -S "${MONOREPO_ROOT}"/llvm -B "${BUILD_DIR}" \
echo "--- ninja"
# Targets are not escaped as they are passed as separate arguments.
ninja -C "${BUILD_DIR}" -k 0 ${targets}
+
+runtimes="${3}"
+runtime_targets="${4}"
+
+# Compiling runtimes with just-buil
@@ -54,3 +54,68 @@ cmake -S "${MONOREPO_ROOT}"/llvm -B "${BUILD_DIR}" \
echo "--- ninja"
# Targets are not escaped as they are passed as separate arguments.
ninja -C "${BUILD_DIR}" -k 0 ${targets}
+
+runtimes="${3}"
+runtime_targets="${4}"
+
+# Compiling runtimes with just-buil
https://github.com/ldionne requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/93318
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -54,3 +54,68 @@ cmake -S "${MONOREPO_ROOT}"/llvm -B "${BUILD_DIR}" \
echo "--- ninja"
# Targets are not escaped as they are passed as separate arguments.
ninja -C "${BUILD_DIR}" -k 0 ${targets}
+
ldionne wrote:
I don't think it makes sense to serialize all
https://github.com/ldionne edited
https://github.com/llvm/llvm-project/pull/93318
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne edited
https://github.com/llvm/llvm-project/pull/93318
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ldionne wrote:
I will merge once the CI has passed. If someone else sees the CI green, feel
free to merge too.
@Endilll We could indeed "flatten" the `clang-ci` pipeline into the
`github-pull-requests` pipeline. Basically, instead of triggering the
`clang-ci` pipeline like this:
https://gith
ldionne wrote:
> Do we even need to build Clang and run libc++ jobs? I don't even see them
> linked in libc++ PR, even besides the fact that I think libc++ is fully
> tested with GitHub Actions.
What we're testing is that the changes to Clang didn't break libc++. We're
testing Clang via libc+
https://github.com/ldionne updated
https://github.com/llvm/llvm-project/pull/93233
>From 89afeebd55e0ae1167f5af803eb192b73a6e6799 Mon Sep 17 00:00:00 2001
From: Louis Dionne
Date: Thu, 23 May 2024 15:31:11 -0400
Subject: [PATCH 1/2] [clang][ci] Remove unnecessary BuildKite jobs for Clang
1. Re
https://github.com/ldionne created
https://github.com/llvm/llvm-project/pull/93233
1. Remove the format-checking job from the BuildKite pipeline. We now have a
monorepo-wide format checker implemented with Github Actions, so that should
not be necessary anymore.
2. Stop building and testing C
https://github.com/ldionne updated
https://github.com/llvm/llvm-project/pull/90803
>From 4871a82495e0056483759fa207ffbecd63b1e2f8 Mon Sep 17 00:00:00 2001
From: Louis Dionne
Date: Wed, 1 May 2024 18:10:07 -0600
Subject: [PATCH] [libc++][WIP] Move the libc++ test format to Lit
This allows the g
@@ -0,0 +1,355 @@
+#
===--===##
+#
+# Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+# See https://llvm.org/LICENSE.txt for license information.
+# SPDX-License-Identifier: Apache-
ldionne wrote:
> @ldionne, do you find @arichardson reasoning good enough to proceed with
> merging this PR?
I'm not convinced. We use `#include ` pretty consistently in libc++ and
libc++abi and we should strive for all the runtimes to be consistent. I am
especially not convinced that the end
https://github.com/ldionne approved this pull request.
Let's try this again. Thanks for your perseverance, this is obviously not easy
to land but it's important to get it done. Let's hope everything has been
addressed this time around.
https://github.com/llvm/llvm-project/pull/90373
__
https://github.com/ldionne updated
https://github.com/llvm/llvm-project/pull/90803
>From ecab1e5689f9f7ea6f87d9cc8c51910b733f6859 Mon Sep 17 00:00:00 2001
From: Louis Dionne
Date: Wed, 1 May 2024 18:10:07 -0600
Subject: [PATCH] [libc++][WIP] Move the libc++ test format to Lit
This allows the g
https://github.com/ldionne approved this pull request.
The libc++abi changes look fine to me.
https://github.com/llvm/llvm-project/pull/90391
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co
ldionne wrote:
> > I'd rather keep the libc++ tests green while landing this PR. I tried
> > something out, let's see if that works.
>
> It looks like some further adjustments may be needed as some stage1 builders
> are failing:
>
> ```
> [...]
> ```
Ah, yes, we're using the nightly clang wh
https://github.com/ldionne approved this pull request.
I'd rather keep the libc++ tests green while landing this PR. I tried something
out, let's see if that works.
Otherwise LGTM, thanks for tackling this long-standing item on our TODO list :-)
https://github.com/llvm/llvm-project/pull/89446
ldionne wrote:
> > > > For SystemZ the correct value is 256.
> > >
> > >
> > > Thanks! Double-checking: for both constructive and destructive?
> >
> >
> > Yes, for both. Every SystemZ model (supported by GCC/LLVM) has a L1 cache
> > line size of 256 bytes.
>
> Excellent, thank you!
>
> > >
https://github.com/ldionne approved this pull request.
LGTM, the equivalent patch was approved on Phab too.
https://github.com/llvm/llvm-project/pull/89425
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
ldionne wrote:
I just approved the CI runs. I think this can be merged once the CI is all
green. Whoever sees this first with push access can merge.
https://github.com/llvm/llvm-project/pull/88406
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
ldionne wrote:
> > Thanks for the explanation, @AaronBallman . I think I am generally deeply
> > confused about what should be provided by the compiler and what should be
> > provided by the C Standard Library on any given platform. From your reply,
> > it looks like there's no clear rule and
ldionne wrote:
Thanks for the explanation, @AaronBallman . I think I am generally deeply
confused about what should be provided by the compiler and what should be
provided by the C Standard Library on any given platform. From your reply, it
looks like there's no clear rule and Clang basically
ldionne wrote:
> > Why do the Clang builtin headers even try to define this? Shouldn't this be
> > provided by the platform's C library instead? I am really confused about
> > what's the intended layering here and it seems to me like Clang is
> > overstepping its responsibilities by basically
@@ -24,16 +23,30 @@
#include
#include
+// Note: this test fails on musl because:
+//
+// (a) musl disables emission of unwind information for its build, and
+// (b) musl's signal trampolines don't include unwind information
+//
ldionne wrote:
This comment
@@ -24,16 +23,30 @@
#include
#include
+// Note: this test fails on musl because:
+//
+// (a) musl disables emission of unwind information for its build, and
+// (b) musl's signal trampolines don't include unwind information
+//
ldionne wrote:
Same here.
ldionne wrote:
Why do the Clang builtin headers even try to define this? Shouldn't this be
provided by the platform's C library instead? I am really confused about what's
the intended layering here and it seems to me like Clang is overstepping its
responsibilities by basically implementing par
https://github.com/ldionne approved this pull request.
Libc++ parts LGTM.
https://github.com/llvm/llvm-project/pull/86806
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ldionne wrote:
/cherry-pick 1f973efd335f34c75fcba1ccbe288fd5ece15a64
https://github.com/llvm/llvm-project/pull/84917
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne closed
https://github.com/llvm/llvm-project/pull/84917
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne milestoned
https://github.com/llvm/llvm-project/pull/84917
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne approved this pull request.
https://github.com/llvm/llvm-project/pull/84917
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne approved this pull request.
https://github.com/llvm/llvm-project/pull/83774
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne updated
https://github.com/llvm/llvm-project/pull/80007
>From 01012cc48d339a269825725baf62c25707943b7c Mon Sep 17 00:00:00 2001
From: Louis Dionne
Date: Wed, 12 Oct 2022 18:06:32 -0400
Subject: [PATCH] [runtimes] Always define cxx_shared, cxx_static & other
targets
@@ -2912,16 +2912,70 @@ static bool sdkSupportsBuiltinModules(const
Darwin::DarwinPlatformKind &TargetPl
}
}
-void Darwin::addClangTargetOptions(const llvm::opt::ArgList &DriverArgs,
- llvm::opt::ArgStringList &CC1Args,
-
https://github.com/ldionne commented:
The version map seems correct to me. I have a comment about z/OS appearing in a
place it shouldn't but apart from that LGTM. Heads up @ahatanak you probably
want to have a quick look as well since you did a lot of work around aligned
allocation on Apple pl
@@ -2912,16 +2912,70 @@ static bool sdkSupportsBuiltinModules(const
Darwin::DarwinPlatformKind &TargetPl
}
}
-void Darwin::addClangTargetOptions(const llvm::opt::ArgList &DriverArgs,
- llvm::opt::ArgStringList &CC1Args,
-
https://github.com/ldionne edited
https://github.com/llvm/llvm-project/pull/83774
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ldionne wrote:
> > So the intent of the current ordering was to allow creating a toolchain by
> > placing the libc++ headers alongside Clang, as is typically done (and
> > exceptionally not done on Apple platforms). On Apple platforms, you
> > basically always specify a sysroot, either explici
https://github.com/ldionne closed
https://github.com/llvm/llvm-project/pull/79157
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ldionne wrote:
Doing ad-hoc changes like that to provide an apparent guarantee without
actually documenting it, testing it and enforcing it throughout is just
churning the code base. Unless we actually have a plan to do that properly, I
would push back this change. I understand you're just try
https://github.com/ldionne updated
https://github.com/llvm/llvm-project/pull/79157
>From c525b81664d23e3bc75fb6b795459bcbb7e305a4 Mon Sep 17 00:00:00 2001
From: Louis Dionne
Date: Tue, 23 Jan 2024 10:51:53 -0500
Subject: [PATCH 1/3] [clang] Document the type_visibility attribute
I was looking
https://github.com/ldionne updated
https://github.com/llvm/llvm-project/pull/79157
>From c525b81664d23e3bc75fb6b795459bcbb7e305a4 Mon Sep 17 00:00:00 2001
From: Louis Dionne
Date: Tue, 23 Jan 2024 10:51:53 -0500
Subject: [PATCH 1/2] [clang] Document the type_visibility attribute
I was looking
@@ -5557,6 +5557,21 @@ See :doc:`LTOVisibility`.
}];
}
+def TypeVisibilityDocs : Documentation {
+ let Category = DocCatType;
+ let Content = [{
+The ``type_visibility`` attribute allows the ELF visibility of a type and its
vague
+linkage objects (vtable, typeinfo, typein
@@ -5557,6 +5557,21 @@ See :doc:`LTOVisibility`.
}];
}
+def TypeVisibilityDocs : Documentation {
+ let Category = DocCatType;
+ let Content = [{
+The ``type_visibility`` attribute allows the ELF visibility of a type and its
vague
+linkage objects (vtable, typeinfo, typein
@@ -5557,6 +5557,21 @@ See :doc:`LTOVisibility`.
}];
}
+def TypeVisibilityDocs : Documentation {
+ let Category = DocCatType;
+ let Content = [{
+The ``type_visibility`` attribute allows the ELF visibility of a type and its
vague
ldionne wrote:
I don't k
ldionne wrote:
> Yes. What I think Dmitry and I are trying to explain is that it is very weird
> that providing an explicit `-isysroot` in the command line is ignored for the
> C++ headers (and only for them). One can start using `-nostdinc` and friends,
> but that mean rebuilding the header s
ldionne wrote:
> @ldionne if downstream is catching upstream, I would love to discuss
> rationale behind ignoring command line option. I asked this question several
> times and haven't got answer. Original
> [diff](https://reviews.llvm.org/D89001) that introduced this behavior also
> didn't e
ldionne wrote:
If we do that, we’ll just create churn. It’s a moving target.
You will « fix » upstream Clang to match « the system compiler » temporarily,
but by doing so you’re causing the downstream Clang to ingest that change too
via auto-merging and that means you’ll flip-flop the state of
ldionne wrote:
Woah, I just checked Xcode 15.2 and you are totally right, it contains
`clang-1500.1.0.2.5` which still has the behavior reversed from upstream. Sorry
for the confusion, I assumed it was out in recent Xcodes cause the change was
made a while back, but it looks like this change s
ldionne wrote:
@dmpolukhin
Replying to https://reviews.llvm.org/D157283#4648445:
> @ldionne thank you for the reply. Unfortunately current behaviour makes
> problems for clang-tools like clang-tidy and clangd that read CDBs from
> compile_commands.json. They start looking headers relative to
ldionne wrote:
In https://reviews.llvm.org/D157283#4648242, I explained that the current
upstream code actually matches exactly what we have downstream. I made sure to
upstream everything to avoid differences after we started shipping libc++ in
the SDK and were done with our transition.
@drod
https://github.com/ldionne requested changes to this pull request.
We require that the right paths be setup with `-I` or `-isystem` as a general
requirement of libc++, libc++abi and libunwind. This change seems brittle to
me, especially if there's no test or no official guarantee being added an
ldionne wrote:
> I am concerned that `-fstdlib-hardening=` may not map to libstdc++ preferred
> enabling mechanism cleanly. There is a non-zero probability that GCC folks
> would not add an option that just passes a `-D...` to cc1. Then this driver
> option will feel like a libc++ specific fea
ldionne wrote:
CC @petrhosek @vitalybuka since this broke your setups last time. The
reproduction steps were really non-trivial so I never got around to
reproducing, but it would be great to see if this is still problematic.
https://github.com/llvm/llvm-project/pull/80007
_
https://github.com/ldionne created
https://github.com/llvm/llvm-project/pull/80007
However, mark them as EXCLUDE_FROM_ALL when we don't want to build them. Simply
declaring the targets should be of no harm, and it allows other projects to
mention these targets regardless of whether they end up
ldionne wrote:
> > > I am on the fence whether a driver option is really needed. It is a very
> > > shallow layer of extra abstraction that a curious reader has to look
> > > through. I guess I'll not object to this, if people really want to add it.
> >
> >
> > Setting macros that are reserve
ldionne wrote:
> I am on the fence whether a driver option is really needed. It is a very
> shallow layer of extra abstraction that a curious reader has to look through.
> I guess I'll not object to this, if people really want to add it.
Setting macros that are reserved names is really unappea
@@ -35,7 +32,12 @@ struct _Unwind_LandingPadContext {
// Communication channel between compiler-generated user code and personality
// function
-thread_local struct _Unwind_LandingPadContext __wasm_lpad_context;
+#if __STDC_VERSION__ >= 202311L
ldionne wrote:
@@ -180,6 +180,7 @@
#endif
#define _LIBUNWIND_HIGHEST_DWARF_REGISTER
\
_LIBUNWIND_HIGHEST_DWARF_REGISTER_LOONGARCH
+#elif defined(__wasm__)
ldionne wrote:
Why don't we define `_LIBUNWIND_CURSOR_SIZE` and friends on wasm?
@@ -12,6 +12,7 @@
#include
#include "config.h"
+#ifndef __wasm__
ldionne wrote:
Similar question as above here. If this file is basically empty on wasm, we
should instead avoid adding it in the CMakeLists.txt.
https://github.com/llvm/llvm-project/pull/7966
@@ -10,14 +10,11 @@
//
//===--===//
+#if __STDC_VERSION__ < 202311L
ldionne wrote:
This change seems unrelated to the rest of the patch.
https://github.com/llvm/llvm-project/pull/79667
https://github.com/ldionne requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/79667
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -15,6 +15,7 @@
#include <__libunwind_config.h>
+#ifndef __wasm__
ldionne wrote:
What is the purpose of this header if it's entirely empty on wasm?
https://github.com/llvm/llvm-project/pull/79667
___
cfe-commits
@@ -36,7 +36,12 @@ struct __cxa_exception;
_LIBCPP_OVERRIDABLE_FUNC_VIS __cxa_exception* __cxa_init_primary_exception(
void*,
std::type_info*,
-void(
+# if defined(__USING_WASM_EXCEPTIONS__)
ldionne wrote:
Let's introduce a typedef name for this f
https://github.com/ldionne edited
https://github.com/llvm/llvm-project/pull/79667
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne milestoned
https://github.com/llvm/llvm-project/pull/73618
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fcxx-exceptions -verify %s
+
+#if !__has_builtin(__builtin_verbose_trap)
+#error
+#endif
+
+constexpr char const* constMsg1 = "hello";
+char const* const constMsg2 = "hello";
+char const constMsg3[] = "hello";
+
+templ
ldionne wrote:
@AaronBallman We're struggling a bit to find the right person to help review
this -- do you know who would be a good candidate? Hui is very familiar with
libc++ but he's less familiar with codegen, and I'm not very useful in that
area of the project :-).
https://github.com/llvm
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fcxx-exceptions -verify %s
+
+#if !__has_builtin(__builtin_verbose_trap)
+#error
+#endif
+
+constexpr char const* constMsg1 = "hello";
+char const* const constMsg2 = "hello";
+char const constMsg3[] = "hello";
+
+templ
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fcxx-exceptions -verify %s
+
+#if !__has_builtin(__builtin_verbose_trap)
+#error
+#endif
+
+constexpr char const* constMsg1 = "hello";
+char const* const constMsg2 = "hello";
+char const constMsg3[] = "hello";
+
+templ
ldionne wrote:
@DimitryAndric Thanks, please keep us in the loop. If we need to make a fix on
our side, @itrofimow we'll want to cherry-pick it to LLVM 18.
https://github.com/llvm/llvm-project/pull/65534
___
cfe-commits mailing list
cfe-commits@lists.
https://github.com/ldionne approved this pull request.
You'll want to wait for other reviewers to also be happy with this, but from my
side this is ready to go! Thanks!
https://github.com/llvm/llvm-project/pull/78763
___
cfe-commits mailing list
cfe-c
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fcxx-exceptions -verify %s
+
+#if !__has_builtin(__builtin_verbose_trap)
+#error
+#endif
+
+constexpr char const* constMsg1 = "hello";
+char const* const constMsg2 = "hello";
+char const constMsg3[] = "hello";
+
+templ
@@ -3379,6 +3379,54 @@ Query for this feature with
``__has_builtin(__builtin_debugtrap)``.
Query for this feature with ``__has_builtin(__builtin_trap)``.
+``__builtin_verbose_trap``
+--
+
+``__builtin_verbose_trap`` causes the program to stop its exec
@@ -851,6 +851,28 @@ static void InitializePredefinedMacros(const TargetInfo
&TI,
Twine(getClangFullCPPVersion()) + "\"");
// Initialize language-specific preprocessor defines.
+ if (LangOpts.getStdlibHardeningMode()) {
+const char *StdlibHardenin
https://github.com/ldionne updated
https://github.com/llvm/llvm-project/pull/77930
>From eabd2a9d6922dd82b59497b769bc0a160e69c811 Mon Sep 17 00:00:00 2001
From: Jeremy Morse
Date: Fri, 12 Jan 2024 11:06:50 +
Subject: [PATCH 1/3] [DebugInfo][RemoveDIs] Add a DPValue implementation for
instc
Author: Louis Dionne
Date: 2024-01-24T11:03:05-05:00
New Revision: fc364e26845ce5529caf9f88abcc5a5531d1f59f
URL:
https://github.com/llvm/llvm-project/commit/fc364e26845ce5529caf9f88abcc5a5531d1f59f
DIFF:
https://github.com/llvm/llvm-project/commit/fc364e26845ce5529caf9f88abcc5a5531d1f59f.diff
@@ -3220,8 +3220,8 @@ def TypeVisibility : InheritableAttr {
let Args = [EnumArgument<"Visibility", "VisibilityType",
["default", "hidden", "internal", "protected"],
["Default", "Hidden", "Hidden", "Protected"]>];
-// let
https://github.com/ldionne created
https://github.com/llvm/llvm-project/pull/79157
I was looking for the documentation of that attribute, and the best I could
find was a Stackoverflow answer or the commit message that originally
introduced the attribute. I figured I might as well document what
https://github.com/ldionne closed
https://github.com/llvm/llvm-project/pull/78869
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
201 - 300 of 824 matches
Mail list logo