On 9/28/23 05:55, Richard Sandiford wrote:
poly_int was written before the switch to C++11 and so couldn't
use explicit default constructors. This led to an awkward split
between poly_int_pod and poly_int. poly_int simply inherited from
poly_int_pod and added constructors, with the argumentless
This revision changes from using DK_PEDWARN for permerror-with-option to using
DK_PERMERROR.
Tested x86_64-pc-linux-gnu. OK for trunk?
-- 8< --
In the discussion of promoting some pedwarns to be errors by default, rather
than move them all into -fpermissive it seems to me to make sense to suppo
On 10/3/23 12:48, David Malcolm wrote:
As mentioned in my Cauldron talk, this patch adds a call to
diagnostic_show_locus to the "required from here" messages
in print_instantiation_partial_context_line, so that e.g., rather
than the rather mystifying:
In file included from ../x86_64-pc-linux-gnu
On 10/3/23 08:41, Patrick Palka wrote:
On Mon, 2 Oct 2023, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
The relationship between tsubst_copy_and_build and tsubst_copy (two of
the main template argument substitution routines for
On 10/4/23 03:07, Florian Weimer wrote:
* Jason Merrill:
@@ -6159,6 +6153,18 @@ errors by @option{-pedantic-errors}. For instance:
-Wwrite-strings @r{(C++11 or later)}
}
+@opindex fpermissive
+@item -fpermissive
+Downgrade some required diagnostics about nonconformant code from
On 10/3/23 10:45, Jonathan Wakely wrote:
We have a long history of INVALID bugs about std functions being
available in the global namespace (PRs 27846, 67566, 82619, 99865,
110602, 111553, probably others). Let's document it.
Also de-prioritize the C++98-only bugs, which are unlikely to affect
a
On 10/9/23 06:03, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu with
GXX_TESTSUITE_STDS=98,11,14,17,20,23,26,impcx.
-- >8 --
This patch improves the errors given when casting from void* in C++26 to
include the expected type if the type of the pointed-to object was
not
On 10/8/23 21:03, Nathaniel Shead wrote:
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631203.html
+ && (TREE_CODE (t) == MODIFY_EXPR
+ /* Also check if initializations have implicit change of active
+member earlier up the access chain. */
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This becomes be more important with concepts, but can also be seen with
generic lambdas.
PR c++/109422
gcc/cp/ChangeLog:
* mangle.cc (write_template_param): Also mangle level.
gcc/testsuite/ChangeLog:
* g++.dg/cp
On 10/12/23 04:53, Nathaniel Shead wrote:
On Wed, Oct 11, 2023 at 12:48:12AM +1100, Nathaniel Shead wrote:
On Mon, Oct 09, 2023 at 04:46:46PM -0400, Jason Merrill wrote:
On 10/8/23 21:03, Nathaniel Shead wrote:
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631203.html
On 10/12/23 17:04, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
My recent patch introducing cp_fold_immediate_r caused exponential
compile time with nested COND_EXPRs. The problem is that the COND_EXPR
case recursively walks the arms of a COND_EXPR,
On 10/10/23 13:20, Marek Polacek wrote:
Thanks for looking into this. It's kept me occupied for quite a while.
Thanks, nice work.
On Tue, Aug 29, 2023 at 03:26:46PM -0400, Jason Merrill wrote:
On 8/23/23 15:49, Marek Polacek wrote:
+struct A {
+ int x;
+ int y = id(x);
+};
+
+tem
On 10/13/23 14:53, Marek Polacek wrote:
On Thu, Oct 12, 2023 at 09:41:43PM -0400, Jason Merrill wrote:
On 10/12/23 17:04, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
My recent patch introducing cp_fold_immediate_r caused exponential
compile t
On 10/13/23 18:15, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
In C++23, since P2448, a constexpr function F that calls a non-constexpr
function N is OK as long as we don't actually call F in a constexpr
context. So instead of giving an erro
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
I want to distinguish between constraint && and fold-expressions there of
written by the user and those implied by template parameter
type-constraints; to that end, let's improve our EXPR_LOCATION for an
explicit fold-expression.
The fold3.
Ping?
On 10/3/23 17:09, Jason Merrill wrote:
This revision changes from using DK_PEDWARN for permerror-with-option to using
DK_PERMERROR.
Tested x86_64-pc-linux-gnu. OK for trunk?
-- 8< --
In the discussion of promoting some pedwarns to be errors by default, rather
than move them all i
On 10/17/23 12:34, Marek Polacek wrote:
On Tue, Oct 17, 2023 at 09:35:21PM +1100, Nathaniel Shead wrote:
Marek pointed out in another patch of mine [1] that I was missing an
auto_diagnostic_group to correctly associate informative notes with
their errors in structured error outputs. This patch g
On 10/16/23 20:39, Marek Polacek wrote:
On Sat, Oct 14, 2023 at 01:13:22AM -0400, Jason Merrill wrote:
On 10/13/23 14:53, Marek Polacek wrote:
On Thu, Oct 12, 2023 at 09:41:43PM -0400, Jason Merrill wrote:
On 10/12/23 17:04, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu
On 9/25/23 21:56, waffl3x wrote:
Also, just a quick update on my copyright assignment, I have sent an
e-mail to the FSF and haven't gotten a response yet. From what I was
reading, I am confident that it's my preferred option going forward
though. Hopefully they get back to me soon.
Any progres
On 9/25/23 21:56, waffl3x wrote:
On the plus side, I took my time to figure out how to best to pass down
information about whether a param is an xobj param. My initial
impression on what you were suggesting was to push another node on the
front of the list, but I stared at it for a few hours and
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Most of this is introducing the abi_check function to reduce the verbosity
of most places that check -fabi-version.
The start_mangling change is to avoid needing to zero-initialize additional
members of the mangling globals, though I'm not
On 10/17/23 17:38, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
r6-2367 added a DECL_INITIAL check to cp_parser_simple_declaration
so that we don't emit multiple errors in g++.dg/parse/error57.C.
But that means we don't diagnose
int f1() =
On 10/18/23 07:46, waffl3x wrote:
Any progress on this, or do I need to coax the process along? :)
Yeah, I've been working on it since the copyright assignment process
has finished, originally I was going to note that on my next update
which I had hoped to finish today or tomorrow. Well, in tr
On 10/18/23 13:28, waffl3x wrote:
I will try to get something done today, but I was struggling with
writing some of the tests, there's also a lot more of them now. I also
wrote a bunch of musings in comments that I would like feedback on.
My most concrete question is, how exactly should I be tes
On 10/19/23 09:39, Patrick Palka wrote:
On Tue, 17 Oct 2023, Marek Polacek wrote:
On Tue, Oct 17, 2023 at 04:49:52PM -0400, Jason Merrill wrote:
On 10/16/23 20:39, Marek Polacek wrote:
On Sat, Oct 14, 2023 at 01:13:22AM -0400, Jason Merrill wrote:
On 10/13/23 14:53, Marek Polacek wrote:
On
On 10/12/23 14:49, Patrick Palka wrote:
On Tue, 26 Sep 2023, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
This follow-up patch removes some more repetition of the type-dependent
On second thought there's no good reason to spli
A recent question led me to look at this file again, and it occurred to me that
it could use to offer more guidance. OK for trunk?
-- 8< --
gcc/ChangeLog:
* ABOUT-GCC-NLS: Add usage guidance.
---
gcc/ABOUT-GCC-NLS | 13 +
1 file changed, 13 insertions(+)
diff --git a/gcc/A
Tested with make po/gcc.pot to see that the strings are still there (though in
a different place, now with the gcc-internal-format tag).
Applying to trunk.
-- 8< --
Since these strings are passed to error_at, they should be marked for
translation with G_, like other diagnostic messages, rather t
OK for trunk?
-- 8< --
While checking another change, I noticed that the new permerror overloads
break gettext with "permerror used incompatibly as both
--keyword=permerror:2 --flag=permerror:2:gcc-internal-format and
--keyword=permerror:3 --flag=permerror:3:gcc-internal-format". So let's
chan
OK.
On Mon, Jul 2, 2018 at 6:58 AM, Paolo Carlini wrote:
> Hi,
>
> I was double checking my pending patch and going through the errors we emit
> in decl.c and elsewhere about thread_local and __thread and noticed another
> place, in parser.c, where using rich_location::add_range seems natural.
>
OK.
On Tue, Jul 3, 2018 at 10:14 AM, Marek Polacek wrote:
> This patch merely adds a test for an already fixed issue.
>
> Tested on x86_64-linux, ok for trunk?
>
> 2018-07-03 Marek Polacek
>
> PR c++/84306
> * g++.dg/overload/conv-op3.C: New test.
>
> diff --git gcc/testsuite/g
This was a simple typo in strip_typedefs_expr, where we were iterating
but then building a new list consisting entirely of the first element.
Tested x86_64-pc-linux-gnu, applying to trunk, 8, 7.
commit 1cab1ce37320aac67d8fbf88d10930f5c769cfb1
Author: Jason Merrill
Date: Mon Jul 2 15:09:58 2018
OK.
On Tue, Jul 3, 2018 at 12:08 PM, Marek Polacek wrote:
> This is an ICE of kind "Error reporting routines re-entered". From the PR:
>
> The problem here is that we report the missing return value:
> 9224 permerror (input_location, "return-statement with no value, in "
> 9225
On Thu, Jun 28, 2018 at 5:39 AM, Paolo Carlini wrote:
> Hi,
>
> On 28/06/2018 03:22, David Malcolm wrote:
>>
>> [snip]
>>>
>>> If I'm following you right, the idea is that gcc should complain
>>> because two different things in the user's source code contradict
>>> each
>>> other.
>>>
>>> In such
On Fri, Jun 29, 2018 at 3:58 PM, Marek Polacek wrote:
> On Wed, Jun 27, 2018 at 07:35:15PM -0400, Jason Merrill wrote:
>> On Wed, Jun 27, 2018 at 12:53 PM, Marek Polacek wrote:
>> > This PR complains about us accepting invalid code like
>> >
>> >
On Tue, Jul 3, 2018 at 2:58 PM, Marek Polacek wrote:
> On Tue, Jul 03, 2018 at 12:40:51PM -0400, Jason Merrill wrote:
>> On Fri, Jun 29, 2018 at 3:58 PM, Marek Polacek wrote:
>> > On Wed, Jun 27, 2018 at 07:35:15PM -0400, Jason Merrill wrote:
>> >> On Wed, Jun 27, 2
On Tue, Jul 3, 2018 at 3:41 PM, Jason Merrill wrote:
> On Tue, Jul 3, 2018 at 2:58 PM, Marek Polacek wrote:
>> On Tue, Jul 03, 2018 at 12:40:51PM -0400, Jason Merrill wrote:
>>> On Fri, Jun 29, 2018 at 3:58 PM, Marek Polacek wrote:
>>> > On Wed, Jun 27, 2018 at 0
OK.
On Tue, Jul 3, 2018 at 2:37 PM, Paolo Carlini wrote:
> Hi,
>
> On 03/07/2018 18:36, Jason Merrill wrote:
>>
>>
>>> if ((type_quals & TYPE_QUAL_VOLATILE)
>>> - && (loc == UNKNOWN_LOCATION || locations[ds_volat
On Tue, Jul 3, 2018 at 4:35 PM, Marek Polacek wrote:
> On Tue, Jul 03, 2018 at 03:41:43PM -0400, Jason Merrill wrote:
>> On Tue, Jul 3, 2018 at 2:58 PM, Marek Polacek wrote:
>> > On Tue, Jul 03, 2018 at 12:40:51PM -0400, Jason Merrill wrote:
>> >> On Fri, Jun 29,
Ok.
On Wed, Jul 4, 2018, 11:52 AM Ville Voutilainen
wrote:
> This has been buggy for a while, but since we were implementing
> the library triviality traits in terms of just the intrinsic since GCC 8,
> not too many users ran into it. The bug has been worked around
> in the library, but I'd rath
Did you consider handling this in check_local_shadow?
On Fri, Jul 6, 2018 at 7:50 PM, Ville Voutilainen
wrote:
> Tested on Linux-PPC64. Ok for trunk, perhaps with the change
> that I move the test under cpp1y, since it's a c++14 test anyway?
>
> I considered pushing the captures into the paramete
OK.
On Fri, Jul 6, 2018 at 8:14 PM, Richard Biener wrote:
>
> The following fixes
>
> FAIL: gcc.dg/guality/pr48437.c -O2 -flto -fno-use-linker-plugin
> -flto-partition=none line 14 i == 0
>
> because we now prune non-local/VAR_DECLs from BLOCK trees during
> free-lang-data (after we emitted ea
On Fri, Jul 6, 2018 at 5:20 PM, Andreas Krebbel wrote:
> On 06/20/2018 01:41 PM, Andreas Krebbel wrote:
>> When turning a user-defined numerical literal into an operator
>> invocation the literal needs to be translated to the execution
>> character set.
>>
>> Bootstrapped and regtested on s390x. x
Ok.
On Mon, Jul 9, 2018, 6:42 AM Paolo Carlini wrote:
> Hi,
>
> noticed three additional error messages where an additional range seems
> appropriate. Tested x86_64-linux.
>
> Thanks, Paolo.
>
> //
>
>
tcase revealed another bug, whereby
collecting the bindings for captured variables wasn't respecting
unevaluated context.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit c63bbedf903c28225d9cc273c14d3023e6074fa5
Author: Jason Merrill
Date: Fri Jul 13 23:22:26 2018 +1000
PR
On Wed, Jul 18, 2018 at 4:57 AM, Jakub Jelinek wrote:
> The standard says:
> "In the decl-specifier-seq of the lambda-declarator, each decl-specifier shall
> either be mutable or constexpr."
> and the C++ FE has CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR flag for that.
> But as implemented, it is a
OK. And I think this qualifies as obvious; you don't need to wait for
approval on further patches like this.
Jason
On Tue, Jul 17, 2018 at 10:17 PM, Paolo Carlini
wrote:
> Hi again,
>
> here I noticed a pair of consecutive permerrors (instead of permerror +
> inform) and also that the first one
OK.
On Fri, Jul 13, 2018 at 11:43 PM, Marek Polacek wrote:
> Ping.
>
> On Tue, Jul 03, 2018 at 09:35:24AM -0400, Marek Polacek wrote:
>> This PR complains about bogus -Wsign-conversion warning even with an
>> explicit static_cast. It started with this hunk from the delayed folding
>> merge:
>>
>
OK.
On Thu, Jul 12, 2018 at 7:52 PM, Paolo Carlini wrote:
> Hi,
>
> the below resolves the bug report and its duplicates by implementing - in a
> rather straightforward way, I believe - the resolution of DR 136, which also
> made into C++17. Note that in the patch I used permerror instead of a pl
OK.
On Wed, Jul 18, 2018 at 6:20 PM, Jakub Jelinek wrote:
> On Wed, Jul 18, 2018 at 11:34:30AM +1000, Jason Merrill wrote:
>> On Wed, Jul 18, 2018 at 4:57 AM, Jakub Jelinek wrote:
>> > The standard says:
>> > "In the decl-specifier-seq of the lambda-declarator,
OK.
On Sat, Jul 28, 2018 at 8:02 AM, David Malcolm wrote:
> This makes it easier to compare cp_printer with gcc_cxxdiag_char_table
> in c-format.c.
>
> No functional change intended.
>
> gcc/cp/ChangeLog:
> * error.c (cp_printer): In the leading comment, move "%H" and "I"
> into a
OK.
On Tue, Jul 31, 2018 at 7:22 PM, Richard Biener wrote:
> On Mon, 30 Jul 2018, Tom de Vries wrote:
>
>> Hi,
>>
>> Consider test.C compiled at -O0 -g:
>> ...
>> class string {
>> public:
>> string (const char *p) { this->p = p ; }
>> string (const string &s) { this->p = s.p; }
>>
>> private
On Tue, Jul 31, 2018 at 9:51 AM, Martin Sebor wrote:
> The middle-end contains code to determine the lengths of constant
> character arrays initialized by string literals. The code is used
> in a number of optimizations and warnings.
>
> However, the code is unable to deal with constant arrays in
On Mon, Jul 30, 2018 at 9:01 PM, Jakub Jelinek wrote:
> Seems what is considered an aggregate type keeps changing in every single
> C++ version.
Indeed :/
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
This is OK. I think we could also use a -Wc++2a-compat warning, and
On Mon, Jul 23, 2018 at 8:50 PM, Richard Biener
wrote:
> On Mon, Jul 23, 2018 at 12:28 PM Jakub Jelinek wrote:
>>
>> On Mon, Jul 23, 2018 at 12:17:42PM +0200, Richard Biener wrote:
>> > > Bootstrapped/regtested on x86_64-linux.
>> >
>> > Thanks for working on this. I wonder if we can completely
On 10/19/23 11:21, Jakub Jelinek wrote:
On Thu, Oct 19, 2023 at 11:11:30AM -0400, Jason Merrill wrote:
A recent question led me to look at this file again, and it occurred to me that
it could use to offer more guidance. OK for trunk?
-- 8< --
gcc/ChangeLog:
* ABOUT-GCC-NLS:
On 10/19/23 10:14, Marek Polacek wrote:
On Thu, Oct 19, 2023 at 10:06:01AM -0400, Jason Merrill wrote:
On 10/19/23 09:39, Patrick Palka wrote:
On Tue, 17 Oct 2023, Marek Polacek wrote:
On Tue, Oct 17, 2023 at 04:49:52PM -0400, Jason Merrill wrote:
On 10/16/23 20:39, Marek Polacek wrote:
On
On 10/19/23 12:55, Marek Polacek wrote:
On Thu, Oct 19, 2023 at 12:32:49PM -0400, Jason Merrill wrote:
On 10/19/23 10:14, Marek Polacek wrote:
On Thu, Oct 19, 2023 at 10:06:01AM -0400, Jason Merrill wrote:
On 10/19/23 09:39, Patrick Palka wrote:
On Tue, 17 Oct 2023, Marek Polacek wrote:
On
On 10/19/23 14:45, Marek Polacek wrote:
On Thu, Oct 19, 2023 at 01:02:33PM -0400, Jason Merrill wrote:
On 10/19/23 12:55, Marek Polacek wrote:
On Thu, Oct 19, 2023 at 12:32:49PM -0400, Jason Merrill wrote:
On 10/19/23 10:14, Marek Polacek wrote:
On Thu, Oct 19, 2023 at 10:06:01AM -0400
On 10/4/23 12:08, Patrick Palka wrote:
On Tue, 3 Oct 2023, Jason Merrill wrote:
On 10/3/23 08:41, Patrick Palka wrote:
On Mon, 2 Oct 2023, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
The relationship betw
On 10/4/23 15:23, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
After the previous patch, we currently have two tsubst entry points
for expression trees: tsubst_copy_and_build and tsubst_expr. But the
latter is just a super
On 9/25/23 16:43, Patrick Palka wrote:
This much more mechanical patch removes build_non_dependent_expr
(and make_args_non_dependent) and adjusts callers accordingly,
no functional change.
These two patches are OK either separately or squashed, whichever you
prefer.
gcc/cp/ChangeLog:
On 10/19/23 17:05, waffl3x wrote:
Also, I'm not sure what %qs is, should I be using that instead of %s
for strings?
The q prefix means quoted, with ' or other quotation marks, depending on
the locale.
On another topic, I have been trying to fix taking pointers to explicit
object member func
On 10/19/23 19:35, waffl3x wrote:
(waffl3x (me))
At a glance it seems like all I need to do then is disable the
PTRMEM_OK_P flag then.
I'm just now realizing that I'm almost certainly wrong about this. It
still needs PTRMEM_OK_P set if there are any implicit-object member
functions in the overl
On 10/12/23 18:05, Nathaniel Shead wrote:
On Thu, Oct 12, 2023 at 04:24:00PM -0400, Jason Merrill wrote:
On 10/12/23 04:53, Nathaniel Shead wrote:
On Wed, Oct 11, 2023 at 12:48:12AM +1100, Nathaniel Shead wrote:
On Mon, Oct 09, 2023 at 04:46:46PM -0400, Jason Merrill wrote:
On 10/8/23 21:03
On 10/11/23 11:41, Marek Polacek wrote:
On Wed, Oct 11, 2023 at 10:57:06AM +1100, Nathaniel Shead wrote:
On Mon, Oct 09, 2023 at 04:10:20PM -0400, Jason Merrill wrote:
On 10/9/23 06:03, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu with
GXX_TESTSUITE_STDS
On 10/20/23 00:34, waffl3x wrote:
Based on what you've said, I assume that OFFSET_REF handles static
member functions that are overloaded. But as I've said this seems to
contradict the comments I'm reading, so I'm not sure that I'm
understanding you correctly.
That's right. For instance,
str
On 10/20/23 12:31, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
In the PR, Joseph says that in C char8_t is not a distinct type. So
we should behave as if it can alias anything, like ordinary char.
In C, unsigned_char_type_node == char8_type_
On 8/24/23 09:58, Jakub Jelinek wrote:
Hi!
The following patch implements C++26 unevaluated-string.
As it seems to me just extra pedanticity, it is implemented only for
-std=c++26 or -std=gnu++26 and later and only if -pedantic/-pedantic-errors.
Hmm, I assumed it was accepted as a DR, but appa
Tested x86_64-pc-linux-gnu, applying to trunk. Patrick, sorry I didn't apply
this sooner.
-- 8< --
In r13-3766 I changed the logic at the end of tourney to avoid redundant
comparisons, but the change also meant skipping any less-good matches
between the champ_compared_to_predecessor candidate an
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This test doesn't break as expected with implicit constexpr.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/constexpr-diag1.C: Add -fno-implicit-constexpr.
---
gcc/testsuite/g++.dg/cpp1y/constexpr-diag1.C | 2 +-
1 file changed, 1 insert
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In my implementation of P0929 I treated a conversion to an rvalue of
abstract class type as a bad conversion, but that's still too soon to check
it; we need to wait until we're done with overload resolution.
gcc/cp/ChangeLog:
* cal
On 10/20/23 17:59, Jakub Jelinek wrote:
On Fri, Oct 20, 2023 at 04:12:48PM -0400, Jason Merrill wrote:
On 8/24/23 09:58, Jakub Jelinek wrote:
The following patch implements C++26 unevaluated-string.
As it seems to me just extra pedanticity, it is implemented only for
-std=c++26 or -std=gnu++26
On 10/23/23 11:16, David Malcolm wrote:
On Wed, Jan 25, 2023 at 4:09 PM Ben Boeckel via Gcc wrote:
This simplifies the interface for other UTF-8 validity detections when a
simple "yes" or "no" answer is sufficient.
libcpp/
* charset.cc: Add `_cpp_valid_utf8_str` which determines whe
On 10/23/23 05:10, Thomas Schwinge wrote:
Hi Patrick!
On 2023-10-20T13:36:30-0400, Patrick Palka wrote:
Built on x86_64-pc-linux-gnu, pushed to trunk as obvious (hopefully).
-- >8 --
This patch removes stray NON_DEPENDENT_EXPR checks following the removal
of this tree code from the C++ FE.
On 10/20/23 09:53, Ken Matsui wrote:
Since RID_MAX soon reaches 255 and all built-in traits are used approximately
once in a C++ translation unit, this patch removes all RID values for built-in
These two lines are too long; please wrap at 75 columns so they don't go
over 80 when git log adds 4
On 10/20/23 09:53, Ken Matsui wrote:
This patch accepts the use of built-in trait identifiers when they are
actually not used as traits. Specifically, we check if the subsequent token
is '(' for ordinary built-in traits or is '<' only for the special
__type_pack_element built-in trait. If those
On 10/20/23 17:37, Patrick Palka wrote:
On Fri, 20 Oct 2023, Patrick Palka wrote:
On Fri, 20 Oct 2023, Patrick Palka wrote:
On Fri, 20 Oct 2023, Ken Matsui wrote:
This patch implements built-in trait for std::is_invocable.
Nice! My email client unfortunately ate my first review attempt,
On 10/23/23 19:49, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
After the removal of NON_DEPENDENT_EXPR, cp_stabilize_reference which
used to just exit early for NON_DEPENDENT_EXPR is now more prone to
passing a weird templated tr
On 10/24/23 12:18, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we issue a bogus error: invalid operands of types 'unsigned char:2'
and 'int' to binary 'operator!=' when casting a bit-field of scoped enum
type to bool.
In build_static_cast_1, p
On 10/24/23 13:03, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
like the right approach?
-- >8 --
This PR is another instance of NON_DEPENDENT_EXPR having acted as an
"analysis barrier" for middle-end routines, and now that it's gone we
may end up passi
On 10/23/23 19:51, Patrick Palka wrote:
The second patch in this series is new and ensures that the candidates
list isn't mysteriously missing some candidates when noting other
candidates due to deletedness.
-- >8 --
This patch:
* changes splice_viable to move the non-viable candidates to t
On 10/23/23 19:51, Patrick Palka wrote:
During overload resolution, we sometimes outright ignore a function from
the overload set and leave no trace of it in the candidates list, for
example when we find a perfect non-template candidate we discard all
function templates, or when the callee is a t
On 10/23/23 19:51, Patrick Palka wrote:
With the previous two patches in place, we can now extend our
deletedness diagnostic to note the other considered candidates, e.g.:
deleted16.C: In function 'int main()':
deleted16.C:10:4: error: use of deleted function 'void f(int)'
10 | f(0
Pushing as obvious.
-- 8< --
Mention front-end uses of the address_space bit-field, and remove the
inaccurate "only".
gcc/ChangeLog:
* tree-core.h (struct tree_base): Update address_space comment.
---
gcc/tree-core.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --gi
On 10/25/23 12:03, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
We also need to avoid folding 'outer_nelts_check' when in a template
context to prevent an ICE on the below testcase. This patch achieves
this by replacing the fold_
On 10/25/23 14:32, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Declaring get() inline seems necessary to avoid link failure:
/usr/bin/ld: /tmp/ccwdv6Co.o: in function `g3@pr105322.Decltype()':
decltype-1_b.C:(.text._ZW8pr105322W8Decltype2g3v[_ZW8pr105
On 10/26/23 14:01, Patrick Palka wrote:
Since when in a template context we end up just discarding the result
of build_new_1, we don't have to bother with much of the code generation
it performs. This patch makes the function exit early, returning a dummy
non-erroneous result, once we've done pr
On 10/25/23 14:55, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Now that we don't have to worry about looking thruogh NON_DEPENDENT_EXPR,
we can easily extend the -Wparentheses warning in convert_for_assignment
to consider (non-de
On 10/25/23 06:28, Alex Coplan wrote:
On 11/10/2023 14:31, Alex Coplan wrote:
On 27/09/2023 15:27, Alex Coplan wrote:
Hi,
This is a v4 patch to address Jason's feedback here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630911.html
w.r.t. v3 it just removes a comment now that some
On 10/13/23 17:28, Lewis Hyatt wrote:
On Tue, Sep 12, 2023 at 04:09:21PM -0400, Lewis Hyatt wrote:
On Tue, Aug 8, 2023 at 5:53 PM Jason Merrill wrote:
On 7/31/23 22:22, Lewis Hyatt via Gcc-patches wrote:
`#pragma GCC target' is not currently handled in preprocess-only mode (e.g.,
On 8/28/23 06:34, Richard Biener wrote:
On Fri, 25 Aug 2023, Jakub Jelinek wrote:
Hi!
The following patch implements
CWG 2406 - [[fallthrough]] attribute and iteration statements
The genericization of some loops leaves nothing at all or just a label
after a body of a loop, so if the loop is la
On 9/18/23 13:21, Jakub Jelinek wrote:
Here is an updated version of the patch.
Compared to the last version, based on the discussion in the PR, the patch
1) warns (but only that) if size()/data() methods aren't declared
constexpr/consteval (or implicitly constexpr)
The language requirement
On 10/26/23 17:37, Patrick Palka wrote:
On Thu, 26 Oct 2023, Patrick Palka wrote:
On Thu, 26 Oct 2023, Jason Merrill wrote:
On 10/25/23 14:55, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Now that we don't have
On 10/27/23 15:55, Patrick Palka wrote:
New in patch 1/3:
* consistently use "non-viable" instead of "unviable"
throughout
* make 'champ' and 'challenger' in 'tourney' be z_candidate**
to simplify moving 'champ' to the front of the list. drive-by
cleanups in tourney, includi
On 10/27/23 15:55, Patrick Palka wrote:
With the previous two patches in place, we can now extend our
deletedness diagnostic to note the other considered candidates, e.g.:
deleted16.C: In function 'int main()':
deleted16.C:10:4: error: use of deleted function 'void f(int)'
10 | f(0
On 8/25/23 16:49, Jakub Jelinek wrote:
Hi!
This paper voted in as DR makes some multi-character literals ill-formed.
'abcd' stays valid, but e.g. 'á' is newly invalid in UTF-8 exec charset
while valid e.g. in ISO-8859-1, because it is a single character which needs
2 bytes to be encoded.
The fo
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In r12-6333 for PR33799, I fixed the example in [except.ctor]/2. In that
testcase, the exception is caught and the function returns again,
successfully.
In this testcase, however, the exception is rethrown, and hits two separate
cleanups:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
I noticed we were using a hash_table directly here instead of the simpler
hash_set interface. Also, let's check for the variable itself and repeats
earlier, since they should happen more often than any of the other cases.
gcc/cp/ChangeLog:
On 11/2/23 03:53, Jakub Jelinek wrote:
On Fri, Oct 27, 2023 at 07:05:34PM -0400, Jason Merrill wrote:
--- gcc/testsuite/g++.dg/cpp26/literals1.C.jj 2023-08-25 17:23:06.662878355
+0200
+++ gcc/testsuite/g++.dg/cpp26/literals1.C 2023-08-25 17:37:03.085132304
+0200
@@ -0,0 +1,65 @@
+// C
1 - 100 of 11598 matches
Mail list logo
