On Thu, Apr 15, 2021 at 6:30 PM David Malcolm via Gcc wrote:
> On Thu, 2021-04-15 at 16:26 -0400, Chris Punches wrote:
> > What I see here in sum is another high level tightly integrated Red
> > Hat
> > employee saying the gist of "I'm really not saying it out of my
> > employer's interest and it
Dear Alfred and Alexandre,
It seems that neither of you would like to offer any evidence
that counteracts what I have already been given by multiple
individuals. Furthermore,
Alexandre:
> A misguided person thought that reciprocating the doxxing against RMS
> was a good way to defend him.
Dear Alexandre,
As stated here, shortly after I sent my message
(https://gcc.gnu.org/pipermail/gcc/2021-March/235197.html):
> Apologies, a correction here. I should have more carefully read
> it, but this paragraph:
>
> > My problem is Dr. Richard M. Stallman stands credibly and
> >
Dear Giacomo,
Apologies, a correction here. I should have more carefully read
it, but this paragraph:
> My problem is Dr. Richard M. Stallman stands credibly and
> factually accused of Doxxing and GCC contributor/participant and
> knowingly manipulating the project for his own personal
Dear Giacomo,
I want to reply specifically to you because you, like me, are a
new contributor, and I have a few questions and a few points that I
think are salient in this discussion.
> As an Italian I'm having a hard time trying to follow your reasoning
> about Stallman being a problem to
Dear GCC Community,
Hi. My name is JeanHeyd Meneide, my online moniker is "ThePhD"
(not an actual Doctor. Yet!). I spend a lot of my time hacking on C
and C++. Some of the things I've done include:
- Contributing (mostly) a Implementation [1]
- Doing a GSoC for GCC and writin
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
(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
> > >
> > >
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!
>
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
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
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/
?
Sincerely,
JeanHeyd Meneide
On Wed, Feb 12, 2020 at 11:55 PM David Malcolm wrote:
> On Thu, 2020-02-06 at 20:58 -0500, David Malcolm wrote:
> > On Mon, 2020-01-27 at 16:30 +0100, Martin Liška wrote:
> > > On 1/15/20 11:45 PM, Martin Jambor wrote:
> > > > Therefor
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
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
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
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
>
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
Dear Richard Biener,
On Wed, Dec 4, 2019 at 5:48 AM Richard Biener
wrote:
>
> On Sun, Dec 1, 2019 at 7:47 PM JeanHeyd Meneide
> wrote:
> >
> > ...
> > It worked, but this approach required removing some type checks
> > in digest_init just to be able to fak
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):
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
.
Sincerely Yours,
JeanHeyd Meneide
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
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
... 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
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/
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
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 tree.c
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
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
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
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
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 at 3
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
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
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,
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
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*
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
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
40 matches
Mail list logo
