e the library work-around.
Tested on Linux-PPC64, ok for trunk and the gcc-8 branch?
2018-07-04 Ville Voutilainen
gcc/cp/
PR c++/86398
* method.c (is_trivially_xible): Return false
if is_xible_helper returns a NULL_TREE.
testsuite/
PR c++/86398
* g++.d
and capturepack/parampack, capturepack/param, capture/parampack
and capture/param clashes.
Guidance welcome. This approach has the benefit that it, well,
seems to work. :)
2018-07-07 Ville Voutilainen
gcc/cp/
PR c++/79133
* lambda.c (start_lambda_function): Reject captures and paramete
On 7 July 2018 at 16:15, Jason Merrill wrote:
> Did you consider handling this in check_local_shadow?
Roughly like this, not fully tested yet:
2018-07-07 Ville Voutilainen
gcc/cp/
PR c++/79133
* name-lookup.c (check_local_shadow): Reject captures and parameters
with
On 7 July 2018 at 21:12, Paolo Carlini wrote:
> Should we really print the same name twice? Looks like we don't have
> available (yet) a location for cap - that would likely enable fancy things -
> but in that case too I don't think the user would find that interesting
> seeing the same name twice
On 7 July 2018 at 21:55, Ville Voutilainen wrote:
> On 7 July 2018 at 21:12, Paolo Carlini wrote:
>> Should we really print the same name twice? Looks like we don't have
>> available (yet) a location for cap - that would likely enable fancy things -
>> but in that case
Needed one more tweak; when dealing with a capture proxy, always bail
out and never fall through to the warning-handling
code below the DR 2211 check.
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 3aafb0f..fee5482 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -264
On 8 July 2018 at 00:35, Paolo Carlini wrote:
> Hi,
>
> On 07/07/2018 23:20, Ville Voutilainen wrote:
>>
>> + error_at (DECL_SOURCE_LOCATION (old),
>> + "capture %qD and lambda parameter %qD "
>>
On 8 July 2018 at 01:54, Paolo Carlini wrote:
>> That would make this more consistent with such a shadow warning, but I
>> don't want
>> to use the shadowing wording (which would be easy to do; just set
>> 'shadowed' and do
>> a 'goto inform'), because this isn't shadowing in the precise sense;
>>
On 19 July 2018 at 20:18, Jonathan Wakely wrote:
> This removes some seemingly redundant conditions from a few traits. If
> __is_trivially_assignable correctly checks the assignable condition as
> well as triviality, then we don't need is_assignable explicitly. Does
> anybody see a problem with t
On 31 July 2018 at 20:07, Jonathan Wakely wrote:
> The solution for PR 77537 causes ambiguities due to the extra copy
> assignment operator taking a __nonesuch_no_braces parameter. The copy
> and move assignment operators can be defined as defaulted to meet the
> semantics required by the standard
On Thu, 11 Apr 2024 at 20:22, Jonathan Wakely wrote:
>
> I'm considering this late patch for gcc-14 to workaround an issue
> discovered by a recent Clang change.
>
> I'm not yet sure if Clang is right to require these symbols. It's not
> really clear, because always_inline isn't part of the standa
On Fri, 12 Jan 2024 at 00:16, Jonathan Wakely wrote:
>
> I'd like to commit this to trunk for GCC 14. Please take a look.
Without looking at it in excruciating detail, it's pretty much along
the lines of what I have always envisioned
to be a powerful combination of concepts and if-constexpr. My g
On Wed, 3 Jul 2024 at 18:33, Jonathan Wakely wrote:
>
> On Thu, 27 Jun 2024 at 11:52, Jonathan Wakely wrote:
> >
> > This refactoring to use RAII doesn't seem to make any difference in
> > benchmarks, although the generated code for some std::vector operations
> > seems to be slightly larger. Mayb
On Wed, 24 Jul 2024 at 22:51, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> Any reason not to do this? I don't think the assertions are useful to
> catch implementation bugs where we access the contained value without
> checking it - we should use tests for that.
Looks good to me.
> The cu
On Thu, 2 May 2024 at 20:25, Ken Matsui wrote:
> > There was some discussion of how to name the built-ins back in
> > https://gcc.gnu.org/pipermail/gcc-patches/2007-March/thread.html#212171
> > but __builtin wasn't discussed.
> >
> > Apparently this naming convention follows the MSVC precedent:
>
On Tue, 7 May 2024 at 16:47, Jonathan Wakely wrote:
>
> I don't think using a macro for these really saves us much, we can do
> this to avoid duplication instead. And now it's not a big, multi-line
> macro that's a pain to edit.
>
> Any objections?
No, that's beautiful, ship it.
Tested on Linux-PPC64.
2015-07-12 Ville Voutilainen
Implement std::experimental::fundamentals_v2::make_array and
std::experimental::fundamentals_v2::to_array.
* include/Makefile.am: Add array.
* include/Makefile.in: Add array.
* include/experimental/array: New
On 12 July 2015 at 21:45, Ville Voutilainen wrote:
> Tested on Linux-PPC64.
>
> 2015-07-12 Ville Voutilainen
> Implement std::experimental::fundamentals_v2::make_array and
> std::experimental::fundamentals_v2::to_array.
> * include/Makefile.am: Add arra
On 13 July 2015 at 01:25, Ville Voutilainen wrote:
> On 12 July 2015 at 21:45, Ville Voutilainen
> wrote:
>> Tested on Linux-PPC64.
>>
>> 2015-07-12 Ville Voutilainen
>> Implement std::experimental::fundamentals_v2::make_array and
>> std::exp
Tested on Linux-PPC64.
2015-07-15 Ville Voutilainen
Implement N4280, Non-member size() and more (Revision 2)
* include/bits/range_access.h: Change class to typename
in every template.
* include/bits/range_access.h(size, empty, data): New.
* testsuite/24_iterators
Tested on Linux-PPC64.
2015-07-19 Ville Voutilainen
Implement N4089 Safe conversions in unique_ptr (LWG 2118)
and N4387 LWG 2228: Missing SFINAE rule in unique_ptr
templated assignment
* include/bits/unique_ptr.h
(__remove_cv, __is_derived_Tp): Remove.
(default_delete
On 19 July 2015 at 19:56, Ville Voutilainen wrote:
> Tested on Linux-PPC64.
>
> 2015-07-19 Ville Voutilainen
> Implement N4089 Safe conversions in unique_ptr (LWG 2118)
> and N4387 LWG 2228: Missing SFINAE rule in unique_ptr
> templated assignment
> * incl
On 19 July 2015 at 20:13, Ville Voutilainen wrote:
> Minor changelog fix, the single-pointer functions aren't constrained with
> array compatibility, but with deleter compatibility.
And that should be single-object, not single-pointer, not that it has any
effect on the corrected changelog. :)
On 19 July 2015 at 20:14, Ville Voutilainen wrote:
> On 19 July 2015 at 20:13, Ville Voutilainen
> wrote:
>> Minor changelog fix, the single-pointer functions aren't constrained with
>> array compatibility, but with deleter compatibility.
>
> And that should be sing
Tested on Linux-PPC64.
2015-07-21 Ville Voutilainen
Implement N4279, Improved insertion interface for unique-key maps.
* include/bits/stl_map.h (try_emplace, insert_or_assign): New.
* include/bits/stl_tree.h (_M_get_insert_unique_pos,
_M_get_insert_equal_pos
g (and
it's thus far unclear whether it was intended to work by the language
rules).
2015-07-25 Ville Voutilainen
PR libstdc++/60970, implement LWG 2148, hash support for
enum types.
* include/bits/functional_hash.h
(__hash_enum): New.
(hash): Derive from __hash_enum.
Fyi.
2015-07-29 Ville Voutilainen
* MAINTAINERS (Write After Approval): Add myself.
diff --git a/ChangeLog b/ChangeLog
index 4fcf016..bf49729 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,6 @@
+2015-07-29 Ville Voutilainen
+ * MAINTAINERS (Write After Approval): Add myself
On 29 July 2015 at 21:48, Marek Polacek wrote:
> On Wed, Jul 29, 2015 at 08:29:34PM +0300, Ville Voutilainen wrote:
>> Fyi.
>>
>> 2015-07-29 Ville Voutilainen
>> * MAINTAINERS (Write After Approval): Add myself.
>
> There should be a blank line between
On 29 July 2015 at 22:18, Ville Voutilainen wrote:
> On 29 July 2015 at 21:48, Marek Polacek wrote:
>> On Wed, Jul 29, 2015 at 08:29:34PM +0300, Ville Voutilainen wrote:
>>> Fyi.
>>>
>>> 2015-07-29 Ville Voutilainen
>>> * MAINTAINERS (W
This is the first stab, I haven't written the tests yet. Feedback would be
most welcome; should I put this code into a separate function? Is the minor
code duplication with the regular namespace definition ok?
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 3a68dd7..00f18fb 100644
--- a/gcc/cp
>>>+ else if (warn_multiple_inheritance)
>>>+warning (OPT_Wmultiple_inheritance,
>>>+ "%qT defined with multiple direct bases", ref);
>>You don't need to guard the warning with a check of the warning flag; warning
>>will only give the warning if the option is enabled.
>the spelling
On 17 September 2015 at 23:11, Jason Merrill wrote:
> On 09/16/2015 07:55 AM, Ville Voutilainen wrote:
>>
>> This is the first stab, I haven't written the tests yet. Feedback would be
>> most welcome; should I put this code into a separate function? Is the
>> mi
On 18 September 2015 at 01:23, Ville Voutilainen
wrote:
> Ok. Tested on Linux-PPC64. This patch doesn't handle attributes yet, it looks
> to
> me as if gcc doesn't support namespace attributes in the location that
> the standard
> grammar puts them into. I had to adjust
On 18 September 2015 at 02:02, Ville Voutilainen
wrote:
> Ahem, oops, the patch doesn't do any sort of a pedwarn for standard versions
> below cpp1z; I'll do a new patch taking that into account tomorrow. I don't
> think we have maybe_warn_cpp1z or anything like that?
On 18 September 2015 at 19:27, Jason Merrill wrote:
> On 09/17/2015 06:23 PM, Ville Voutilainen wrote:
>>
>> This patch doesn't handle attributes yet, it looks to
>> me as if gcc doesn't support namespace attributes in the location that
>> the standard gramm
On 18 September 2015 at 19:34, Jason Merrill wrote:
This patch doesn't handle attributes yet, it looks to
me as if gcc doesn't support namespace attributes in the location that
the standard grammar puts them into.
>>> Mind fixing that, too?
>> Can we please do that separately?
> I s
On 18 September 2015 at 20:26, Jason Merrill wrote:
>>> I suppose so, but it seems pretty trivial. In any case, looks like your
>>> patch would accept the odd
>>> namespace A __attribute ((visibility ("default"))) ::B { }
>> Yes, or namespace A[[nonsense]]::B {}. Those cases are easy to fix,
>> b
On 18 September 2015 at 20:30, Ville Voutilainen
wrote:
> On 18 September 2015 at 20:26, Jason Merrill wrote:
>>>> I suppose so, but it seems pretty trivial. In any case, looks like your
>>>> patch would accept the odd
>>>> namespace A __attribute ((visib
On 18 September 2015 at 20:38, Ville Voutilainen
wrote:
> On 18 September 2015 at 20:30, Ville Voutilainen
> wrote:
>> On 18 September 2015 at 20:26, Jason Merrill wrote:
>>>>> I suppose so, but it seems pretty trivial. In any case, looks like your
>&
On 18 September 2015 at 20:46, Ville Voutilainen
wrote:
> Argh, no. An attribute immediately following a nesting namespace would need
> to be parsed before the nested namespace definition handling is done,
> otherwise
> the nested namespace definition handling is never entered beca
Tested on Linux-PPC64.
/c-family
2015-09-20 Ville Voutilainen
Complete the implementation of N4230, Nested namespace definition.
* c-cppbuiltin.c: Add __cpp_namespace_attributes and
__cpp_nested_namespace_definitions.
/cp
2015-09-20 Ville Voutilainen
Complete the
On 21 September 2015 at 00:08, Ville Voutilainen
wrote:
> /cp
> 2015-09-20 Ville Voutilainen
>
> Complete the implementation of N4230, Nested namespace definition.
> * parser.c (cp_parser_namespace_definition): Support namespace
> attributes both before and a
Tested on Linux-PPC64, committed as obvious.
/cp
2015-09-23 Ville Voutilainen
Fix small typos in the coding rule enforcement warnings.
* parser.c (cp_parser_namespace_definition): Replace 'namepace'
with 'namespace'.
/testsuite
2015-09-23 Ville Voutilainen
Tested on Linux-PPC64.
2015-09-25 Ville Voutilainen
Avoid creating dangling references in case of nested tuples
for tuple constructors that construct from other tuples.
* include/std/tuple (_TC::_NonNestedTuple): New.
* include/std/tuple (tuple::_TNTC): New.
* include/std
Tested on Linux-PPC64.
/cp
2015-10-01 Ville Voutilainen
PR c++/54430
* name-lookup.c (push_binding): Make non-static.
* name-lookup.h (push_binding): Declare it.
* parser.c (cp_parser_range_for): Use it, get the range
declaration away from the scope until the range
the traits themselves, this is a straightforward fix,
for certain tuple-specific values of "straightforward". ;)
And hey, the problem and its solution were, once the bug
report came in, obvious to the resident tuple-hacker between
my chair and my keyboard. :)
2015-10-05 Ville V
Tested on Linux-PPC64.
/cp
2015-10-11 Ville Voutilainen
PR c++/58566
* lambda.c (lambda_return_type): Return error_mark_node
instead of void_type_node for the error cases.
/testsuite
2015-10-11 Ville Voutilainen
PR c++/58566
* g++.dg/cpp0x/lambda/lambda-58566.C: New.
On 11 October 2015 at 20:05, Ville Voutilainen
wrote:
> Tested on Linux-PPC64.
>
> /cp
> 2015-10-11 Ville Voutilainen
>
> PR c++/58566
> * lambda.c (lambda_return_type): Return error_mark_node
> instead of void_type_node for the error cases.
>
>
It seems to me that there's a discrepancy in handling explicit
default constructors. Based on my tests, this works:
struct X {explicit X() {}};
void f(X) {}
int main()
{
f({});
}
However, if the explicit constructor is defaulted, gcc accepts the code:
struct X {explicit X() = default;};
v
On 25 October 2015 at 22:15, Ville Voutilainen
wrote:
> It seems to me that there's a discrepancy in handling explicit
> default constructors. Based on my tests, this works:
>
> struct X {explicit X() {}};
>
> void f(X) {}
>
> int main()
> {
> f({}
Since N3994 ended up being rejected and was never included
in C++17, I want to remove the support for it. It's easy to bring
it back if such a facility is resurrected, but for now, let's remove
such an extension.
Tested on Linux-PPC64.
/cp
2015-10-31 Ville Voutilainen
quite some time, could you please review this patch?
Tested on Linux-PPC64.
2015-11-01 Ville Voutilainen
Make the default constructors of tuple and pair conditionally explicit.
* include/std/type_traits (
__do_is_implicitly_default_constructible
tested on Linux-PPC64. Minor typo fixes for the
changelog. Ok for trunk?
2015-11-01 Ville Voutilainen
Make the default constructors of tuple and pair conditionally explicit.
* include/std/type_traits (
__do_is_implicitly_default_constructible_impl,
__is_implicitly_de
nux-PPC64, tests adjusted due to line changes,
Changelog entry updated to have a correct date on it.
2015-11-02 Ville Voutilainen
Make the default constructors of tuple and pair conditionally explicit.
* include/std/type_traits (
__do_is_implicitly_default_construct
On 2 November 2015 at 23:07, Paolo Carlini wrote:
> Great, thanks a lot. Thinking more about this detail, I wonder if we should
> therefore apply the below too? Anything I'm missing?
Tested again on Linux-PPC64. Ok for trunk?
2015-11-03 Ville Voutilainen
Make the default cons
On 3 November 2015 at 16:42, Jonathan Wakely wrote:
> On 3 November 2015 at 02:37, Paolo Carlini wrote:
>> Hi,
>>
>> On 11/02/2015 09:20 PM, Ville Voutilainen wrote:
>>>
>>> On 2 November 2015 at 21:20, Paolo Carlini
>>> wrote:
>>>>
&
Tested on Linux-X64.
2015-11-10 Ville Voutilainen
LWG 2510, make the default constructors of library tag types
explicit.
* include/bits/mutex.h (defer_lock_t, try_lock_t,
adopt_lock_t): Add an explicit default constructor.
* include/bits/stl_pair.h (piecewise_construct_t
Tested on Linux-PPC64.
2015-11-11 Ville Voutilainen
Implement D0013R2, logical type traits.
/libstdc++-v3
* include/experimental/type_traits (conjunction_v, disjunction_v,
negation_v): New.
* include/std/type_traits (conjunction, disjunction, negation):
Likewise
On 12 November 2015 at 00:18, Jonathan Wakely wrote:
> So I think we want to define them again, independently, in
> , even though it might lead to ambiguities
Here. Tested again on Linux-PPC64.
2015-11-11 Ville Voutilainen
Implement D0013R2, logical type traits.
/libstd
On 12 November 2015 at 16:23, Gerald Pfeifer wrote:
> On Wed, 11 Nov 2015, Jonathan Wakely wrote:
>>
>> Fixed by this patch.
>
>
> Thanks, Jonathan! Unfortunately bootstrap is still broken
> (on i386-unknown-freebsd11.0 at least):
>
> In file included from
> /scratch/tmp/gerald/gcc-HEAD/libstdc++
>> On Sun, Nov 15, 2015 at 11:09:18PM +0100, Andreas Schwab wrote:
>>> Andi Kleen writes:
>>>
>>> > Fix the obivous typos. To to commit?
>>>
>>> They are not typos.
>>
>> Ok. What do you suggest to fix the error then?
>Someone will need to fix the regression introduced by the C++ delayed
>folding.
Tested on Linux-PPC64.
2015-12-11 Ville Voutilainen
PR libstdc++/68139
/libstdc++-v3
* libsupc++/nested_exception.h (_S_rethrow): Use __std::addressof.
/testsuite
* 18_support/nested_exception/68139.cc: New.
diff --git a/libstdc++-v3/libsupc++/nested_exception.h
b
On 11 December 2015 at 08:55, Marc Glisse wrote:
> On Fri, 11 Dec 2015, Ville Voutilainen wrote:
>
>> Tested on Linux-PPC64.
>>
>> 2015-12-11 Ville Voutilainen
>>
>>PR libstdc++/68139
>>
>>/libstdc++-v3
>>* libsupc++
On 11 December 2015 at 09:52, Marc Glisse wrote:
/libstdc++-v3
* libsupc++/nested_exception.h (_S_rethrow): Use __std::addressof.
>>> Typo.
>> I must be blind, but I don't see what you mean. :)
> Shouldn't the underscores apply to addressof, not to the namespace?
Hah! Yes, thanks
This shebang adds library tests for all cases of parenthesized aggregate
initialization that I could find. Tested locally on Linux-x64, going to
test with full suite on Linux-PPC64, OK for trunk if tests pass?
2020-02-23 Ville Voutilainen
Library-side tests for parenthesized aggregate
On Tue, 25 Feb 2020 at 15:36, Jonathan Wakely wrote:
> I think what I'd really like to do is get rid of __memmove entirely.
> We already have code that does the explicit assignment in a loop, for
> the cases where we can't use __builtin_memmove because the type is not
> trivially copyable.
>
> We
On Fri, 6 Mar 2020 at 10:41, Andreas Krebbel wrote:
>
> zTPF uses the same numeric value for ENOSYS and ENOTSUP.
>
> Ok for mainline?
>
> libstdc++-v3/ChangeLog:
>
> 2020-03-06 Andreas Krebbel
>
> * src/c++11/system_error.cc: Omit the ENOTSUP case statement if it
> would match E
On Fri, 6 Mar 2020 at 11:52, Andreas Krebbel wrote:
> > Hmm, what system does not have ENOSYS but has ENOTSUP? Meaning the
> > !defined ENOSYS
> > bit?
> >
> None that I know about. It is just to make sure the compare afterwards
> operates on defined inputs.
Ah, I see, indeed. This dance is don
On Fri, 15 Nov 2019 at 22:16, Smith-Rowland, Edward M
wrote:
>
> Pretty self-explanatory.
LGTM. Jonathan still needs to ack it.
On Sun, 17 Nov 2019 at 23:15, François Dumont wrote:
>
> H1 used to be a reference to the user Hash, now _Hashtable and unordered
> types agree on the same Hash type which is more intuitive.
>
> I also chose to not support anymore a stateful ranged hash functor. We
> only use _Mod_range_hashing an
On Mon, 18 Nov 2019 at 23:41, François Dumont wrote:
> > Also, is
> > this ABI-compatible
> > for our unordered containers?
> >
> IMHO, yes it is.
>
> In hashtable_policy.h _H1 was the user hash which I renamed in _Hash,
> the same template name that for unordered containers.
>
> _H2 was always
On Wed, 20 Nov 2019 at 11:47, Christophe Lyon
wrote:
>
> On Thu, 14 Nov 2019 at 16:55, Jonathan Wakely wrote:
> >
> > On 09/11/19 02:07 +, Smith-Rowland, Edward M wrote:
> > >Here is the part of C++20 p1032 Misc constexpr bits.
> > >
> > >Tested on x86_64-linux. OK?
> >
> > OK for trunk, tha
On Wed, 20 Nov 2019 at 12:16, Christophe Lyon
wrote:
>
> On Wed, 20 Nov 2019 at 11:10, Ville Voutilainen
> wrote:
> >
> > On Wed, 20 Nov 2019 at 11:47, Christophe Lyon
> > wrote:
> > >
> > > On Thu, 14 Nov 2019 at 16:55, Jonathan Wakely wrote:
&
On 8 July 2018 at 02:08, Ville Voutilainen wrote:
> On 8 July 2018 at 01:54, Paolo Carlini wrote:
>>> That would make this more consistent with such a shadow warning, but I
>>> don't want
>>> to use the shadowing wording (which would be easy to do; just se
On 7 August 2018 at 13:12, Jason Merrill wrote:
> Maybe put this block first rather than add !is_capture_proxy to the if
> condition?
Thus?
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 3aafb0f..0faf739 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -2640,13 +264
On 7 August 2018 at 14:50, Jason Merrill wrote:
> OK.
Trunk only, no backports, presumably. I asked about backports in the
second-to-last submission, but I am gravitating
away from backporting this, it's a non-regression that's dealing with
a fairly recent change, so I'm going to operate
with a t
On 7 August 2018 at 17:29, Jonathan Wakely wrote:
> On 07/08/18 15:24 +0100, Jonathan Wakely wrote:
>>
>> This patch fixes the bug, but is it correct?
>>
>> IIUC the _M_destructive_move effects don't depend on whether move
>> assignment is trivial, so should be defined the same way in both
>> spec
On 10 August 2018 at 13:47, Jonathan Wakely wrote:
> Doing a test like this with TSan should be the absolute minimum
> required for any change to the mutex locking policy.
Agreed. Concurrency code is something that our test suite is not
well-equipped to test (because
it doesn't support TSan and s
On 14 August 2018 at 23:34, Jonathan Wakely wrote:
> This was deprecated in C++17, and has been removed from the current
> draft. This adds the dprecated attribute for C++17 and later.
>
> We can't actually remove it for C++2a because we use it (indirectly)
> in stl_algo.h. We could rename it to _
On 17 August 2018 at 22:29, Jonathan Wakely wrote:
> That was added by https://gcc.gnu.org/ml/libstdc++/2016-12/msg00122.html
> but I see no justification for that in the standard (and neither
> libc++ nor MSFTL does anything special here, so they fail the test
> too).
>
> Ville, I'm no longer con
On 17 August 2018 at 22:46, Ville Voutilainen
wrote:
>>
>> If we think the test is right, we should report a defect. Either way,
>> I think this patch would be a nice simplification. We can either fix
>> (or just remove) the test, or constrain the primary template.
On 21 August 2018 at 12:17, Jonathan Wakely wrote:
> I think this is slightly simpler and easier to maintain, but I'd like
> to hear other views, especially from Ville who added most of these
> constraints and does most of the work to maintain std::tuple.
+1, OK.
On 2 September 2018 at 23:03, Jonathan Wakely wrote:
> On 01/09/18 21:56 +0200, Marc Glisse wrote:
>>
>> On Sat, 1 Sep 2018, Marc Glisse wrote:
>>
>>> this patch passed bootstrap+regtest on powerpc64le-unknown-linux-gnu.
>>
>>
>> I realized afterwards that for a C++17-only feature, that's not test
Tested on Linux-x64.
2017-06-10 Ville Voutilainen
PR libstdc++/80675
PR libstdc++/80940
* include/std/istream:
(__is_convertible_to_basic_istream_test(basic_istream<_Ch, _Up>*)): New.
(__do_is_convertible_to_basic_istream_impl): Li
Tested manually on Linux-X64, finishing testing with the full suite on
Linux-PPC64.
I spent far too much time contemplating whether to add a compatibility switch
for this, but -fcheck-new *is* such a compatibility switch.
OK for trunk?
2017-11-10 Ville Voutilainen
gcc/
Remove the
On 10 November 2017 at 18:19, Jason Merrill wrote:
> OK.
I see non-obvious testsuite failures, I'll see if adding -fcheck-new
to those cases
cures the problem. Please stay tuned. :)
On 10 November 2017 at 18:55, Ville Voutilainen
wrote:
> On 10 November 2017 at 18:19, Jason Merrill wrote:
>> OK.
>
>
> I see non-obvious testsuite failures, I'll see if adding -fcheck-new
> to those cases
> cures the problem. Please stay tuned. :)
Here. Tested
On 13 November 2017 at 14:17, Eric Botcazou wrote:
>> 2017-11-13 Ville Voutilainen
>>
>> gcc/
>>
>> Remove the null check from placement new in all modes
>> * cp/init.c (build_new_1): Don't do a null check for
>> a namespace-sc
Tested on Linux-x64.
2017-11-14 Ville Voutilainen
Implement LWG 2733 and LWG 2759
* include/experimental/numeric (gcd): Reject cv-qualified bool.
(lcm): Likewise.
* include/std/numeric (gcd): Likewise.
(lcm): Likewise.
* testsuite/26_numerics/gcd/gcd_neg.cc: Add tests
On 14 November 2017 at 19:06, Jonathan Wakely wrote:
> Both files can use remove_cv_t instead of remove_cv::type (and there's
> no need to std-qualify it in std::gcd).
>
> They could also use is_integral_v and is_same_v but that's
> pre-existing, and less important because there's no 'typename' th
or of an istream.
Testing on Linux-PPC64, ok for trunk if the full suite passes?
2017-11-19 Ville Voutilainen
Implement LWG 2353
* include/bits/stl_iterator_base_funcs.h (next):
Use InputIterator instead of ForwardIterator.
* testsuite/24_iterators/operations/lwg2353.cc
On 19 November 2017 at 02:40, Ville Voutilainen
wrote:
> The issue submission talks about ranges that have InputIterators
> as their iterator type. Even without any such range types, the added
> test more or less shows that it's draconian to require a ForwardIterator
> in st
Tested on Linux-x64.
2017-11-14 Ville Voutilainen
Implement LWG 2221
* include/std/ostream (operator<<(nullptr_t)): New.
* testsuite/27_io/basic_ostream/inserters_other/char/lwg2221.cc: New.
diff --git a/libstdc++-v3/include/std/ostream b/libstdc++-v3/include/std/ostream
?
2017-12-16 Ville Voutilainen
PR libstdc++/68430
* testsuite/20_util/is_constructible/68430.cc: New.
diff --git a/libstdc++-v3/testsuite/20_util/is_constructible/68430.cc
b/libstdc++-v3/testsuite/20_util/is_constructible/68430.cc
new file mode 100644
index 000..3f880b3
--- /dev
ry, and he spoke
"this will not stand".
Tested on Linux-PPC64. The change is an ABI break due to changing
optional to a trivially copyable type. It's perhaps
better to get that ABI break in now rather than later.
So here you go (ho ho ho):
2017-12-25 Ville Voutilainen
Ma
Tested partially on Linux-x64, finishing testing the full suite on
Linux-PPC64. Ok for trunk?
2018-01-03 Ville Voutilainen
Protect optional's deduction guide with the feature macro
* include/std/optional: Use the feature macro.
diff --git a/libstdc++-v3/include/std/optional
b/li
On 25 May 2018 at 20:27, Jason Merrill wrote:
> On Thu, May 24, 2018 at 8:04 PM, Ville Voutilainen
> wrote:
>> I smacked my head against conversion_null_warnings for a while,
>> and then I realized that we could just stop convert_like_real from
>> changing the node type
On 25 May 2018 at 20:38, Ville Voutilainen wrote:
> On 25 May 2018 at 20:27, Jason Merrill wrote:
>> On Thu, May 24, 2018 at 8:04 PM, Ville Voutilainen
>> wrote:
>>> I smacked my head against conversion_null_warnings for a while,
>>> and then I realized that we
On 25 May 2018 at 19:50, François Dumont wrote:
> Hi
>
> As we are at working on associative containers I'd like to propose this last
> patch to remove the copy constructible constraint on the _Compare functor
> when it is supposed to be default constructed.
>
> This way the _Compare is built dire
On 25 May 2018 at 22:16, Jonathan Wakely wrote:
>> Why is this patch removing _Compare() calls? That changes the
>> initialization
>> of _Compare from value-initialization to default-initialization, which
>> is a breaking change.
>
>
> The _Rb_tree_key_compare base class will still value-initializ
1 - 100 of 624 matches
Mail list logo
