Currently finishing testing on Linux-x64. The only implementation change
in this patch is the initialization of the iterator variables in
__minmax_element,
otherwise it's just adding constexpr.
2014-12-18 Ville Voutilainen
C++14 constexpr min, max, minmax, min_element, max_element
On 18 December 2014 at 02:16, Ville Voutilainen
wrote:
> Currently finishing testing on Linux-x64. The only implementation change
> in this patch is the initialization of the iterator variables in
> __minmax_element,
> otherwise it's just adding constexpr.
>
> 2014-1
Tested on Linux-x64.
/cp
2014-12-19 Ville Voutilainen
Reject trailing return type for an operator auto().
* decl.c (grokdeclarator): Reject trailing return types for
all conversion operators, don't handle conversion operators
in the previous checks that deal with
Any comments on this?
On 19 December 2014 at 09:21, Ville Voutilainen
wrote:
> Tested on Linux-x64.
>
> /cp
> 2014-12-19 Ville Voutilainen
>
> Reject trailing return type for an operator auto().
> * decl.c (grokdeclarator): Reject trailing return types for
Tested on Linux-x64.
/cp
2015-01-05 Ville Voutilainen
PR c++/64489
* class.c (check_field_decls): Make copy assignment operators
complex only in c++98 mode.
/testsuite
2015-01-05 Ville Voutilainen
PR c++/64489
* g++.dg/ext/is_trivially_constructible1.C: Add tests for
On 12 September 2014 05:05, Jason Merrill wrote:
> Basically all we need to do here is accept it, like check_classfn; all the
> necessary checking was already done in check_explicit_specialization.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
I'd expect you want to remove the dg-bogus direc
On 12 September 2014 17:41, Jason Merrill wrote:
> On 09/12/2014 02:06 AM, Ville Voutilainen wrote:
>>
>> I'd expect you want to remove the dg-bogus directives from the test,
>> and the "// odd diagnostic" comment too?
> They aren't necessary, but they
Tested on Linux-x64.
/cp
2014-09-14 Ville Voutilainen
Do not diagnose lambda default arguments in c++14 modes.
* parser.c (cp_parser_lambda_declarator_opt): Make the pedwarn conditional.
/testsuite
2014-09-14 Ville Voutilainen
Do not diagnose lambda default arguments in c++14
Tested on Linux-x64.
/testsuite
2014-09-14 Ville Voutilainen
Minor cleanup, don't run tests for which compilation is enough.
* g++.dg/g++.dg/cpp1y/var-templ1.C: Change return to
static_assert, compile instead of running.
* g++.dg/g++.dg/cpp1y/var-templ3.C: Likewise.
* g++
On 14 September 2014 21:36, Paolo Carlini wrote:
> Hi,
>
> On 09/14/2014 07:44 PM, Ville Voutilainen wrote:
>>
>> Tested on Linux-x64.
>
> Thanks. In such cases you can as well remove the main: then is also
> immediately obvious the the testcase is a dg-do compil
On 15 September 2014 18:51, Jason Merrill wrote:
> On 09/14/2014 10:55 AM, Ville Voutilainen wrote:
>>
>> * g++.dg/cpp0x/lambda/lambda-defarg.C: Enable in c++11_only.
>> * g++.dg/cpp1y/lambda-defarg.C: New.
>
>
> Instead of adding a second test, make only
>>Ville asked for help with the necessary compiler intrinsics for the
>>is_trivially_* >>C++11 library traits. The first patch cleans up a few
>>oddities I noticed with the
>Great. I think this can be as well marked as PR c++/26099.
There's also PR c++/63362.
The intrinsics still fail to suppor
On 1 October 2014 11:11, Paolo Carlini wrote:
> Hi again,
>
> On 10/01/2014 12:48 AM, Ville Voutilainen wrote:
>>
>> The intrinsics still fail to support certain variadic cases, such as
>> template void bar() {
>> static_assert(__is_trivially_constructible(T, A
On 1 October 2014 20:20, Jason Merrill wrote:
> Here are two more patches: the first fixes trivial_fn_p for a defaulted
> default constructor overloaded with a template default constructor, and the
> second fixes the variadic case above.
Excellent, thank you very much. Paolo, feel free to close
I guess the subject says it all. Tested on Linux x86-64.
diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index 3ce9ebb..bb6014b 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -367,10 +367,7 @@ build_capture_proxy (tree member)
object = TREE_OPERAND (object, 0);
/* Remove the __ inse
As analysed in the bug report, the scope for the accessibility
check was incorrect, and hence the friend was not allowed access.
Fixed by pushing into the class scope before parsing the
base-clause, and popping afterwards to let the surrounding
nested-name-specifier popping work correctly.
Tested
On 22 January 2014 19:39, Paolo Carlini wrote:
> On 01/21/2014 04:24 PM, Jason Merrill wrote:
>>
>> OK, thanks.
>
> I don't think Ville has Write After Approval, thus I'm going to commit this
> on his behalf.
Oh, I was expecting Jason would do that. Note that Marek Polacek pointed
out two format
On 22 July 2014 15:53, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> On 07/22/2014 01:56 AM, Ville Voutilainen wrote:
>>
>> +/* Parse a type-parameter-key.
>> +
>> + type-parameter-key:
>> + class
>> + typedef
>> +
>> + Returns
This is my first shot at library patches. Do tell me if there's
anything massively
wrong. Tested on x86_64-linux.
2014-03-09 Ville Voutilainen
Implement is_trivially_default_constructible.
* doc/xml/manual/status_cxx2011.xml: Remove mention of is_trivially_default_cons
tructible not
Tested on X86-32 linux.
2011-10-21 Ville Voutilainen
PR c++/50811
* parser.c (cp_parser_class_head): Parse virt-specifiers regardless
of whether an id is present
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index ea0c4dc..dd2357b 100644
--- a/gcc/cp/parser.c
+++ b/gcc
>Could someone please review this?
+ if (cxx_dialect < cxx0x && !in_system_header)
+ pedwarn (input_location, OPT_pedantic,
+ "comma at end of enumerator list");
Why not use maybe_warn_cpp0x there?
On 30 October 2011 12:17, Magnus Fromreide wrote:
> Attached is a variation where maybe_warn_cpp0x is used.
> Please note how my new pedwarn breaks the pattern in maybe_warn_cpp0x.
Looks reasonable to me, but I'm not a maintainer. :) Jason?
On 4 November 2011 19:38, Jason Merrill wrote:
> Applied. Sorry for the delay, thanks for the pings.
So we want to pedwarn directly in parser, rather than use maybe_warn_cpp0x?
Magnus did a newer revision of the patch that uses maybe_warn_cpp0x, although
I don't know what the usual policy for th
On 4 November 2011 20:53, Jason Merrill wrote:
> Oops, I was ignoring the pings when looking for the actual patch. :)
> But in general I've been only been using maybe_warn_cpp0x for larger
> features.
Understood. Modification to cp-tree.h make rebuilds heavier, so I don't feel
strongly about it.
2012-06-16 Ville Voutilainen
Parse virt-specifiers after late-specified return types.
* parser.c (cp_parser_direct_declarator): Move virt-specifier parsing
after late-specified return type parsing
* override4.C: new
Git is doing weird things with my test, its diff
On 20 June 2012 10:35, Jason Merrill wrote:
> Applied, thanks. Note that your dg-error regexp doesn't make much sense:
>
>
> // { dg-error "expected type-specifier before 'final'||expected
> ';'||declaration doesn't declare anything" }
>
> Regular expression "or" uses a single |, so this ends up
Tested on Linux/X86-32.
2011-09-20 Ville Voutilainen
Implement delegating constructors. Based on an
original patch by Pedro Lamarao.
* cp-tree.h (enum cpp0x_warn_str): Add CPP0X_DELEGATING_CTORS.
* error.c (maybe_warn_cpp0x): Adjust
At Tue, 20 Sep 2011 20:29:27 +0300,
Ville Voutilainen wrote:
> --- a/gcc/testsuite/g++.dg/template/meminit1.C
> +++ b/gcc/testsuite/g++.dg/template/meminit1.C
> @@ -2,7 +2,7 @@
> template
> struct S
> {
> - S() : S() {} // { dg-error "base" }
> + S()
At Tue, 20 Sep 2011 17:05:55 -0400,
Jason Merrill wrote:
> Try to avoid reformatting lines that you don't actually change.
I find it hard to see what exactly changes there. Even if I
restore the indentation level, git still shows a diff. Perhaps
there were tabs in it...
> > + if (init == void_ty
At Tue, 20 Sep 2011 19:05:32 -0400,
Jason Merrill wrote:
> We don't need a new variable, just use basetype. TYPE_MAIN_VARIANT
> shouldn't affect the comparison to current_class_type.
>
> > + error ("mem-initializer for %qD follows constructor delegation; "
> > +"previous target c
On 21 September 2011 02:18, Ville Voutilainen
wrote:
> Ok, a new patch:
I just noticed that I have tabs disabled. You may want to tabify the patch.
At Wed, 21 Sep 2011 02:34:22 +0300,
Ville Voutilainen wrote:
>
> On 21 September 2011 02:18, Ville Voutilainen
> wrote:
> > Ok, a new patch:
> I just noticed that I have tabs disabled. You may want to tabify the patch.
Tabified and rebased on top of the nsdmi changes. Changelo
On 5 December 2011 17:51, Jason Merrill wrote:
> While applying it I noticed that we were sharing the argument trees between
> the two calls in a way that might be problematic, and I went ahead and fixed
> that.
Ouch. Thanks.
> I noticed that template/meminit1.C is ill-formed in C++11 as well, d
Tested on Linux/X86-32.
2011-07-21 Ville Voutilainen
Warn about the use of final/override in non-c++0x mode, and add
__final for non-c++0x mode.
* cp-tree.h (cpp0x_warn_str): Add CPP0X_OVERRIDE_CONTROLS.
* error.c (maybe_warn_cpp0x): Adjust
On 21 July 2011 18:23, Ville Voutilainen wrote:
> +struct F : E {}; { dg-error "cannot derive from ‘final’ base" }
Urgh, botched. Will send a new patch after I finish the test run. Note
to self: it's not
a good idea to run check-c++ target with make -j3. One might think
te
At Thu, 21 Jul 2011 18:34:35 +0300,
Ville Voutilainen wrote:
> On 21 July 2011 18:23, Ville Voutilainen wrote:
> > +struct F : E {}; { dg-error "cannot derive from ‘final’ base" }
> Urgh, botched. Will send a new patch after I finish the test run. Note
This one seems to wor
On 22 July 2011 22:43, Jason Merrill wrote:
> On 07/21/2011 01:39 PM, Ville Voutilainen wrote:
>> This one seems to work...
> Looks good. ChangeLogs?
> Jason
In the first patch-mail that had the borken test-patch. Repasted:
2011-07-21 Ville Voutilainen
Warn about t
This is just for the parser, the semantic analysis of virt-specifiers
will be done later. Also, these changes don't yet support a final
specifier on class.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index e538825..08d939f 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -4420,6 +4420
On 25 April 2011 18:32, Gabriel Dos Reis wrote:
>> typedef int cp_cv_quals;
>> +/* A type-qualifier, or bitmask therefore, using the VIRT_SPEC
>> + constants. */
>> +typedef int cp_virt_specifiers;
> could we use enums instead?
No reason not to, except that we don't for the cp_cv_quals above.
On 25 April 2011 20:06, Jason Merrill wrote:
>>> could we use enums instead?
>> No reason not to, except that we don't for the cp_cv_quals above. :) I
>> followed
>> the same approach.
> Sure, let's use enums for the named values. But I think we still want to
> use the int typedef for variables a
On 28 April 2011 00:56, Gabriel Dos Reis wrote:
>> Seems to fall over itself in a bunch of places. C++ bootstrap smells
>> like a red herring
>> to me at this point.
> Hmm, do you mean GCC fails to bootstrap with C++ a compiler before your mods?
I did make distclean, followed by
CC=g++ GCC=g++ CF
On 28 April 2011 01:40, Gabriel Dos Reis wrote:
> My configuration command line is:
> /home/gdr/src/gcc.svn/configure --enable-languages=c,c++
> --enable-build-with-cxx --disable-multilib --disable-nls
> and the builds is progressing quite very well with "g++".
> There is no need for manual setti
Tested on Linux/X86-32. Final on class is not yet supported,
that's probably what I'll be working on next. Changelog and
patch follow. Please holler if anything's wrong, as far as
I can see this works as it's supposed to.
2011-05-08 Ville Voutilainen
Implemen
Diagnose final on non-virtuals properly, diagnose override on
virtuals that don't actually override properly. Amend these
cases to the tests. Tested on Linux/X86-32.
2011-05-10 Ville Voutilainen
Fixes for override/final.
* class.c (check_for_override): Diagnose fin
At Tue, 10 May 2011 00:46:54 -0400,
Jason Merrill wrote:
> This is breaking an optimization: before this change we don't bother
> looking for overrides if we've never seen a virtual function with the
> same name. Just set overrides_found as well as DECL_VINDEX.
Ok. Tests still pass.
diff --git
At Tue, 10 May 2011 08:46:02 +0200,
Jakub Jelinek wrote:
> Hi!
> Just small style nits:
> s/int/bool/;s/0/false/;s/1/true/
> And the above condition is short enough that it could be on one line.
Ok. Tests still pass.
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 12db2bc..94a339d 100644
--- a
Tested on Linux/X86-32.
2011-05-13 Ville Voutilainen
Implement final on class.
* class.c (check_bases): Diagnose derivation from a final class.
* cp-tree.h (lang_type_class): Add is_final and adjust dummy.
* cp-tree.h (CLASSTYPE_FINAL): New
On 13 May 2011 20:46, Jason Merrill wrote:
> Why did you put this before the invalid template-id check, rather than
> after?
For no particular reason. Is it significant?
> Also, shouldn't we reject "override" on classes?
You can have stuff like
struct blah override{};
where struct blah is an e
At Fri, 13 May 2011 14:13:52 -0400,
Jason Merrill wrote:
> Yes, the order affects the handling of
> struct Undeclared final { };
> Add the error after the call to cp_parser_commit_to_tentative_parse, at
> which point we've decided that we're dealing with a class definition.
Here's a new patch. Ho
At Sat, 14 May 2011 09:01:39 +0200,
Paolo Carlini wrote:
> ... I'm wondering if wouldn't be more appropriate for the new testcase to be
> in /cpp0x, with a name like final.C
There are probably other tests there that need moving too,
if such moving is done. I don't have a strong opinion
either way
On 14 May 2011 19:41, Jason Merrill wrote:
> Paolo is right, C++0x tests go in cpp0x. I'll move this and your earlier
> one.
Duly noted, I'll keep that in mind for subsequent ones. Is the patch
otherwise ok?
On 14 May 2011 21:15, Jason Merrill wrote:
> On 05/14/2011 12:42 PM, Ville Voutilainen wrote:
>> Duly noted, I'll keep that in mind for subsequent ones. Is the patch
>> otherwise ok?
> Yes, and I've applied it.
Cool, thanks! I'm not quite sure whether the
On Sat, 16 Nov 2024 at 01:12, Jason Merrill wrote:
>
> Does this seem like an interesting direction?
>
> -- 8< --
>
> A problem with coexistence of module std and the library headers is that
> import and then #include tends to break (PR99000). But even with that
> fixed, it might be useful to be
On Thu, 13 Mar 2025 at 23:57, Jonathan Wakely wrote:
> > Do we also want to constraint the tuple(const _Elements&...)
> > constructor with requires sizeof...(_Elements) >= 1, which is present
> > on the C++17 version?
>
> Oh we don't need that constraint, because we have an explicit
> specializati
On Fri, 14 Mar 2025 at 00:03, Ville Voutilainen
wrote:
>
> On Thu, 13 Mar 2025 at 23:57, Jonathan Wakely wrote:
> > > Do we also want to constraint the tuple(const _Elements&...)
> > > constructor with requires sizeof...(_Elements) >= 1, which is present
> >
On Thu, 13 Mar 2025 at 23:16, Ville Voutilainen
wrote:
>
> On Thu, 13 Mar 2025 at 23:03, Patrick Palka wrote:
> > + // Defined as a template to work around PR libstdc++/116440.
> > + template
> > + constexpr explicit(!__convertible())
> >
On Thu, 13 Mar 2025 at 23:14, Patrick Palka wrote:
> Ah, I just realized the C++17 tuple impl already defines the
> tuple(const _Elements&...) constructor as a template in order to
> constrain it! So this patch arguably makes the C++20 constructor
> set more consistent with the C++17 impl, and so
On Thu, 13 Mar 2025 at 23:28, Patrick Palka wrote:
> > Oh, never mind. The pack is just deduced as an empty pack.
>
> Yep that's my understanding, though I don't know where in the standard
> this is specified, a quick Ctrl+F is failing me.
I'll go with https://eel.is/c++draft/temp.variadic#9, and
On Fri, 14 Mar 2025 at 00:04, Ville Voutilainen
wrote:
>
> On Fri, 14 Mar 2025 at 00:03, Ville Voutilainen
> wrote:
> >
> > On Thu, 13 Mar 2025 at 23:57, Jonathan Wakely wrote:
> > > > Do we also want to constraint the tuple(const _Elements&...)
>
On Thu, 13 Mar 2025 at 23:03, Patrick Palka wrote:
> + // Defined as a template to work around PR libstdc++/116440.
> + template
> + constexpr explicit(!__convertible())
> + tuple(const _Elements&... __elements)
I don't understand how a constructor template declared like thi
Well, is_xible is not is_xible_p because it doesn't need to be both is_*
and *_p. But xes_from_temporary is less obviously a question, so
xes_from_temporary_p would imho be a better name.
On Fri, Jul 15, 2022, 18:33 Marek Polacek via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> On Thu, Jul 14, 202
On Mon, 1 Mar 2021 at 20:09, Thiago Macieira via Libstdc++
wrote:
>
> On Sunday, 28 February 2021 07:05:47 PST Hans-Peter Nilsson wrote:
> > On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote:
> > > ints can be used in futexes. chars can't.
> >
> > Shouldn't that be an atomic type instead
On Mon, 1 Mar 2021 at 21:44, Thiago Macieira wrote:
> But you can see someone doing:
>
> #if __cplusplus >= 202002L && __has_include()
> # include
> #else
> # error "Please upgrade your compiler & standard library"
> #endif
>
> and using in their inline code. And as you say, if they then mix D
On Mon, 1 Mar 2021 at 23:54, Thiago Macieira wrote:
> But your suggestion does work. We don't need to apply them to all macros, only
> those that are new in a given version, like __cpp_lib_atomic_wait or
> __cpp_lib_latch in this case. Alternatively, implementations can set the macro
> to a given
On Tue, 2 Mar 2021 at 00:21, Thiago Macieira wrote:
> But the code I posted, if people are careful to use write like I did, would
> allow us to have the experimental "we're not sure this is right"
> implementation of atomic waits, latches, barriers and semaphores right now.
The code assumes that
On Wed, 3 Mar 2021 at 19:25, Jonathan Wakely via Libstdc++
wrote:
> Oh, except that is_scalar is surprisingly expensive to instantiate
> (its defined in a really expensive way) and since we control all uses
I'll be more than happy to write you an __is_scalar for GCC 12. :P
On Thu, 5 Aug 2021 at 15:11, Christophe Lyon via Libstdc++
wrote:
>
> Hi Jonathan,
>
> On Wed, Aug 4, 2021 at 2:04 PM Jonathan Wakely via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
> > On 04/08/21 12:56 +0100, Jonathan Wakely wrote:
> > >... and container adaptors.
> > >
> > >This adds the
On Thu, 5 Aug 2021 at 17:21, Jonathan Wakely via Libstdc++
wrote:
>
> On 04/08/21 12:55 +0100, Jonathan Wakely wrote:
> >This adds [[nodiscard]] throughout , as proposed by P2377R0
> >(with some minor corrections).
> >
> >The attribute is added for all modes from C++11 up, using
> >[[__nodiscard__
On Mon, 14 Sep 2020 at 09:18, Glen Fernandes via Libstdc++
wrote:
>
> Edit; Correct patch this time.
>
> Fix overflow handling in align
Should the test verify that space is unmodified when nullptr is returned?
On Mon, 14 Sep 2020 at 12:51, Ville Voutilainen
wrote:
>
> On Mon, 14 Sep 2020 at 09:18, Glen Fernandes via Libstdc++
> wrote:
> >
> > Edit; Correct patch this time.
> >
> > Fix overflow handling in align
>
> Should the test verify that space is unmodifie
On Mon, 14 Sep 2020 at 15:49, Glen Fernandes wrote:
>
> On Mon, Sep 14, 2020 at 5:52 AM Ville Voutilainen wrote:
> > On Mon, 14 Sep 2020 at 12:51, Ville Voutilainen
> > wrote:
> > > On Mon, 14 Sep 2020 at 09:18, Glen Fernandes
> > wrote:
> > > > Edit;
This seems like a worthy incremental
improvement to me.
2020-09-29 Ville Voutilainen
PR libstdc++/95904
* include/std/variant (__same_types): New.
(__check_visitor_result): Likewise.
(__check_visitor_results): Likewise.
(visit(_Visitor&&, _Variant
On Tue, 29 Sep 2020 at 14:20, Jonathan Wakely wrote:
> I think this is what we want:
>
>template
> constexpr inline __same_types = (is_same_v<_Tp, _Types> && ...);
>
> is_same_v is very cheap, it uses the built-in directly, so you don't
> need to instantiate any class templates at all.
>
On Sat, 3 Oct 2020 at 01:14, Jonathan Wakely wrote:
> OK for trunk with those leading spaces switched to tab.
The patch is borked, doesn't pass tests, fixing...
On Mon, 5 Oct 2020 at 01:15, Ville Voutilainen
wrote:
> The patch is borked, doesn't pass tests, fixing...
Unborked, ok for trunk if full testsuite passes?
2020-10-05 Ville Voutilainen
PR libstdc++/95904
* include/std/variant (__deduce_visit_result): Add a neste
On Sat, 10 Oct 2020 at 13:52, Jonathan Wakely wrote:
> index_sequence uses size_t not unsigned long. This parameter pack
> needs to be size_t... _Idxs, and the NTTP for __check_visitor_result
> should be size_t _Idx.
Fixed in
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=02cbd79e4728319e0887ad77
On Fri, 26 Nov 2021 at 14:29, Jonathan Wakely via Libstdc++
wrote:
>
> I've bored of having to do preprocessor checks before using
> is_constant_evaluated, so I've come up with this approach. Anybody got a
> better idea, or objections to this?
None here, I like this improvement.
On Wed, 8 Dec 2021 at 19:27, Jonathan Wakely via Libstdc++
wrote:
> After resolving a PEBKAC issue, here's an incremental diff that
> preserves the old behaviour for the existing @GLIBCXX_3.4.11 symbol,
> but adds a new @@GLIBCXX_3.4.30 symbol that supports cancellation via
> __forced_unwind.
>
>
On Wed, 4 Nov 2020 at 10:46, Stephan Bergmann via Libstdc++
wrote:
> To me it looks like it boils down to disagreement between g++ and
> clang++ over
>
> > struct S { static constexpr int f() { return 0; } };
> > void f(S & s) { static_assert(s.f(), ""); }
>
> where I think Clang might be right in
On Thu, 5 Nov 2020 at 21:52, Jonathan Wakely via Libstdc++
wrote:
>
> On 05/11/20 19:09 +, Jonathan Wakely wrote:
> >The relational operators for std::optional were using the wrong types
> >in the declval expressions used to constrain them. Instead of using
> >const lvalues they were using non
On Wed, 22 Sept 2021 at 20:09, Antony Polukhin via Libstdc++
wrote:
>
> std::unique_ptr allows construction from std::unique_ptr of derived
> type as per [unique.ptr.single.asgn] and [unique.ptr.single.ctor]. If
> std::default_delete is used with std::unique_ptr, then after such
> construction a d
On Wed, 22 Sept 2021 at 20:49, Antony Polukhin wrote:
>
> ср, 22 сент. 2021 г. в 20:23, Ville Voutilainen :
> >
> > On Wed, 22 Sept 2021 at 20:09, Antony Polukhin via Libstdc++
> > wrote:
> > >
> > > std::unique_ptr allows construction from st
On Fri, 1 Oct 2021 at 23:19, Jonathan Wakely via Libstdc++
wrote:
>
> This adds a non-standard extension to support initializing a
> std::jthread with a pointer to a member function that expects a
> stop_token to be added to the arguments. That use case is not supported
> by C++20, because the sto
Tested on Linux-PPC64.
This ain't no regression. But it seems to hamper attempts to fix library
regressions (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033).
2020-03-16 Ville Voutilainen
gcc/
PR c++/94197
* cp/method.c (assignable_expr, constructible_expr): Push
On Mon, 16 Mar 2020 at 23:25, Ville Voutilainen
wrote:
>
> Tested on Linux-PPC64.
>
> This ain't no regression. But it seems to hamper attempts to fix library
> regressions (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033).
It occurred to me that this can be done in on
On Tue, 17 Mar 2020 at 16:42, Jason Merrill wrote:
>
> On 3/17/20 9:04 AM, Jonathan Wakely wrote:
> > On 17/03/20 13:02 +, Jonathan Wakely wrote:
> >> Shouldn't the test use { dg-do compile { target c++11 } } instead of:
> >>
> >> +// { dg-do compile }
> >> +// { dg-options "-std=c++11" }
>
>
On Tue, 17 Mar 2020 at 16:52, Ville Voutilainen
wrote:
>
> On Tue, 17 Mar 2020 at 16:42, Jason Merrill wrote:
> >
> > On 3/17/20 9:04 AM, Jonathan Wakely wrote:
> > > On 17/03/20 13:02 +, Jonathan Wakely wrote:
> > >> Shouldn't the test use {
On Tue, 21 Jul 2020 at 02:28, Marek Polacek wrote:
>
> P1975R0 tweaks the static_cast wording: it says that "An expression e can be
> explicitly converted to a type T if [...] T is an aggregate type having a
> first
> element x and there is an implicit conversion sequence from e to the type of
>
On Tue, 21 Jul 2020 at 21:56, Marek Polacek wrote:
>
> On Tue, Jul 21, 2020 at 12:53:03PM +0300, Ville Voutilainen wrote:
> > On Tue, 21 Jul 2020 at 02:28, Marek Polacek wrote:
> > >
> > > P1975R0 tweaks the static_cast wording: it says that "An expressi
On Tue, 21 Jul 2020 at 22:39, Marek Polacek wrote:
> > Okay. I think it's remotely reasonable that a static_cast(42) would
> > work for an array, then.
> > And by a natural extension, that using the concrete type would also
> > work. That seems consistent,
> > but doesn't seem like it rises to the
On Sat, 18 Apr 2020 at 03:35, kamlesh kumar via Libstdc++
wrote:
>
> On Fri, Apr 17, 2020, 10:59 PM kamlesh kumar
> wrote:
>
> > Fixes all this.
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92156
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91630
> > https://gcc.gnu.org/bugzilla/show_bug.
On Mon, 20 Apr 2020 at 21:09, Ville Voutilainen
wrote:
>
> On Sat, 18 Apr 2020 at 03:35, kamlesh kumar via Libstdc++
> wrote:
> >
> > On Fri, Apr 17, 2020, 10:59 PM kamlesh kumar
> > wrote:
> >
> > > Fixes all this.
> > > https://gcc
On Tue, 21 Apr 2020 at 04:10, kamlesh kumar wrote:
>
> Thank you for reviewing.
> without _Decay to decay_t in the constructor which takes inplace_type_t,
> cases like this fails
> auto a = std::any(std::in_place_type, 5);
>
> for these constructors, standard does not say anything about
> not-sam
On Tue, 21 Apr 2020 at 09:11, Ville Voutilainen
wrote:
>
> On Tue, 21 Apr 2020 at 04:10, kamlesh kumar wrote:
> >
> > Thank you for reviewing.
> > without _Decay to decay_t in the constructor which takes inplace_type_t,
> > cases like this fails
> > aut
On Tue, 21 Apr 2020 at 11:29, kamlesh kumar wrote:
>
> Added the fix for emplace.
>
> diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
> index 6b7e68f0e63..f35d90e548d 100644
> --- a/libstdc++-v3/include/std/any
> +++ b/libstdc++-v3/include/std/any
> @@ -178,30 +178,17 @@ _
Aggregate-paren-init breaks tuple and optional. This fixes the breakage.
An LWG issue will be filed.
Full suite test run pending. Ok for master and gcc-10 if the full tests pass?
2020-05-01 Ville Voutilainen
PR libstdc++/94890
* include/std/optional (optional(_Up&&
On Fri, 1 May 2020 at 21:15, Ville Voutilainen
wrote:
>
> Aggregate-paren-init breaks tuple and optional. This fixes the breakage.
> An LWG issue will be filed.
The previous approach was bogus. Here's a better one. Ok for master
and gcc-10 if
full testsuite run passes?
202
On Mon, 11 May 2020 at 00:09, François Dumont via Libstdc++
wrote:
>
> I just committed this patch.
This was a commit-without-review. When the patch was originally
posted, the maintainer said
"Let's revisit it in a few weeks.". That's not the same as "OK when
stage1 reopens."
On Thu, 4 Jun 2020 at 01:52, Marc Glisse wrote:
>
> Hello,
>
> is there any drawback to the attached patch? It changes the code generated for
I don't get it. The noexceptness of the defaulted default constructor
should be a computation
of the noexceptness of the subobjects, and that should boil d
On Thu, 4 Jun 2020 at 02:13, Marc Glisse wrote:
>
> On Thu, 4 Jun 2020, Ville Voutilainen wrote:
>
> > On Thu, 4 Jun 2020 at 01:52, Marc Glisse wrote:
> >>
> >> Hello,
> >>
> >> is there any drawback to the attached patch? It changes the c
501 - 600 of 632 matches
Mail list logo
