On 11/21/23 17:51, Jakub Jelinek wrote:
On Tue, Nov 21, 2023 at 11:19:56PM +0100, Jakub Jelinek wrote:
+ error_at (location, "% message must be a string "
+ "literal or object with % and "
+ "% members");
Let's print the type of
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In review of the deducing 'this' patch, it came up that the logic in
start_preparsed_function around the ctype variable was convoluted, being
set for non-static member functions and friends, but not for static member
functions. Let's set
On 11/21/23 08:04, waffl3x wrote:
Bootstrapped and tested on x86_64-linux with no regressions.
Hopefully this patch is legible enough for reviewing purposes, I've not
been feeling the greatest so it was a task to get this finished.
Tomorrow I will look at putting the diagnostics in
On 11/21/23 12:17, Jakub Jelinek wrote:
On Thu, Oct 26, 2023 at 09:21:47PM -0400, Jason Merrill wrote:
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
On 11/15/23 00:13, Sam James wrote:
Florian Weimer writes:
* Sam James:
Florian Weimer writes:
Most -Wimplicit-int warnings were unconditionally disabled for system
headers. Only missing types for parameters in old-style function
definitions resulted in warnings. This is inconsistent
On 11/17/23 09:50, Alex Coplan wrote:
Hi,
This is a v5 patch to address Marek's feedback here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635157.html
I also implemented Jason's suggestion to use constexpr for the tables
from this review:
On 11/17/23 16:46, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This patch is an attempt to implement (part of?) P2280, Using unknown
pointers and references in constant expressions. (Note that R4 seems to
only allow References to unknown/Accesses
On 11/19/23 21:33, Alexandre Oliva wrote:
Unlike C, C++ doesn't mark enums shortened by -fshort-enums as packed.
This makes for undesirable warning differences between C and C++,
e.g. c-c++-common/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early*.c
triggers a warning about a type cast
On 11/19/23 02:28, Alexandre Oliva wrote:
When targetm.cxx.cdtor_return_this() holds, cdtors have a
non-VOID_TYPE_P result, but IMHO this ABI implementation detail
shouldn't leak to the abstract language conceptual framework, in which
cdtors don't have return values. For contracts,
On 11/19/23 02:38, Alexandre Oliva wrote:
__dt_base doesn't get its body from a maybe_return_this caller, it's
rather cloned with the full body within build_clone, and then it's
left alone, without going through finish_function_body or
build_delete_destructor_body, that call maybe_return_this.
On 11/19/23 16:44, waffl3x wrote:
On Sunday, November 19th, 2023 at 1:34 PM, Jason Merrill
wrote:
On 11/19/23 13:36, waffl3x wrote:
I'm having trouble fixing the error for this case, the control flow
when the functions are overloaded is much more complex.
struct S {
void f(this S
Tested x86_64-pc-linux-gnu. Are the library bits OK? Any comments before I
push this?
-- 8< --
Per https://github.com/itanium-cxx-abi/cxx-abi/issues/24 and
https://github.com/itanium-cxx-abi/cxx-abi/pull/166
We need to mangle constraints to be able to distinguish between function
templates
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
There should never be a reason to compare more than one level of template
parameters; additional levels are for the enclosing context, which is either
irrelevant (for a template template parameter) or already compared (for a
member
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Let's use a more informative name instead of DECL_VIRTUAL_P directly.
gcc/cp/ChangeLog:
* cp-tree.h (DECL_TEMPLATE_PARM_CHECK): New.
(DECL_IMPLICIT_TEMPLATE_PARM_P): New.
(decl_template_parm_check): New.
*
On 11/19/23 13:36, waffl3x wrote:
I'm having trouble fixing the error for this case, the control flow
when the functions are overloaded is much more complex.
struct S {
void f(this S&) {}
void f(this S&, int)
void g() {
void (*fp)(S&) =
}
};
This seemed to have fixed the non
On 11/19/23 08:39, waffl3x wrote:
Funny enough I ended up removing the ones I was thinking about, seems
to always happen when I ask style questions but I'm glad to hear it's
okay going forward.
I'm having trouble fixing this bug, based on what Gasper said in
PR102609 I am pretty sure I know
On Sat, Nov 18, 2023 at 1:43 AM waffl3x wrote:
>
> The patch is coming along, I just have a quick question regarding
> style. I make use of IILE's (immediately invoked lambda expression) a
> whole lot in my own code. I know that their use is controversial in
> general so I would prefer to ask
You recently pinged this patch, but I haven't seen an update since this
review?
On 10/26/23 21:21, Jason Merrill wrote:
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
On 11/11/23 03:22, Jakub Jelinek wrote:
Hi!
While filing a clang request to return 18 on _BitInts for
__builtin_classify_type instead of -1 they return currently, I've
noticed that we return -1 for vector types. I'm not convinced it is a good
idea to change behavior of __builtin_classify_type
On 10/30/23 08:57, Richard Biener wrote:
We have a support case that shows GCC 7 sometimes creates
DW_TAG_label refering to itself via a DW_AT_abstract_origin
when using LTO. This for example triggers the sanity check
added below during LTO bootstrap.
Making this check cover more than just
On 11/5/23 12:42, Jakub Jelinek wrote:
Hi!
check_field_decls for DECL_C_BIT_FIELD FIELD_DECLs with error_mark_node
TREE_TYPE continues early and doesn't call check_bitfield_decl which would
either set DECL_BIT_FIELD, or clear DECL_C_BIT_FIELD. So, the following
testcase ICEs after emitting
On 11/15/23 13:03, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/13/12 (to match the PR107939 / r13-6525-ge09bc034d1b4d6 backports)?
-- >8 --
potential_constant_expression for a CALL_EXPR to a non-overload tests
FUNCTION_POINTER_TYPE_P on
On 11/15/23 17:24, Marek Polacek wrote:
On Tue, Nov 14, 2023 at 05:27:03PM -0500, Jason Merrill wrote:
On 11/14/23 10:58, Marek Polacek wrote:
On Mon, Nov 13, 2023 at 09:26:41PM -0500, Jason Merrill wrote:
On 11/10/23 20:13, Marek Polacek wrote:
On Thu, Nov 09, 2023 at 07:07:03PM -0500
On 11/1/23 11:07, Patrick Palka wrote:
On Tue, 31 Oct 2023, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Does it look OK for release branches as well for sake of PR111703?
-- >8 --
potential_constant_expression was incorrectly treating
On 11/14/23 11:10, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
For decltype((x)) within a lambda where x is not captured, we dubiously
require that the lambda has a capture default, unlike for decltype(x).
This patch fixes this
On 11/14/23 11:35, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
OK.
-- >8 --
The NON_DEPENDENT_EXPR removal exposed that is_direct_enum_init may end
up checking convertibility of a type-dependent argument.
PR c++/112515
On 11/14/23 16:04, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
Here we're ICEing from strip_typedefs for the partially instantiated
requires-expression when walking its REQUIRES_EXPR_EXTRA_ARGS since it's
a TREE_LIST with
On 11/14/23 10:43, Patrick Palka wrote:
On Fri, 10 Nov 2023, Jason Merrill wrote:
On 11/10/23 10:28, Patrick Palka wrote:
On Fri, 10 Nov 2023, Patrick Palka wrote:
On Thu, 9 Nov 2023, Jason Merrill wrote:
On 11/8/23 16:59, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc
On 11/14/23 10:58, Marek Polacek wrote:
On Mon, Nov 13, 2023 at 09:26:41PM -0500, Jason Merrill wrote:
On 11/10/23 20:13, Marek Polacek wrote:
On Thu, Nov 09, 2023 at 07:07:03PM -0500, Jason Merrill wrote:
On 11/9/23 14:58, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu
On 11/14/23 12:38, Jakub Jelinek wrote:
On Mon, Nov 13, 2023 at 10:59:52PM -0500, Jason Merrill wrote:
On 11/13/23 06:50, Jakub Jelinek wrote:
The following patch implements C++26 P2864R2 by emitting pedwarn enabled by
the same options as the C++20 and later warnings (i.e. -Wenum-compare
On 11/13/23 01:02, Iain Sandoe wrote:
The clang compiler supports essentially arbitrary, per-attribute, syntax and
token forms for attribute arguments. This extends to the case where token
forms are required to be accepted that are not part of the valid set for
standard C or C++.
A motivating
On 11/3/23 14:58, Jakub Jelinek wrote:
On Thu, Nov 02, 2023 at 10:23:27PM -0400, Jason Merrill wrote:
Under the existing diagnostic I'd like to distinguish the different cases
more, e.g.
"multicharacter literal with %d characters exceeds 'int' size of %d bytes"
"multicharacter
On 11/14/23 02:33, Jakub Jelinek wrote:
Hi!
On Tue, Nov 14, 2023 at 08:23:27AM +0100, Jakub Jelinek wrote:
The following patch (in plaintext just a pseudo-patch where I've left out
the too big parts of either wget downloaded or regenerated files out with
..., full patch attached compressed)
On 11/13/23 06:50, Jakub Jelinek wrote:
The following patch implements C++26 P2864R2 by emitting pedwarn enabled by
the same options as the C++20 and later warnings (i.e. -Wenum-compare,
-Wdeprecated-enum-enum-conversion and -Wdeprecated-enum-float-conversion
which are all enabled by default).
On 11/11/23 05:43, waffl3x wrote:
[combined reply to all three threads]
On 11/9/23 23:24, waffl3x wrote:
There are a few known issues still present in this patch. Most importantly,
the implicit object argument fails to convert when passed to by-value xobj
parameters. This occurs both for xobj
On 11/10/23 20:13, Marek Polacek wrote:
On Thu, Nov 09, 2023 at 07:07:03PM -0500, Jason Merrill wrote:
On 11/9/23 14:58, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we are wrongly parsing
int y(auto(42));
which uses the C++23 c
On 11/13/23 14:01, Jonathan Wakely wrote:
Tested x86_64-linux. Does this make sense for trunk?
OK, thanks.
These forbidden conversions are defined as narrowing conversions, and we
already use -Wnarrowing to control other "ill-formed, but only warn by
default" diagnostics required by the
On 11/6/23 17:34, Marek Polacek wrote:
On Fri, Nov 03, 2023 at 01:51:07PM -0400, Jason Merrill wrote:
On 11/2/23 11:28, Marek Polacek wrote:
On Sat, Oct 14, 2023 at 12:56:11AM -0400, Jason Merrill wrote:
On 10/10/23 13:20, Marek Polacek wrote:
I suppose some
functions cannot possibly
[combined reply to all three threads]
On 11/9/23 23:24, waffl3x wrote:
I'm unfortunately going down a rabbit hole again.
--function.h:608
`/* If pointers to member functions use the least significant bit to indicate
whether a function is virtual, ensure a pointer to this function will have
On 11/10/23 10:28, Patrick Palka wrote:
On Fri, 10 Nov 2023, Patrick Palka wrote:
On Thu, 9 Nov 2023, Jason Merrill wrote:
On 11/8/23 16:59, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here when building up the
On 11/10/23 12:25, Patrick Palka wrote:
On Thu, 9 Nov 2023, Jason Merrill wrote:
On 11/7/23 10:08, Patrick Palka wrote:
bootstrapped and regtested on x86_64-pc-linxu-gnu, does this look OK for
trunk?
-- >8 --
In the COMPOUND_EXPR case of tsubst_expr, we were redundantly clear
On 11/7/23 10:08, Patrick Palka wrote:
bootstrapped and regtested on x86_64-pc-linxu-gnu, does this look OK for trunk?
-- >8 --
In the COMPOUND_EXPR case of tsubst_expr, we were redundantly clearing
the tf_decltype flag when substituting the LHS and also neglecting to
propagate it when
On 11/7/23 14:52, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
We usually don't see capture proxies in finish_decltype_type because
process_outer_var_ref is a no-op inside an unevaluated context and
so a use of a capture
On 11/7/23 14:52, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
The capture decltype handling in finish_decltype_type wasn't looking
through implicit INDIRECT_REF (added by convert_from_reference), which
caused us to incorrectly
On 11/8/23 16:59, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here when building up the non-dependent .* expression, we crash from
fold_convert on 'b.a' due to this (templated) COMPONENT_REF having an
IDENTIFIER_NODE instead of
On 11/9/23 14:58, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we are wrongly parsing
int y(auto(42));
which uses the C++23 cast-to-prvalue feature, and initializes y to 42.
However, we were treating the auto as an implicit template
On 11/5/23 10:06, waffl3x wrote:
I had wanted to write about some of my frustrations with trying to
write a test for virtual specifiers and errors/warnings for
shadowing/overloading virtual functions, but I am a bit too tired at
the moment and I don't want to delay getting this up for another
correct successes without requires, and by
extension a non dependent variable
+// so for the time being, there are no non dependent tests invalid calls.
I don't understand the problem, you can have requires-expressions in
non-dependent context.
JasonFrom 07b007a44a277f7b5cde69f5e54c2be336dfca1b
On 11/4/23 02:40, waffl3x wrote:
I'm unfortunately going down a rabbit hole again.
--function.h:608
```
/* If pointers to member functions use the least significant bit to
indicate whether a function is virtual, ensure a pointer
to this function will have that bit clear. */
#define
LGTM but I'd like Marek to approve it.
On Fri, Nov 3, 2023, 3:12 PM Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because with -Wno-attributes=foo::no_sanitize
> (but generally any other non-gnu namespace and some gnu well known
> attribute
> name within that other namespace) the
On 11/3/23 00:44, waffl3x wrote:
That leaves 2, 4, and 5.
2. I am pretty sure xobj functions should have the struct they are a
part of recorded as the method basetype member. I have already checked
that function_type and method_type are the same node type under the
hood and it does appear to
On 11/2/23 11:28, Marek Polacek wrote:
On Sat, Oct 14, 2023 at 12:56:11AM -0400, Jason Merrill wrote:
On 10/10/23 13:20, Marek Polacek wrote:
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
On 10/28/23 00:07, waffl3x wrote:
I wanted to change DECL_NONSTATIC_MEMBER_FUNCTION_P to include explicit
object member functions, but it had some problems when I made the
modification. I also noticed that it's used in cp-objcp-common.cc so
would making changes to it be a bad idea?
-- cp-tree.h
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
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.
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:
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
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 |
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,
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 to wo
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
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
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.,
when
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
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
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
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()':
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
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
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 |
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
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
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
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,
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
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/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
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
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/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
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
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:
*
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
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
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
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 ==
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,
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/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/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
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
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/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
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/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/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 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 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:
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
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
701 - 800 of 11376 matches
Mail list logo
