@@ -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
@@ -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
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:
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
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.
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
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
@@ -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:
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
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
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
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
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
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
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
@@ -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
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
}
}
-void Darwin::addClangTargetOptions(const llvm::opt::ArgList ,
- llvm::opt::ArgStringList ,
-
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
@@ -2912,16 +2912,70 @@ static bool sdkSupportsBuiltinModules(const
Darwin::DarwinPlatformKind
}
}
-void Darwin::addClangTargetOptions(const llvm::opt::ArgList ,
- llvm::opt::ArgStringList ,
-
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
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
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,
@@ -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,
@@ -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
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
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
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
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
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
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.
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
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
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
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
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
@@ -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
@@ -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.
@@ -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
___
@@ -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
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";
+
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 :-).
@@ -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";
+
@@ -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";
+
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
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
@@ -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";
+
@@ -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
@@ -851,6 +851,28 @@ static void InitializePredefinedMacros(const TargetInfo
,
Twine(getClangFullCPPVersion()) + "\"");
// Initialize language-specific preprocessor defines.
+ if (LangOpts.getStdlibHardeningMode()) {
+const char
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
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"]>];
-//
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
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
https://github.com/ldionne edited
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
https://github.com/ldionne updated
https://github.com/llvm/llvm-project/pull/69498
>From 6f89b118ed56ad7a3af1996e19ccd30cc893c51e Mon Sep 17 00:00:00 2001
From: Louis Dionne
Date: Wed, 14 Jun 2023 17:49:22 -0700
Subject: [PATCH 01/11] [libc++] Fix the behavior of throwing `operator new`
under
https://github.com/ldionne demilestoned
https://github.com/llvm/llvm-project/pull/77176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -360,11 +365,13 @@ _LIBCPP_HARDENING_MODE_DEBUG
#define _LIBCPP_ASSERT_VALID_ELEMENT_ACCESS(expression, message)
_LIBCPP_ASSERT(expression, message)
#define _LIBCPP_ASSERT_NON_NULL(expression, message)
_LIBCPP_ASSERT(expression, message)
#
@@ -52,204 +51,234 @@
class ComparisonResults {
ldionne wrote:
We need to take the parts of this test that would reproduce an OOB access
inside `std::sort` & friends to a new test file. And that one should be enabled
whenever the valid-element-access checks
@@ -53,10 +53,9 @@ struct __debug_less {
_LIBCPP_CONSTEXPR_SINCE_CXX14 inline _LIBCPP_HIDE_FROM_ABI void
__do_compare_assert(long, _LHS&, _RHS&) {}
};
-// Pass the comparator by lvalue reference. Or in debug mode, using a
-// debugging wrapper that stores a reference.
-#if
https://github.com/ldionne edited
https://github.com/llvm/llvm-project/pull/77405
___
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.
@philnik777
> Does this actually improve the performance anywhere? AFAICT all we gain is
> avoiding the messages being generated in the binary, but I'm not convinced
> that's much of a problem. e.g. in the `std::next` case, there doesn't
@@ -350,6 +363,9 @@ _LIBCPP_HARDENING_MODE_DEBUG
#define _LIBCPP_ASSERT_PEDANTIC(expression, message)
_LIBCPP_ASSUME(expression)
#define _LIBCPP_ASSERT_INTERNAL(expression, message)
_LIBCPP_ASSUME(expression)
#define
https://github.com/ldionne edited
https://github.com/llvm/llvm-project/pull/77176
___
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.
LGTM.
https://github.com/llvm/llvm-project/pull/77164
___
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/69498
>From 6f89b118ed56ad7a3af1996e19ccd30cc893c51e Mon Sep 17 00:00:00 2001
From: Louis Dionne
Date: Wed, 14 Jun 2023 17:49:22 -0700
Subject: [PATCH 1/8] [libc++] Fix the behavior of throwing `operator new`
under
Jan =?utf-8?q?Kokemüller?= ,
Jan =?utf-8?q?Kokemüller?= ,
Jan =?utf-8?q?Kokemüller?= ,
Jan =?utf-8?q?Kokemüller?= ,
Jan =?utf-8?q?Kokemüller?= ,
Jan =?utf-8?q?Kokemüller?= ,
Jan =?utf-8?q?Kokemüller?= ,
Jan =?utf-8?q?Kokemüller?= ,
Jan =?utf-8?q?Kokemüller?= ,
Jan =?utf-8?q?Kokemüller?= ,
Jan
https://github.com/ldionne approved this pull request.
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
https://github.com/ldionne closed
https://github.com/llvm/llvm-project/pull/77806
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -851,6 +851,33 @@ static void InitializePredefinedMacros(const TargetInfo
,
Twine(getClangFullCPPVersion()) + "\"");
// Initialize language-specific preprocessor defines.
+ if (LangOpts.getLibcxxHardeningMode()) {
+const char
@@ -275,6 +275,8 @@ def warn_drv_unknown_argument_clang_cl_with_suggestion :
Warning<
InGroup;
def err_drv_unknown_target_triple : Error<"unknown target triple '%0'">;
+def err_drv_stdlib_hardening_unavailable : Error<"libc++ hardening is
available only when libc++ is
@@ -281,6 +281,7 @@ LANGOPT(OffloadingNewDriver, 1, 0, "use the new driver for
generating offloading
LANGOPT(SYCLIsDevice , 1, 0, "Generate code for SYCL device")
LANGOPT(SYCLIsHost, 1, 0, "SYCL host compilation")
ENUM_LANGOPT(SYCLVersion , SYCLMajorVersion, 2,
https://github.com/ldionne edited
https://github.com/llvm/llvm-project/pull/78763
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 603 matches
Mail list logo
