Author: ldionne
Date: Tue Jul 31 19:08:59 2018
New Revision: 338475
URL: http://llvm.org/viewvc/llvm-project?rev=338475&view=rev
Log:
[libc++] Remove _LIBCPP_BUILDING_XXX macros, which are redundant since
_LIBCPP_BUILDING_LIBRARY
Summary: As suggested by Marshall in https://reviews.llvm.org/D499
Author: ldionne
Date: Tue Jul 31 19:08:59 2018
New Revision: 338475
URL: http://llvm.org/viewvc/llvm-project?rev=338475&view=rev
Log:
[libc++] Remove _LIBCPP_BUILDING_XXX macros, which are redundant since
_LIBCPP_BUILDING_LIBRARY
Summary: As suggested by Marshall in https://reviews.llvm.org/D499
Author: ldionne
Date: Wed Aug 1 06:13:14 2018
New Revision: 338531
URL: http://llvm.org/viewvc/llvm-project?rev=338531&view=rev
Log:
[libc++] Fix GCC 7.2.0 macro redefinition warning
The warning happens when LIBCXX_ENABLE_EXCEPTIONS cmake option is not set,
and it fires every time __config is in
Author: ldionne
Date: Fri Aug 3 15:36:53 2018
New Revision: 338933
URL: http://llvm.org/viewvc/llvm-project?rev=338933&view=rev
Log:
[NFC][libc++] Consistently use spaces to indent
rdar://problem/19988944
Modified:
libcxx/trunk/include/__tree
libcxx/trunk/include/any
libcxx/trunk/in
Author: ldionne
Date: Mon Aug 6 07:11:50 2018
New Revision: 339012
URL: http://llvm.org/viewvc/llvm-project?rev=339012&view=rev
Log:
[libc++] Add the _LIBCPP_HIDE_FROM_ABI_AFTER_V1 macro
Summary:
This macro allows hiding symbols from the ABI when the library is built
with an ABI version after AB
Author: ldionne
Date: Mon Aug 6 07:29:47 2018
New Revision: 339016
URL: http://llvm.org/viewvc/llvm-project?rev=339016&view=rev
Log:
[clang] Fix broken include_next in float.h
Summary:
The code defines __FLOAT_H and then includes the next , which is
guarded on __FLOAT_H so it gets skipped entire
Author: ldionne
Date: Fri Aug 10 06:24:56 2018
New Revision: 339431
URL: http://llvm.org/viewvc/llvm-project?rev=339431&view=rev
Log:
[libc++] Enable aligned allocation based on feature test macro, irrespective of
standard
Summary:
The current code enables aligned allocation functions when compi
Author: ldionne
Date: Tue Aug 14 06:29:17 2018
New Revision: 339675
URL: http://llvm.org/viewvc/llvm-project?rev=339675&view=rev
Log:
[libc++] Add missing #include in C11 features tests
Summary:
These #includes are quite important, since otherwise any
#if TEST_STD_VER > 14 && defined(TEST_HA
Author: ldionne
Date: Tue Aug 14 11:16:56 2018
New Revision: 339702
URL: http://llvm.org/viewvc/llvm-project?rev=339702&view=rev
Log:
[libc++] Fix incorrect definition of TEST_HAS_C11_FEATURES
Summary:
The macro was not defined in C++11 mode when it should have been, at least
according to how _LI
Author: ldionne
Date: Tue Aug 14 17:16:41 2018
New Revision: 339741
URL: http://llvm.org/viewvc/llvm-project?rev=339741&view=rev
Log:
[libc++] Detect C11 features on non-Clang compilers
Summary:
The macros were inside `#if defined(_LIBCPP_COMPILER_CLANG)`, which means
we would never detect C11 fe
Author: ldionne
Date: Tue Aug 14 17:18:01 2018
New Revision: 339742
URL: http://llvm.org/viewvc/llvm-project?rev=339742&view=rev
Log:
[libc++] Disable failing C11 feature tests for and
Summary:
Those tests are breaking the test bots. A Bugzilla has been filed to
make sure those tests are re-ena
Author: ldionne
Date: Tue Aug 14 17:30:03 2018
New Revision: 339743
URL: http://llvm.org/viewvc/llvm-project?rev=339743&view=rev
Log:
[libcxx] Fix XFAILs for aligned allocation tests on older OSX versions
Summary:
Since r338934, Clang emits an error when aligned allocation functions are
used in c
Author: ldionne
Date: Thu Oct 4 08:49:42 2018
New Revision: 343790
URL: http://llvm.org/viewvc/llvm-project?rev=343790&view=rev
Log:
[clang] Add the exclude_from_explicit_instantiation attribute
Summary:
This attribute allows excluding a member of a class template from being part
of an explicit
cks-win\llvm\tools\clang\lib\Sema\SemaExprCXX.cpp
> : fatal error C1128: number of sections exceeded object file format limit:
> compile with /bigobj
>
>
> Please have a look?
> The builder was already red and did not send notifications on this.
>
> Thanks
>
> Gali
Author: ldionne
Date: Wed Oct 10 08:32:29 2018
New Revision: 344146
URL: http://llvm.org/viewvc/llvm-project?rev=344146&view=rev
Log:
[clang] Properly apply attributes on explicit instantiations of static data
members
Summary: https://llvm.org/PR39118
Reviewers: aaron.ballman, rnk
Subscribers:
Author: ldionne
Date: Wed Oct 10 10:37:37 2018
New Revision: 344159
URL: http://llvm.org/viewvc/llvm-project?rev=344159&view=rev
Log:
[clang] Fix failing attribute test on Windows
The test added in r344146 was failing because the ABI on Windows is
different, and that test includes ABI-specific de
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:
> > 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 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
@@ -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 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
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 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
@@ -851,6 +851,33 @@ static void InitializePredefinedMacros(const TargetInfo
&TI,
Twine(getClangFullCPPVersion()) + "\"");
// Initialize language-specific preprocessor defines.
+ if (LangOpts.getLibcxxHardeningMode()) {
+const char *LibcxxHardenin
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
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
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 =?utf
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 -f
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 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
@@ -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 _LIBCPP_ASSERT_
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 s
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
@@ -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
@@ -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
@@ -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)
#de
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
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 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 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 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
@@ -3220,8 +3220,8 @@ def TypeVisibility : InheritableAttr {
let Args = [EnumArgument<"Visibility", "VisibilityType",
["default", "hidden", "internal", "protected"],
["Default", "Hidden", "Hidden", "Protected"]>];
-// let
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.
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
301 - 400 of 747 matches
Mail list logo
