On 12/6/22 13:35, Patrick Palka wrote:
This patch fixes some issues with substitution into a C++20 template
parameter object wrapper:
* The first testcase demonstrates a situation where the same_type_p
assert in relevant case of tsubst_copy doesn't hold, because (partial)
substitution of {
On 12/2/22 10:45, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
If the DECL_VALUE_EXPR of a VAR_DECL has EXPR_LOCATION set, then any use of
that variable looks like it has that location, which leads to the debugger
jumping back and forth for both lambdas and structured
On 12/17/22 08:40, Iain Sandoe wrote:
Hi.
It seems that everyone agrees that extern C coroutines should be permitted,
although I have yet to see a useful testcase.
This patch has been revised to append the suffices for such functions in
mangle.cc rather than as part of the outlined function dec
On 12/16/22 14:03, Patrick Palka wrote:
On Fri, 16 Dec 2022, Jason Merrill wrote:
On 12/16/22 11:45, Patrick Palka wrote:
Here we're rejecting the use of the captured 't' (of empty type) as a
template argument ultimately because convert_nontype_argument checks
potentiality using is_constant_ex
On 12/16/22 13:28, Marek Polacek wrote:
Here we crash because check_function_format was using TREE_PURPOSE
directly rather than using get_attribute_name.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
PR c/98487
gcc/c-family/ChangeLog:
* c-format.cc (check
On 11/22/22 03:00, Thomas Neumann wrote:
When registering a dynamic unwinding frame the fde list is sorted.
Previously, we split the list into a sorted and an unsorted part,
sorted the later using heap sort, and merged both. That can be
quite slow due to the large number of (expensive) comparison
On 12/9/22 12:34, Thomas Neumann wrote:
When registering an unwind frame with __register_frame_info_bases
we currently initialize that fde object eagerly. This has the
advantage that it is immutable afterwards and we can safely
access it from multiple threads, but it has the disadvantage
that we
On 12/16/22 11:45, Patrick Palka wrote:
Here we're rejecting the use of the captured 't' (of empty type) as a
template argument ultimately because convert_nontype_argument checks
potentiality using is_constant_expression which returns false for
captured variables since want_rval=false. But in th
On 12/10/22 10:54, Iain Sandoe wrote:
From: Andrew Pinski
This is Andrew Pinski's patch, I just did testing, adjusted the test case and
provided the Changelog.
tested on x86-64-Darwin21,
OK for trunk?
Iain
OK.
--- >8 ---
The PR reports that using integer_zero_node triggers a warning for
-W
On 12/15/22 11:15, Patrick Palka wrote:
There's a curious corner case with variadic member using-decls: the
terminal name can also contain a parameter pack, and only through naming
a conversion function, e.g.
using A::operator Ts...;
We currently only handle parameter packs appearing in the
On 12/15/22 14:31, Patrick Palka wrote:
On Thu, 15 Dec 2022, Patrick Palka wrote:
On Thu, 15 Dec 2022, Jason Merrill wrote:
On 12/12/22 12:20, Patrick Palka wrote:
When instantiating a constrained hidden template friend, we need to
substitute into its constraints for sake of declaration matc
On 12/15/22 13:00, Arsen Arsenović wrote:
Hi Jason,
Jason Merrill writes:
On 12/10/22 08:13, Arsen Arsenović wrote:
If the mangler is relied on, functions with extern "C" on them emit multiple
definitions of the same name.
But doing it here interferes with lazy mangling. How about appendi
On 12/8/22 11:42, Patrick Palka wrote:
Here when parsing the class-scope auto constrained by a qualified
concept-id, we first tentatively parse the overall member-declaration as
a deprecated access-declaration, during which we parse C as a
standalone TEMPLATE_ID_EXPR (not part of the auto) and en
On 12/9/22 16:57, Patrick Palka wrote:
Here during partial instantiation of the constexpr if, extra_local_specs
walks the statement looking for local specializations within to save and
possibly capture. However, we're thwarted by the fact that 'ts' first
appears inside an unevaluated context, an
On 12/10/22 04:33, Jakub Jelinek wrote:
Hi!
The TRUTH_NOT_EXPR case in cp_build_unary_op is one of the spots where
we somewhat fold immediately using invert_truthvalue_loc.
I've tried using
return build1_loc (location, TRUTH_NOT_EXPR, boolean_type_node, arg);
in there instead, but unfortunate
On 12/10/22 04:43, Arsen Arsenović wrote:
This script is a helper used to generate dg-output lines from an existing
program output conveniently. It takes care of escaping Tcl and ARE stuff.
contrib/ChangeLog:
* dg-out-generator.pl: New file.
---
contrib/dg-out-generator.pl | 67 ++
On 12/10/22 04:43, Arsen Arsenović wrote:
From: Jonathan Wakely
Make the output more readable. Don't output anything unless verbose
termination is enabled at configure-time.
libstdc++-v3/ChangeLog:
PR libstdc++/107792
PR libstdc++/107778
* src/experimental/contract.cc
On 12/10/22 04:43, Arsen Arsenović wrote:
The lowercase constants are more consistent with the standard, and it is
unlikely that the uppercase versions would've been accepted.
OK.
gcc/cp/ChangeLog:
* contracts.cc: Rename references to
contract_violation_continuation_mode cons
On 12/12/22 12:20, Patrick Palka wrote:
When instantiating a constrained hidden template friend, we need to
substitute into its constraints for sake of declaration matching.
Hmm, we shouldn't need to do declaration matching when there's only a
single declaration.
For
this substitution we us
On 12/10/22 08:13, Arsen Arsenović wrote:
If the mangler is relied on, functions with extern "C" on them emit multiple
definitions of the same name.
But doing it here interferes with lazy mangling. How about appending
the suffix into write_mangled_name instead of write_encoding? The
demangl
On 12/13/22 04:40, Jakub Jelinek wrote:
Hi!
The following patch adds typeinfos for the extended floating point
types and _Float{32,64}x.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
2022-12-13 Jakub Jelinek
PR libstdc++/108075
gcc/cp/
* rtti.c
On 12/14/22 12:48, Patrick Palka wrote:
We substitute the qualifying scope of a TYPENAME_TYPE directly using
tsubst_aggr_type (so that we can pass entering_scope=true) instead of
going through tsubst, which means we don't properly reuse typedefs
during this substitution. This ends up causing us
On 12/14/22 19:01, Patrick Palka wrote:
Here we're triggering an overzealous assert in unify during partial
ordering since the member function pointer constants are represented as
ordinary CONSTRUCTORs (with TYPE_PTRMEMFUNC_P TREE_TYPE) but the assert
expects only COMPOUND_LITERAL_P constructors.
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In these testcases, we weren't adequately verifying that constructing the
element type from an array element would have the same effect as
constructing it from one of the initializers.
PR c++/108071
PR c++/105838
gcc/cp/Cha
On 12/6/22 08:26, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
Ping.
-- 8< --
The PR (which isn't resolved by this commit) pointed out to me that GCC
should build with -Wconditionally-supported to support bootstrapping with a
C++11 compiler that makes different choices.
After the previous patches, I noticed that we were putting the array of
strings into .rodata, but then memcpying it into an automatic array, which
is pointless; we should be able to use it directly.
C++ doesn't allow us to do this for the backing array of an
initializer_list, but should be able to
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The previous patch avoided building an initializer_list at all when
building a vector, but in situations where that isn't possible, we
could still build the initializer_list with a loop over a constant array.
This is represented using a VEC
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
When constructing a vector from { "strings" }, first is built an
initializer_list, which is then copied into the strings in the
vector. But this is inefficient: better would be treat the { "strings" }
as a range and construct the strings in
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In this PR, initializing the array of std::string to pass to the vector
initializer_list constructor gets very confusing to the optimizers as the
number of elements increases, primarily because of all the std::allocator
temporaries passed to
Ping.
On 12/2/22 10:45, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
If the DECL_VALUE_EXPR of a VAR_DECL has EXPR_LOCATION set, then any use of
that variable looks like it has that location, which leads to the debugger
jumping back and forth for both lambdas and str
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
The PR (which isn't resolved by this commit) pointed out to me that GCC
should build with -Wconditionally-supported to support bootstrapping with a
C++11 compiler that makes different choices.
PR c++/64867
gcc/ChangeLog:
* conf
On 12/5/22 06:09, Prathamesh Kulkarni wrote:
On Mon, 5 Dec 2022 at 09:51, Patrick Palka via Gcc-patches
wrote:
These functions currently repeatedly dereference tp during the subtree
walk, dereferences which the compiler can't CSE because it can't
guarantee that the subtree walking doesn't modi
On 12/2/22 14:42, Patrick Palka wrote:
Here find_parameter_packs_r isn't recognizing the unexpanded pack T
inside the requires-expr's parameter list ultimately because
cp_walk_trees avoids walking the parameters, for good reason: in
requires (Ts... ts) { }
walking 'ts' would trigger a false
On 12/2/22 15:25, Iain Sandoe wrote:
Thanks to Adrian for working on this and producing the revised test-cases.
This has been tested on x86_64-darwin21 with our testsuite, cppcoro and
a patched version of folly (that enables the experimental coroutines tests)
without regresssion (actually a hand
On 12/2/22 18:58, Marek Polacek wrote:
On Fri, Nov 18, 2022 at 08:39:10PM -0500, Jason Merrill wrote:
On 11/18/22 18:52, Marek Polacek wrote:
+/* Parse a string literal or user defined string literal.
+
+ user-defined-string-literal :
+ string-literal ud-suffix
+
+ Parameters as for cp_
On 12/2/22 14:48, Marek Polacek wrote:
On Fri, Nov 18, 2022 at 09:26:26PM -0500, Jason Merrill wrote:
On 11/16/22 15:27, Jason Merrill wrote:
On 11/16/22 11:06, Marek Polacek wrote:
On Wed, Nov 16, 2022 at 08:41:53AM -0500, Jason Merrill wrote:
On 11/15/22 19:30, Marek Polacek wrote:
@@ -996
On 12/2/22 14:01, Patrick Palka wrote:
We implement using enum at class scope by injecting clones of the enum's
CONST_DECLs as fields of the class, for which CONST_DECL_USING_P is
true, so that qualified lookup naturally finds the enumerators.
Substitution into such a CONST_DECL currently ICEs ho
On 11/23/22 10:28, Jason Merrill wrote:
On 11/22/22 15:25, Jason Merrill wrote:
On 11/20/22 12:06, Bernhard Reutner-Fischer wrote:
Hi Jason!
The "meh" of result-decl-plugin-test-2.C should likely be omitted,
grokdeclarator would need some changes to add richloc hints and we
would not
be able
On 12/2/22 09:30, Patrick Palka wrote:
On Thu, 1 Dec 2022, Jason Merrill wrote:
On 12/1/22 14:51, Patrick Palka wrote:
On Thu, 1 Dec 2022, Jason Merrill wrote:
On 12/1/22 11:37, Patrick Palka wrote:
When defining a explicit specialization of a constrained member template
(of a class templat
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
If the DECL_VALUE_EXPR of a VAR_DECL has EXPR_LOCATION set, then any use of
that variable looks like it has that location, which leads to the debugger
jumping back and forth for both lambdas and structured bindings.
Rather than fix all the uses,
On 12/1/22 15:57, Patrick Palka wrote:
Here the two BOUND_TEMPLATE_TEMPLATE_PARMs written as C end
up having the same TYPE_CANONICAL since the ctp_table (which interns the
canonical form of a template type parameter) doesn't set the
comparing_specializations flag which controls how PARM_DECLs fro
On 12/1/22 14:51, Patrick Palka wrote:
On Thu, 1 Dec 2022, Jason Merrill wrote:
On 12/1/22 11:37, Patrick Palka wrote:
When defining a explicit specialization of a constrained member template
(of a class template) such as f and g in the below testcase, the
DECL_TEMPLATE_PARMS of the correspond
On 12/1/22 11:37, Patrick Palka wrote:
When defining a explicit specialization of a constrained member template
(of a class template) such as f and g in the below testcase, the
DECL_TEMPLATE_PARMS of the corresponding TEMPLATE_DECL are partially
instantiated, whereas its associated constraints ar
On 12/1/22 05:32, Jakub Jelinek wrote:
On Wed, Nov 30, 2022 at 01:52:08PM -0500, Jason Merrill wrote:
It looks like we're already deducing the type for the underlying S variable
in cp_convert_omp_range_for, we just aren't updating the types of the
individual bindings.
You're right. With this
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
Under the old logic for validate_switches, once suffix or starred got set,
they stayed set for all later switches found in the spec. So for e.g.
%{g*:%{%:debug-level-gt(0):
Once we see g*, starred is set. Then we see %:, and it sees that as a
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The first is an actual bug: remove_contract_attributes was only keeping one
attribute. The second just helps flow analysis in optimizers and static
analyzers.
gcc/cp/ChangeLog:
* contracts.cc (remove_contract_attributes): Actually
On 11/30/22 03:51, Iain Sandoe wrote:
Hi Adrian,
On 28 Nov 2022, at 20:44, Iain Sandoe wrote:
Bootstrapping and running the testsuite on x86_64 was successfull. No
regression occured.
This looks resonable to me, as said in the PR. I’d like to test a little wider
with some larger
codeba
On 11/30/22 10:51, Jakub Jelinek wrote:
On Tue, Nov 29, 2022 at 11:05:33PM +0100, Jakub Jelinek wrote:
On Tue, Nov 29, 2022 at 04:38:50PM -0500, Jason Merrill wrote:
--- gcc/testsuite/g++.dg/gomp/for-21.C.jj 2020-01-12 11:54:37.178401867
+0100
+++ gcc/testsuite/g++.dg/gomp/for-21.C 2022
On 11/29/22 07:32, Jakub Jelinek wrote:
Hi!
The PR84469 patch I've just posted regresses the for-21.C testcase,
when in OpenMP loop there are at least 2 associated loops and
in a template outer structured binding with non type dependent expression
is used in the expressions of some inner loop, w
On 11/29/22 15:03, Patrick Palka wrote:
In a SFINAE context composite_pointer_type returns error_mark_node if
the given pointer types are incompatible, but the SPACESHIP_EXPR case of
cp_build_binary_op wasn't prepared to handle error_mark_node, which led
to an ICE (from spaceship_comp_cat) for th
On 11/28/22 15:16, Patrick Palka wrote:
Here we're crashing when using an explicit specialization of a function
template with trailing requirements ultimately because decls_match
(called indirectly from register_specialization) returns false since the
template has trailing requirements whereas th
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Usually a requirement starting with 'typename' is a type-requirement, but it
might be a simple-requirement such as a functional cast to a typename-type.
PR c++/101733
gcc/cp/ChangeLog:
* parser.cc (cp_parser_requirement):
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Some clang folks mailed me asking about being less permissive about
'concept bool', so let's bump it up from pedwarn to permerror.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_decl_specifier_seq): Change 'concept bool'
diagnost
On 9/16/22 07:52, Jason Merrill wrote:
On 6/24/22 01:23, Alexandre Oliva via Gcc-patches wrote:
On Jun 23, 2022, Alexandre Oliva wrote:
Here's the patch. Regstrapped on x86_64-linux-gnu, also tested with a
cross to aarch64-rtems6. Ok to install?
Introduce -nostdlib++ option
Uhh, I went
On 11/23/22 05:10, Jonathan Wakely wrote:
The existence of this option makes users think they need it (even though
it's in neither -Wall nor -Wextra). Document that there's a better
option (since 2011).
OK for trunk?
OK.
-- >8 --
The newer -Wdelete-non-virtual-dtor has no false positives an
On 11/22/22 15:25, Jason Merrill wrote:
On 11/20/22 12:06, Bernhard Reutner-Fischer wrote:
Hi Jason!
The "meh" of result-decl-plugin-test-2.C should likely be omitted,
grokdeclarator would need some changes to add richloc hints and we
would not
be able to make a reliable guess what to remove
On 11/20/22 12:06, Bernhard Reutner-Fischer wrote:
Hi Jason!
The "meh" of result-decl-plugin-test-2.C should likely be omitted,
grokdeclarator would need some changes to add richloc hints and we would not
be able to make a reliable guess what to remove precisely.
C.f. /* Check all other uses of
On 11/21/22 18:00, Jakub Jelinek wrote:
Hi!
I've noticed
+FAIL: compiler driver --help=c++ option(s): "^ +-.*[^:.]\$" absent from output: "
-fcontract-build-level=[off|default|audit] Specify max contract level to generate runtime checks
for"
error, this is due to missing dot at the end of the
As Jonathan suggested.
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The contracts implementation was using strchrnul, which is a glibc
extension, so bootstrap broke on non-glibc targets. Use C89 strcspn
instead.
PR c++/107781
gcc/cp/ChangeLog:
* contracts.cc (role_
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Fixing -Wunused-parm warnings and link errors depending on where -fcontracts
appears on the command line.
gcc/cp/ChangeLog:
* contracts.cc (build_contract_condition_function):
Set DECL_ARTIFICIAL on return value parm.
Tested x86_64-pc-linux-gnu, and also manually changing the HAVE_DECL_STRCHRNUL
flag. OK for trunk?
-- 8< --
The Contracts implementation uses strchrnul, which is a glibc extension, so
bootstrap broke on non-glibc targets. I considered unconditionally using a
local definition, but I guess we mig
On 11/18/22 16:43, Patrick Palka wrote:
We already cache the overall normal form of a declaration's constraints
under the assumption that it can't change over the translation unit.
But if we have two constrained declarations such as
template void f() requires expensive && A;
template void
On 11/18/22 13:17, Jonathan Wakely wrote:
On 03/11/22 15:57 -0400, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. OK for trunk?
-- >8 --
This patch adds the library support for the experimental C++ Contracts
implementation. This now consists only of a default definition of the
violation ha
On 11/16/22 15:27, Jason Merrill wrote:
On 11/16/22 11:06, Marek Polacek wrote:
On Wed, Nov 16, 2022 at 08:41:53AM -0500, Jason Merrill wrote:
On 11/15/22 19:30, Marek Polacek wrote:
@@ -996,19 +1040,26 @@ register_constexpr_fundef (const
constexpr_fundef &value)
**slot = value;
}
-/*
On 11/18/22 18:52, Marek Polacek wrote:
On Thu, Nov 17, 2022 at 07:06:34PM -0500, Jason Merrill wrote:
On 11/16/22 20:12, Marek Polacek wrote:
On Wed, Nov 16, 2022 at 08:22:39AM -0500, Jason Merrill wrote:
On 11/15/22 19:35, Marek Polacek wrote:
On Tue, Nov 15, 2022 at 06:58:39PM -0500, Jason
On 11/18/22 16:59, Patrick Palka wrote:
IIUC the only practical difference between coerce_innermost_template_parms
and the main function coerce_template_parms is that the former takes
a multi-level template parameter list and returns a template argument
vector of the same depth, whereas the latte
On 11/18/22 11:34, Jakub Jelinek wrote:
On Fri, Nov 18, 2022 at 11:24:45AM -0500, Jason Merrill wrote:
Right, that's the C++17 implicit constexpr for lambdas, finish_function:
/* Lambda closure members are implicitly constexpr if possible. */
if (cxx_dialect >= cxx17
&& LAMBDA_
On 11/18/22 10:03, Marek Polacek wrote:
On Fri, Nov 18, 2022 at 08:48:32AM +0100, Jakub Jelinek wrote:
On Thu, Nov 17, 2022 at 07:15:05PM -0500, Marek Polacek wrote:
--- gcc/cp/decl.cc.jj 2022-11-16 14:44:43.692339668 +0100
+++ gcc/cp/decl.cc 2022-11-17 20:53:44.102011594 +0100
@@ -5600,
On 11/18/22 05:49, Bernhard Reutner-Fischer wrote:
On Thu, 17 Nov 2022 18:52:36 -0500
Jason Merrill wrote:
On 11/17/22 14:02, Bernhard Reutner-Fischer wrote:
On Thu, 17 Nov 2022 09:53:32 -0500
Jason Merrill wrote:
Instead, you want to copy the location for instantiations, i.e. check
DECL_
On 11/17/22 15:42, Jakub Jelinek wrote:
On Thu, Nov 17, 2022 at 07:42:40PM +0100, Jakub Jelinek via Gcc-patches wrote:
I thought for older C++ this is to catch
void
foo ()
{
constexpr int a = ({ static constexpr int b = 2; b; });
}
and for C++23 the only 3 spots that diagnose those.
But perha
On 11/16/22 20:12, Marek Polacek wrote:
On Wed, Nov 16, 2022 at 08:22:39AM -0500, Jason Merrill wrote:
On 11/15/22 19:35, Marek Polacek wrote:
On Tue, Nov 15, 2022 at 06:58:39PM -0500, Jason Merrill wrote:
On 11/12/22 06:53, Marek Polacek wrote:
In this PR, we are crashing because we've encou
On 11/17/22 13:38, Marek Polacek wrote:
[dcl.constinit]: "The constinit specifier shall be applied only to
a declaration of a variable with static or thread storage duration."
Thus, this ought to be OK:
constinit void (*p)() = nullptr;
but the error message I introduced when implementing co
On 11/17/22 14:02, Bernhard Reutner-Fischer wrote:
On Thu, 17 Nov 2022 09:53:32 -0500
Jason Merrill wrote:
On 11/17/22 03:56, Bernhard Reutner-Fischer wrote:
On Tue, 15 Nov 2022 18:52:41 -0500
Jason Merrill wrote:
On 11/12/22 13:45, Bernhard Reutner-Fischer wrote:
gcc/cp/ChangeLog:
On 11/17/22 03:56, Bernhard Reutner-Fischer wrote:
On Tue, 15 Nov 2022 18:52:41 -0500
Jason Merrill wrote:
On 11/12/22 13:45, Bernhard Reutner-Fischer wrote:
gcc/cp/ChangeLog:
* decl.cc (start_function): Set the result decl source location to
the location of the typespec.
--
On 11/17/22 04:13, Jakub Jelinek wrote:
On Wed, Nov 16, 2022 at 03:26:32PM -0500, Jason Merrill wrote:
On 11/16/22 09:46, Jakub Jelinek wrote:
On Wed, Nov 16, 2022 at 09:33:27AM -0500, Jason Merrill wrote:
and at that point I fear decl_maybe_constant_var_p will not work
properly. Shall this h
On 11/16/22 11:06, Marek Polacek wrote:
On Wed, Nov 16, 2022 at 08:41:53AM -0500, Jason Merrill wrote:
On 11/15/22 19:30, Marek Polacek wrote:
@@ -996,19 +1040,26 @@ register_constexpr_fundef (const constexpr_fundef &value)
**slot = value;
}
-/* FUN is a non-constexpr function called in
On 11/16/22 09:46, Jakub Jelinek wrote:
On Wed, Nov 16, 2022 at 09:33:27AM -0500, Jason Merrill wrote:
and at that point I fear decl_maybe_constant_var_p will not work
properly. Shall this hunk be moved somewhere else (cp_finish_decl?)
where we can already call it, or do the above in start_decl
On 11/16/22 09:08, Jakub Jelinek wrote:
On Wed, Nov 16, 2022 at 08:20:34AM -0500, Jason Merrill wrote:
Ok. But there is another issue, the
https://eel.is/c++draft/expr.const#5.2
spot that P2647R1 is changing didn't exist in C++20, it was only added with
P2242R3. So, if one would treat P2647R1
On 11/15/22 19:30, Marek Polacek wrote:
On Mon, Nov 14, 2022 at 06:00:58PM -0500, Jason Merrill wrote:
On 11/9/22 10:53, Marek Polacek wrote:
This patch implements C++23 P2448, which lifts more restrictions on the
constexpr keyword. It's effectively going the way of being just a hint
(hello, i
On 11/15/22 19:35, Marek Polacek wrote:
On Tue, Nov 15, 2022 at 06:58:39PM -0500, Jason Merrill wrote:
On 11/12/22 06:53, Marek Polacek wrote:
In this PR, we are crashing because we've encountered a UDL where a
string-literal is expected. This patch makes the parser reject string
and character
On 11/16/22 01:19, Jakub Jelinek wrote:
On Wed, Nov 16, 2022 at 12:27:02AM +, Jonathan Wakely wrote:
On Tue, 15 Nov 2022 at 23:50, Jakub Jelinek wrote:
On Tue, Nov 15, 2022 at 06:36:38PM -0500, Jason Merrill wrote:
Here is an updated patch that passed bootstrap/regtest, the only
change i
On 11/16/22 03:25, Jakub Jelinek wrote:
On Tue, Nov 15, 2022 at 04:49:27PM -0500, Jason Merrill wrote:
Or do you want to outline the
if (result != error_mark_node
&& TREE_CODE (TREE_TYPE (cand->fn)) != METHOD_TYPE
&& TREE_SIDE_EFFECTS (obj))
{
On 11/16/22 05:17, Jakub Jelinek wrote:
On Tue, Nov 15, 2022 at 06:22:36PM -0500, Jason Merrill wrote:
Here is another version of the patch that passed bootstrap/regtest, the only
change are tweaks to 2 further testcases.
2022-11-13 Jakub Jelinek
* decl.cc (grokdeclarator): Implemen
On 11/16/22 05:35, Jakub Jelinek wrote:
On Tue, Nov 15, 2022 at 05:57:26PM -0500, Jason Merrill wrote:
So, my understanding of this is we shouldn't check TYPE_ALIGN in
layout_compatible_type_p, but instead DECL_ALIGN in
next_common_initial_seqence.
Agreed.
+#if __cpp_lib_is_layout_compatible
On 11/8/22 16:10, Ben Boeckel wrote:
Unicode does not support such values because they are unrepresentable in
UTF-16.
libcpp/
* charset.cc: Reject encodings of codepoints above 0x10.
UTF-16 does not support such codepoints and therefore all
Unicode rejects such value
On 11/8/22 16:10, Ben Boeckel 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 whether
a C string is valid UTF-8 or not.
* internal.
On 11/12/22 06:53, Marek Polacek wrote:
In this PR, we are crashing because we've encountered a UDL where a
string-literal is expected. This patch makes the parser reject string
and character UDLs in all places where the grammar requires a
string-literal and not a user-defined-string-literal.
B
On 11/12/22 13:45, Bernhard Reutner-Fischer wrote:
gcc/cp/ChangeLog:
* decl.cc (start_function): Set the result decl source location to
the location of the typespec.
---
Bootstrapped and regtested on x86_86-unknown-linux with no regressions.
Ok for trunk?
Cc: Nathan Sidwell
Cc
On 11/13/22 01:45, Jakub Jelinek wrote:
On Fri, Nov 11, 2022 at 06:07:04PM +0100, Jakub Jelinek wrote:
The following patch on top of Marek's P2448 PR106649 patch
(mainly because that patch implements the previous __cpp_constexpr
feature test macro bump so this can't go in earlier; OT,
P2280R4 do
On 11/13/22 01:43, Jakub Jelinek wrote:
On Fri, Nov 11, 2022 at 08:43:04AM +0100, Jakub Jelinek wrote:
Again, because stage1 close is near, posting the following patch
to implement CWG 2654.
Ok for trunk if it passes bootstrap/regtest and is voted into C++23
and C++20 as a DR?
Here is an upda
On 11/13/22 01:50, Jakub Jelinek wrote:
On Sat, Nov 12, 2022 at 12:23:56PM +0100, Jakub Jelinek wrote:
The following patch implements CWG2635.
So far tested on
GXX_TESTSUITE_STDS=98,11,14,17,20,2b make check-g++
RUNTESTFLAGS="dg.exp=decomp*"
ok for trunk if it passes full bootstrap/regtest and
On 11/14/22 01:28, Jakub Jelinek wrote:
Hi!
Working virtually out of Baker Island.
When trying to figure out what to do about alignment,
layout_compatible_type_p returns false if TYPE_ALIGN on
ENUMERAL_TYPE/CLASS_TYPE_P (but not scalar types?) differ, or if members
don't have the same positions
On 11/14/22 14:33, Marek Polacek wrote:
On Thu, Nov 03, 2022 at 03:22:12PM -0400, Jason Merrill wrote:
On 11/1/22 13:01, Marek Polacek wrote:
It seems wrong to issue a -Wignored-qualifiers warning for code like:
static_assert(!is_same_v);
because there the qualifier matters. Likewise in
On 11/14/22 22:54, Jakub Jelinek wrote:
On Tue, Nov 15, 2022 at 09:54:00AM +0100, Jakub Jelinek via Gcc-patches wrote:
On Mon, Nov 14, 2022 at 07:00:54PM -0500, Jason Merrill wrote:
The following patch adds parsing of attributes to concept definition,
allows deprecated attribute to be specified
On 11/15/22 02:28, Jakub Jelinek wrote:
Hi!
On Mon, Nov 14, 2022 at 06:29:44PM -0500, Jason Merrill wrote:
Indeed. The code in build_new_method_call for this case has the comment
/* In an expression of the form `a->f()' where `f' turns
out to be a static membe
On 11/14/22 00:36, Jakub Jelinek wrote:
Hi!
Working virtually out of Baker Island.
The testcase from DR 2392 passes, so I assume we don't need to do
anything further for the DR.
Tested on x86_64-linux, ok for trunk?
OK.
2022-11-13 Jakub Jelinek
* g++.dg/DRs/dr2392.C: Add testca
On 11/14/22 00:40, Jakub Jelinek wrote:
Hi!
Working virtually out of Baker Island.
The following patch adds parsing of attributes to concept definition,
allows deprecated attribute to be specified (some ugliness needed
because CONCEPT_DECL is a cp/*.def attribute and so can't be mentioned
in c-
On 11/10/22 09:56, Patrick Palka wrote:
AFAICT the only purpose of tsubst_copy_and_build's
integral_constant_expression_p boolean parameter is to diagnose certain
constructs that aren't allowed to appear in a C++98 integral constant
expression context, specifically casts to a non-integral type (d
On 11/10/22 09:56, Patrick Palka wrote:
The function_p parameter of tsubst_copy_and_build (added in r69316) is
inspected only in its IDENTIFIER_NODE case, where it controls whether we
diagnose unqualified name lookup failure for the given identifier. But
I think ever since r173965, we never subs
On 11/10/22 21:40, Jakub Jelinek wrote:
Hi!
As stage1 is very close, here is a patch that implements the static
operator[] paper.
One thing that doesn't work properly is the same problem as I've filed
yesterday for static operator() - PR107624 - that side-effects of
the postfix-expression on whi
501 - 600 of 1568 matches
Mail list logo
