On 1/29/25 12:27 PM, Jakub Jelinek wrote:
I'd like to ping 4 C++ patches:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662379.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662380.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662381.html
P2552R3 - On
On Tue, Jan 07, 2025 at 02:07:58PM +0100, Jakub Jelinek wrote:
> Stage1:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662379.html
> https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662380.html
> https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662381.html
> https://
On 9/1/21 4:11 PM, Jakub Jelinek wrote:
On Wed, Sep 01, 2021 at 03:25:17PM -0400, Jason Merrill wrote:
On 8/30/21 3:11 AM, Jakub Jelinek wrote:
Hi!
I'd like to ping the following patches
libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488]
https://gcc.gnu.org/pipermail/gcc-patches/2021-J
On Wed, Sep 01, 2021 at 03:25:17PM -0400, Jason Merrill wrote:
> On 8/30/21 3:11 AM, Jakub Jelinek wrote:
> > Hi!
> >
> > I'd like to ping the following patches
> >
> > libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488]
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html
>
On 8/30/21 3:11 AM, Jakub Jelinek wrote:
Hi!
I'd like to ping the following patches
libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488]
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html
together with your
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577602.html
incr
On 1/5/21 11:34 AM, Jakub Jelinek wrote:
Hi!
I'd like to ping the:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562099.html
patch.
OK, thanks.
Applied, thanks for your persistence.
On 5/31/19 3:06 PM, Harald van Dijk wrote:
another ping
On 12/05/2019 17:57, Harald van Dijk wrote:
ping again
On 26/04/2019 19:58, Harald van Dijk wrote:
ping
On 13/04/2019 10:01, Harald van Dijk wrote:
Hi,
For PR60531, GCC wrongly rejects function t
ping again
On 26/04/2019 19:58, Harald van Dijk wrote:
ping
On 13/04/2019 10:01, Harald van Dijk wrote:
Hi,
For PR60531, GCC wrongly rejects function templates with explicitly
specified template arguments as overloaded. They are resolved by
resolve_nondeduced_context, which is normally called
On 12/4/18 9:47 AM, Jakub Jelinek wrote:
Hi!
I'd like to ping
PR87506 - https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01758.html
You've acked the patch with the asserts but that FAILs as mentioned
in the above mail. The following has been bootstrapped/regtested
and works, can it be committe
On Mon, Sep 17, 2018 at 1:53 PM, Paolo Carlini wrote:
> Hi again,
>
> On 9/3/18 10:59 PM, Paolo Carlini wrote:
>>
>> in this error-recovery ICE, upon the error make_constrained_auto assigns
>> error_mark_node to PLACEHOLDER_TYPE_CONSTRAINTS (type) which then causes a
>> crash later when hash_place
On Fri, Jul 13, 2018 at 12:24:02PM -0400, Nathan Sidwell wrote:
> On 07/13/2018 09:49 AM, Jakub Jelinek wrote:
> > Hi!
> >
> > I'd like to ping the following C++ patches:
> >
> > - PR c++/85515
> >make range for temporaries unspellable during parsing and only
> >turn them into spellable f
On 07/13/2018 09:49 AM, Jakub Jelinek wrote:
- PR c++/3698, PR c++/86208
extern_decl_map & TREE_USED fix (plus 2 untested variants)
http://gcc.gnu.org/ml/gcc-patches/2018-07/msg00084.html
ok, thanks
--
Nathan Sidwell
On 07/13/2018 09:49 AM, Jakub Jelinek wrote:
Hi!
I'd like to ping the following C++ patches:
- PR c++/85515
make range for temporaries unspellable during parsing and only
turn them into spellable for debug info purposes
http://gcc.gnu.org/ml/gcc-patches/2018-07/msg00086.html
How har
Hi Jason,
On 13/12/2017 23:27, Jason Merrill wrote:
These two don't match:
+ When initializing a temporary to be bound to the first
+ parameter of a constructor where the parameter is of type
+/* Return true if current_function_decl is a constructor
+ and its first argument is a refer
On 12/12/2017 03:20 PM, Paolo Carlini wrote:
Hi,
On 15/11/2017 00:54, Mukesh Kapoor wrote:
Hi,
This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82235
For the following test case
struct Foo {
Foo() {}
explicit Foo(const Foo& aOther) {}
};
struct Bar {
Foo m[1];
};
void
On 09/15/2017 05:53 AM, Paolo Carlini wrote:
Hi,
gently pinging this.
On 16/06/2017 15:47, Paolo Carlini wrote:
Hi,
submitter and Manuel analyzed this a while ago and came to the
conclusion - which I think is still valid vs the current working draft
- that strictly speaking this kind of cod
On 12/15/2016 07:26 AM, Jakub Jelinek wrote:
I don't think so. complete_type (error_mark_node) returns error_mark_node,
and COMPLETE_TYPE_P (error_mark_node) is invalid (should fail TYPE_CHECK in
checking compiler).
I can write it as
inst = complete_type (inst);
if (inst == error_mark_node
On Thu, Dec 15, 2016 at 07:14:15AM -0500, Nathan Sidwell wrote:
> On 12/15/2016 03:34 AM, Jakub Jelinek wrote:
> > Hi!
> >
> > I'd like to ping the
> >
> > http://gcc.gnu.org/ml/gcc-patches/2016-12/msg00698.html
> > P0490R0 GB 20: decomposition declaration should commit to tuple
> > interpretati
On 12/15/2016 03:34 AM, Jakub Jelinek wrote:
Hi!
I'd like to ping the
http://gcc.gnu.org/ml/gcc-patches/2016-12/msg00698.html
P0490R0 GB 20: decomposition declaration should commit to tuple interpretation
early
+ if (inst == error_mark_node)
+return NULL_TREE;
This check is unneeded, b
OK.
Jason
On Mon, Jan 11, 2016 at 05:04:16PM -0500, Jason Merrill wrote:
> >You mean:
> >
> >--- gcc/cp/pt.c.jj 2016-01-05 16:46:02.891896607 +0100
> >+++ gcc/cp/pt.c 2016-01-11 21:33:09.065184178 +0100
> >@@ -12207,6 +12207,8 @@ tsubst_decl (tree t, tree args, tsubst_f
> > DECL_TEMPLATE_INSTA
On 01/11/2016 04:52 PM, Jakub Jelinek wrote:
On Mon, Jan 11, 2016 at 04:44:46PM -0500, Jason Merrill wrote:
On 01/11/2016 03:01 PM, Nathan Sidwell wrote:
On 01/09/16 02:41, Jakub Jelinek wrote:
Hi!
I'd like to ping the PR c++/66808, PR c++/69000
http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02
On Mon, Jan 11, 2016 at 04:44:46PM -0500, Jason Merrill wrote:
> On 01/11/2016 03:01 PM, Nathan Sidwell wrote:
> >On 01/09/16 02:41, Jakub Jelinek wrote:
> >>Hi!
> >>
> >>I'd like to ping the PR c++/66808, PR c++/69000
> >>http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html
> >>patch, fixing IC
On 01/11/2016 03:01 PM, Nathan Sidwell wrote:
On 01/09/16 02:41, Jakub Jelinek wrote:
Hi!
I'd like to ping the PR c++/66808, PR c++/69000
http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html
patch, fixing ICE with GNU __thread vars in templates.
Can't you unconditionally clear DECL_TEMPLAT
On 01/09/16 02:41, Jakub Jelinek wrote:
Hi!
I'd like to ping the PR c++/66808, PR c++/69000
http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html
patch, fixing ICE with GNU __thread vars in templates.
Can't you unconditionally clear DECL_TEMPLATE_INFO regardless of local_p?
if (DECL_LANG_SP
Hi,
On 09/30/2014 04:51 PM, Manuel López-Ibáñez wrote:
I don't want to cause you more work Paolo, but perhaps this should be
documented in https://gcc.gnu.org/gcc-5/changes.html. ?
Something like:
* Excessive template instantiation depth is now a fatal error. This
prevents excessive diagnostic
I don't want to cause you more work Paolo, but perhaps this should be
documented in https://gcc.gnu.org/gcc-5/changes.html. ?
Something like:
* Excessive template instantiation depth is now a fatal error. This
prevents excessive diagnostics that usually do not help to identify
the problem.
Thank
OK.
Jason
... forgot to attach the complete patch ;)
Paolo.
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 215710)
+++ cp/cp-tree.h(working copy)
@@ -5418,7 +5418,6 @@ extern const char *lang_decl_n
29 matches
Mail list logo
