Dear Jonathan,
Done! re-patched, below.
Best,
JeanHeyd
2019-12-03 JeanHeyd "ThePhD" Meneide
* include/bits/c++config: Add new _GLIBCXX20_DEPRECATED macro.
* include/std/type_traits: Deprecate is_pod with message.
* testuite/20_util/is_pod/deprecated-2a.cc (new): t
This patch implements std::source_location. There's a couple
cases where the builtin implemented does not do what is expected of
it, and so the bottom 3 batches of test cases fails. I'm still
including the patch so that others can pick up on what might need to
change about the __builtin_source
On Fri, Dec 27, 2019 at 2:33 PM Jakub Jelinek wrote:
>
> This will be ABI incompatible between GCC and Clang, that doesn't look like
> a good idea to me. I thought the plan is to use what you have in the
> _GLIBCXX_HAVE_BUILTIN_SOURCE_LOCATION case always, except that if
> __builtin_source_locati
On Thu, Jan 2, 2020 at 5:28 AM Jonathan Wakely wrote:
>
> Do nothing - compiling with Clang won't define std::source_location at
> all.
You got it! Patch re-done after discussion here
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93093) and recommended
no-Clang change.
2020-01-02 JeanHeyd "TheP
Glen Fernandes is already working on a patch, so I decided to finish
off my changes and throw them up on the Patch List so that Glen can
access the tests parts that I had written (they are not incredibly
extensive but do pass).
For a small implementation description: the code I use does the
sa
On Thu, Jan 2, 2020 at 5:07 PM Jakub Jelinek wrote:
>
> On Thu, Jan 02, 2020 at 04:57:01PM -0500, JeanHeyd Meneide wrote:
> > +#if defined(_GLIBCXX_HAVE_BUILTIN_SOURCE_LOCATION)
> > +# define __cpp_lib_source_location 201907L
> > +#elif defined(_GLIBCXX_HAVE_BUILT
Attached is a patch for p1301 that improves in the way Jason Merrill
specified earlier
(https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00858.html), but it
keeps segfaulting on my build of GCC. I don't know what changes I've
made that cause it to segfault: it does so whenever the error()
function is
I am also not very smart, wherein I attach patches that do not have the tests.
Sorry!
diff --git a/gcc/c-family/c-lex.c b/gcc/c-family/c-lex.c
index e3c602fbb8d..fb05b5f8af0 100644
--- a/gcc/c-family/c-lex.c
+++ b/gcc/c-family/c-lex.c
@@ -353,13 +353,14 @@ c_common_has_attribute (cpp_reader *pfile
Sincerely,
JeanHeyd
On Wed, Oct 16, 2019 at 8:51 AM David Malcolm wrote:
>
> On Tue, 2019-10-15 at 20:31 -0400, JeanHeyd Meneide wrote:
> > Attached is a patch for p1301 that improves in the way Jason Merrill
> > specified earlier
> > (https://gcc.gnu.org/ml/gcc-patches/2019-0
Thanks, Jason! I fixed those last things and I put the changelog below
in the e-mail. I'll figure out how to write a good changelog in a
commit message on the command line soon. :D
2019-10-16 JeanHeyd Meneide
gcc/
* escaped_string.h: New. Refactored out of t
2019-10-17 JeanHeyd Meneide
gcc/
* escaped_string.h (escaped_string): New header.
* tree.c (escaped_string): Remove escaped_string class.
gcc/c-family
* c-lex.c (c_common_has_attribute): Update attribute value.
gcc/cp/
* tree.c (handle_nodiscard_attribute
bit of a better warning to
cover gen-attrs-67, and bumped the feature test macro value checks in
the feat tests. The rest should be fine now too.
Let me know if anything else seems off!
Best Wishes,
JeanHeyd Meneide
=======
2019-10-17 JeanHeyd Meneide
gcc/
... And I am very tired and forgot to attach the patch. Again. Sorry...!
On Fri, Oct 18, 2019 at 1:54 AM JeanHeyd Meneide
wrote:
>
> Dear Jason,
>
> On Thu, Oct 17, 2019 at 3:51 PM Jason Merrill wrote:
> > > FAIL: g++.dg/cpp0x/gen-attrs-67.C -std=c++11 (test for errors
This is an attempt to use concepts and constraints rather than
ranges::. It builds and run the tests I ran on x86_64 Linux decently
(albeit I'm still new at doing this). I wanted to get a feel for
whether or not this had been done right:
Thoughts?
diff --git a/libstdc++-v3/include/Makefile.am b/li
Thank you for the review!
- I moved the concepts back into the class and changed them to
template aliases because class local concepts aren't a thing that
works.
+ They are not inline constexpr bools because that ICE's GCC
pretty hard, as you explained to me earlier, so we use ::value in some
This patch implements deprecate POD for the C++ Standard Library,
bringing libstdc++ that much closer to 2020 conformance 🎉!
Hilariously, a small bug in the [[deprecated]] warning message was
found while implementing this patch, which drove me a bit insane for a
good 10 minutes until I realized wh
I think I got the tabs right...? You would not believe how unbelievably
hard it is, just to mail a diff!
-
07-24-2019ThePhD
gcc/
* escaped_string.h: New. Refactored out of tree.c to make more
broadly available (e.g. to parser.c, cvt.c).
* tree.c: remove escaped_string class
gcc/c-
The HTML formatting was off (again), so I used git send-email as someone
recommended to me in the IRC. Patch is here:
https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01670.html
I... think it's good, there? Apologies for all the noise; it's a bit hard
getting used to these tools.
Sincerely,
JeanHeyd
This patch implements as it currently exists in the C++20 Working Draft.
Notes:
- __gnu_cxx::__normal_iterator is not fully constexpr, so its not used here
- P1394 might be slated to end up in C++20 per National Body Comments.
Therefore, an early implementation is left in an
implementation-define
On Fri, Aug 30, 2019 at 3:41 PM Jonathan Wakely wrote:
>
> On 30/08/19 15:22 -0400, JeanHeyd Meneide wrote:
> >This patch implements as it currently exists in the C++20 Working
> >Draft.
>
> Nice!
>
>
> >Notes:
> >- __gnu_cxx::__normal_iterator is
Ahem -- we were supposed to use the 20 version of the constexpr macro,
not the base one.
I will note that, for some reason, the default constructor was already
constexpr, so we don't change that one!
On Fri, Aug 30, 2019 at 5:11 PM JeanHeyd Meneide
wrote:
>
> On Fri, Aug 30, 2019
Thank you for the thorough review!
On Tue, Sep 3, 2019 at 9:31 AM Jonathan Wakely wrote:
> It looks like__adl_begin and __adl_end should be guarded by #ifdef
> _GLIBCXX_P1394 because they're not needed otherwise.
I'm absolutely going to need it for the bit data structures (and
in tunin
Dear GCC Community,
This patch implements the recently accepted p1301: [[nodiscard("should
have a reason")]]. Aaron Ballman implemented it for Clang in
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190715/280158.html
-- this is in preparation for a paper that will soon go to the C
I think I managed to fix all of the issues. Do let me know if I missed
anything!
--
diff --git a/.gitignore b/.gitignore
index b53f60db792..8988746a314 100644
--- a/.gitignore
+++ b/.gitignore
@@ -55,3 +55,6 @@ REVISION
/mpc*
/gmp*
/isl*
+
+# ignore some editor-specific files
+.vscod
Oops. I learned that %< and %> do not get applied as part of the string
arguments, only the initial format string. So, updated patch:
-
diff --git a/.gitignore b/.gitignore
index b53f60db792..8988746a314 100644
--- a/.gitignore
+++ b/.gitignore
@@ -55,3 +55,6 @@ REVISION
/mpc*
/gmp*
On Thu, Mar 13, 2025 Qing Zhao wrote:
> ...
>
> Is N3188 the following:
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3188.htm
>
> What’s the status of this proposal?
N3188 was discussed during the January 2024 Meeting in Strasbourg,
France. There was "along the lines" (opinion poll)
On Thu, Mar 13, 2025 Martin Uecker wrote:
> ...
>
> So it seems to be a possible way forward while avoiding
> language divergence and without introducing anything too novel
> in either language.
>
> (But others still have concerns about .n and prefer __self__.)
I would like to gently push
Dear GCC,
This patch adds macros to the general preprocessor that allow
users to understand what the execution and wide execution charsets
are, which are used for "bark" and L"meow" literals in C-family
languages.
The goal of this is to enable individuals in capable languages
like C and
Dear Joseph,
On Thu, Oct 8, 2020 at 1:36 PM Joseph Myers wrote:
>
> This documentation doesn't seem sufficient to use the macros. Do they
> expand to (narrow) string literals? To an unquoted sequence of
> characters? I think from the implementation that the answer is strings
> (so, in particul
Hello,
> Typo: comple-time
>
> >2020-10-08 JeanHeyd "ThePhD" Meneide
> >
> >* gcc/c-family/c-cppbuiltin.c: Add predefined macro
> >definitions for charsets
>
> I think you should put the macro names in braces after the filename and drop
> the trailing "for charsets".
Can do!
>
On Sat, Aug 22, 2020 at 8:14 AM Jonathan Wakely via Gcc-patches
wrote:
> I really wish WG14 would just fix the intmax_t mess so we can make
> them integral types unconditionally.
We're trying, but we're struggling to reach a good consensus. Almost
nobody's fully agreeing on one /particular/ solut
Dear Jeff,
On Mon, Nov 23, 2020 at 3:02 PM Jeff Law wrote:
>
> You use a getter function to retrieve the value of ret.to, which is
> fine. Is there a specific reason why you're not using a setter function
> to save the value?
I did this because I have access to ret.to in the libcpp
functio
(Very very gentle ping, just to make sure it's still on anyone's radar...!)
On Fri, Oct 9, 2020 at 8:39 AM JeanHeyd Meneide wrote:
>
> Hello,
>
> > Typo: comple-time
> >
> > >2020-10-08 JeanHeyd "ThePhD" Meneide
> > >
>
33 matches
Mail list logo
