Author: Louis Dionne
Date: 2021-07-26T16:38:05-04:00
New Revision: e95cd94f7edf50367d650410b8e534342eb0e5cb
URL:
https://github.com/llvm/llvm-project/commit/e95cd94f7edf50367d650410b8e534342eb0e5cb
DIFF:
https://github.com/llvm/llvm-project/commit/e95cd94f7edf50367d650410b8e534342eb0e5cb.diff
Author: Louis Dionne
Date: 2021-07-27T14:19:05-04:00
New Revision: 21c24ae9029a1fcd1c76b61b1c48b81b5c66c606
URL:
https://github.com/llvm/llvm-project/commit/21c24ae9029a1fcd1c76b61b1c48b81b5c66c606
DIFF:
https://github.com/llvm/llvm-project/commit/21c24ae9029a1fcd1c76b61b1c48b81b5c66c606.diff
Author: Louis Dionne
Date: 2022-03-22T12:35:47-04:00
New Revision: 80e66a05b6fad7d5f0ef71d5e0a74ce5ddc157a5
URL:
https://github.com/llvm/llvm-project/commit/80e66a05b6fad7d5f0ef71d5e0a74ce5ddc157a5
DIFF:
https://github.com/llvm/llvm-project/commit/80e66a05b6fad7d5f0ef71d5e0a74ce5ddc157a5.diff
Author: Louis Dionne
Date: 2022-02-09T08:55:31-05:00
New Revision: 6f17768e11480063f4c2bcbeea559505fee3ea19
URL:
https://github.com/llvm/llvm-project/commit/6f17768e11480063f4c2bcbeea559505fee3ea19
DIFF:
https://github.com/llvm/llvm-project/commit/6f17768e11480063f4c2bcbeea559505fee3ea19.diff
Author: Louis Dionne
Date: 2022-02-10T15:05:23-05:00
New Revision: 4ae83bb2b1e27628f6bd14d746aef964ed776d52
URL:
https://github.com/llvm/llvm-project/commit/4ae83bb2b1e27628f6bd14d746aef964ed776d52
DIFF:
https://github.com/llvm/llvm-project/commit/4ae83bb2b1e27628f6bd14d746aef964ed776d52.diff
Author: Louis Dionne
Date: 2022-02-10T15:05:23-05:00
New Revision: 4ae83bb2b1e27628f6bd14d746aef964ed776d52
URL:
https://github.com/llvm/llvm-project/commit/4ae83bb2b1e27628f6bd14d746aef964ed776d52
DIFF:
https://github.com/llvm/llvm-project/commit/4ae83bb2b1e27628f6bd14d746aef964ed776d52.diff
Author: Louis Dionne
Date: 2022-02-16T09:44:08-05:00
New Revision: 641a141da1f22de319e891bdfd61e614632b39f0
URL:
https://github.com/llvm/llvm-project/commit/641a141da1f22de319e891bdfd61e614632b39f0
DIFF:
https://github.com/llvm/llvm-project/commit/641a141da1f22de319e891bdfd61e614632b39f0.diff
Author: Louis Dionne
Date: 2022-07-19T10:44:19-04:00
New Revision: 7300a651f5f3b43f9fa3a2d9927322b0e061fcb2
URL:
https://github.com/llvm/llvm-project/commit/7300a651f5f3b43f9fa3a2d9927322b0e061fcb2
DIFF:
https://github.com/llvm/llvm-project/commit/7300a651f5f3b43f9fa3a2d9927322b0e061fcb2.diff
Author: Louis Dionne
Date: 2022-07-19T15:04:58-04:00
New Revision: ca495e36c1b4d4b8be47c9140647e6e934913cba
URL:
https://github.com/llvm/llvm-project/commit/ca495e36c1b4d4b8be47c9140647e6e934913cba
DIFF:
https://github.com/llvm/llvm-project/commit/ca495e36c1b4d4b8be47c9140647e6e934913cba.diff
Author: Louis Dionne
Date: 2022-07-20T09:14:55-04:00
New Revision: 7169659752557aa107e3efe470ba988155ae3bbd
URL:
https://github.com/llvm/llvm-project/commit/7169659752557aa107e3efe470ba988155ae3bbd
DIFF:
https://github.com/llvm/llvm-project/commit/7169659752557aa107e3efe470ba988155ae3bbd.diff
Author: Louis Dionne
Date: 2022-05-11T10:18:09-04:00
New Revision: c631e33f316d891b39c1e01217a7422fdc29ced1
URL:
https://github.com/llvm/llvm-project/commit/c631e33f316d891b39c1e01217a7422fdc29ced1
DIFF:
https://github.com/llvm/llvm-project/commit/c631e33f316d891b39c1e01217a7422fdc29ced1.diff
Author: Louis Dionne
Date: 2022-05-13T13:25:28-04:00
New Revision: 6716e2055ddeac304f47adc5ae39086381016ba7
URL:
https://github.com/llvm/llvm-project/commit/6716e2055ddeac304f47adc5ae39086381016ba7
DIFF:
https://github.com/llvm/llvm-project/commit/6716e2055ddeac304f47adc5ae39086381016ba7.diff
Author: Louis Dionne
Date: 2022-05-13T14:37:24-04:00
New Revision: 0a22dfcb11c05cbd4f654c8ef1868a4bc6085140
URL:
https://github.com/llvm/llvm-project/commit/0a22dfcb11c05cbd4f654c8ef1868a4bc6085140
DIFF:
https://github.com/llvm/llvm-project/commit/0a22dfcb11c05cbd4f654c8ef1868a4bc6085140.diff
Author: Louis Dionne
Date: 2022-05-19T10:58:13-04:00
New Revision: a5f36259a20533d9c970ab6a5faab7cf341ca1c9
URL:
https://github.com/llvm/llvm-project/commit/a5f36259a20533d9c970ab6a5faab7cf341ca1c9
DIFF:
https://github.com/llvm/llvm-project/commit/a5f36259a20533d9c970ab6a5faab7cf341ca1c9.diff
Author: Louis Dionne
Date: 2022-05-20T09:36:29-04:00
New Revision: 422ec524388b524f48d49fccd436105bb848f833
URL:
https://github.com/llvm/llvm-project/commit/422ec524388b524f48d49fccd436105bb848f833
DIFF:
https://github.com/llvm/llvm-project/commit/422ec524388b524f48d49fccd436105bb848f833.diff
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 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 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
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 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:
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
@@ -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.
@@ -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
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
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:
> > 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:
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:
> @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:
> 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
@@ -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
@@ -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
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
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
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 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
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
@@ -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 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
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
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 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:
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
_
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
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:
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
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:
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
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
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
@@ -851,6 +851,28 @@ static void InitializePredefinedMacros(const TargetInfo
&TI,
Twine(getClangFullCPPVersion()) + "\"");
// Initialize language-specific preprocessor defines.
+ if (LangOpts.getStdlibHardeningMode()) {
+const char *StdlibHardenin
@@ -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
@@ -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
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
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.
@@ -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
@@ -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
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
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
@@ -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
@@ -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
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
@@ -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
@@ -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
@@ -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?
@@ -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:
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
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
https://github.com/ldionne updated
https://github.com/llvm/llvm-project/pull/77692
>From 6b3fd86a9949458410895a2292db935665a2ab77 Mon Sep 17 00:00:00 2001
From: Louis Dionne
Date: Wed, 10 Jan 2024 15:23:47 -0500
Subject: [PATCH 1/3] [libc++] Deprecate the
_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR
https://github.com/ldionne closed
https://github.com/llvm/llvm-project/pull/77692
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne created
https://github.com/llvm/llvm-project/pull/78054
Commit fc1c478709e3 added includes of and to
UnwindCursor.hpp. The library previously built on platforms where these headers
are not provided. These headers should be included only in the case where they
are
ldionne wrote:
CC @ajordanr-google
By the way, I noticed that you checked the "hide my email address" Github
feature, which leads to your commits being authored as `Jordan R AW
<103465530+ajordanr-goo...@users.noreply.github.com>`. Please uncheck that, we
strive to make it easy to track who
ldionne wrote:
> @petrhosek @ldionne would it be better detect libunwind in
> LLVM_ENABLE_RUNTIMES?
I added a check in CMake here: https://github.com/llvm/llvm-project/pull/77991.
The error message should now be clearer than previously.
https://github.com/llvm/llvm-project/pull/77687
ldionne wrote:
That means that based on whether `LLVM_ENABLE_RUNTIMES=libunwind` happens to be
set or not, you'd use a fundamentally different unwinding library which implies
a different ABI. It's convenient, but isn't that too subtle?
https://github.com/llvm/llvm-project/pull/77687
__
https://github.com/ldionne approved this pull request.
https://github.com/llvm/llvm-project/pull/78230
___
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/78230
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ldionne wrote:
Ping. I don't know how to fix the issue, I need some help.
https://github.com/llvm/llvm-project/pull/75841
___
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/78054
___
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/66801
>From f056692eff4cc4ee9315a40a32ddd025be5d7e8d Mon Sep 17 00:00:00 2001
From: Louis Dionne
Date: Wed, 23 Aug 2023 22:23:17 -0400
Subject: [PATCH] [libc++] Re-enable the clang_modules_include test for
Objective-C
https://github.com/ldionne edited
https://github.com/llvm/llvm-project/pull/66801
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ldionne wrote:
Thanks folks! I rebased and I'm re-running the CI. I'll merge once it's green.
https://github.com/llvm/llvm-project/pull/66801
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co
https://github.com/ldionne updated
https://github.com/llvm/llvm-project/pull/66801
>From f056692eff4cc4ee9315a40a32ddd025be5d7e8d Mon Sep 17 00:00:00 2001
From: Louis Dionne
Date: Wed, 23 Aug 2023 22:23:17 -0400
Subject: [PATCH 1/2] [libc++] Re-enable the clang_modules_include test for
Objecti
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/7] [libc++] Fix the behavior of throwing `operator new`
under -f
@@ -211,10 +211,10 @@ if (NOT DEFINED LLVM_LINKER_DETECTED AND NOT WIN32)
)
if(APPLE)
-if("${stderr}" MATCHES "PROJECT:ld64")
+if("${stderr}" MATCHES "PROGRAM:ld")
ldionne wrote:
I'm not certain I understand -- isn't this patch missing something
@@ -211,10 +211,10 @@ if (NOT DEFINED LLVM_LINKER_DETECTED AND NOT WIN32)
)
if(APPLE)
-if("${stderr}" MATCHES "PROJECT:ld64")
+if("${stderr}" MATCHES "PROGRAM:ld")
ldionne wrote:
Ahhh, now this all makes sense! I hadn't noticed that you switched
https://github.com/ldionne approved this pull request.
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
https://github.com/ldionne edited
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
https://github.com/ldionne edited
https://github.com/llvm/llvm-project/pull/69498
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ldionne wrote:
The CI failures seem unrelated. I'll merge when the hidden e-mail address issue
has been resolved.
https://github.com/llvm/llvm-project/pull/77806
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
@@ -408,7 +409,15 @@ static void emitAtomicCmpXchg(CodeGenFunction &CGF,
AtomicExpr *E, bool IsWeak,
CGF.Builder.SetInsertPoint(StoreExpectedBB);
// Update the memory at Expected with Old's value.
- CGF.Builder.CreateStore(Old, Val1);
+
+ llvm::Type *ExpectedType = Expe
@@ -0,0 +1,556 @@
+// RUN: mkdir -p %t
ldionne wrote:
Are these files missing a license?
https://github.com/llvm/llvm-project/pull/75371
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cg
@@ -0,0 +1,556 @@
+// RUN: mkdir -p %t
+// RUN: %clang++ %s -o %t/run
+// RUN: %t/run
ldionne wrote:
I'm not sure if this is going to work on all configurations, for example when
they cross compile. Is there a precedent for these kinds of runtime tests in
the c
https://github.com/ldionne commented:
This is nice!
Tagging a few people who might have opinions on the naming: @nico @kubamracek
@AaronBallman
Also, @jwakely it would be nice if this worked with libstdc++ as well in the
future -- it would probably turn on checks like `__GLIBCXX_ASSERT__`. Do
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
@@ -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, S
@@ -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 used
201 - 300 of 937 matches
Mail list logo
