.
Tested manually on Linux-x64, running full suite on Linux-PPC64. Ok for trunk?
2018-05-29 Ville Voutilainen
gcc/cp/
Do not warn about zero-as-null when NULL is used.
* typeck.c (cp_build_binary_op): Diagnose zero as null here..
* call.c (conversion_null_warnings): ..and here
On 30 May 2018 at 01:23, Jason Merrill wrote:
> On Tue, May 29, 2018 at 4:44 PM, Marek Polacek wrote:
>> [expr.prim.lambda.capture] p8 says "If a lambda-expression explicitly
>> captures
>> an entity that is not odr-usable or captures a structured binding (explicitly
>> or implicitly), the progr
On 29 May 2018 at 23:43, Ville Voutilainen wrote:
> Another round. The other occurrence of
> maybe_warn_zero_as_null_pointer_constant
> in typeck.c seems superfluous. The one in cvt.c seems necessary for
> cpp0x/Wzero-as-null* tests. It seems like cp_build_binary_op is far more
&
or trunk if the tests
pass?
2018-05-30 Ville Voutilainen
gcc/cp/
Do not warn about zero-as-null when NULL is used.
* typeck.c (cp_build_binary_op): Diagnose zero as null here..
* call.c (conversion_null_warnings): ..and here..
* cvt.c (cp_convert_to_pointer): ..not here.
On 30 May 2018 at 18:32, Ville Voutilainen wrote:
> Now it does. This passes all the Wzero-as-null-pointer-constant tests in warn/
> and cpp0x/, running full suite on Linux-PPC64. Ok for trunk if the tests
> pass?
Here we go again. :)
2018-05-30 Ville Voutilainen
gcc/cp/
On 14 June 2018 at 19:51, Jonathan Wakely wrote:
> On 14/06/18 10:46 -0600, Martin Sebor wrote:
>>
>> On 06/13/2018 10:30 AM, Jonathan Wakely wrote:
>>>
>>> The C++ committee has confirmed that passing a null pointer to the
>>> unary basic_string_view constructor is undefined. This removes the che
On 14 June 2018 at 19:57, Jonathan Wakely wrote:
>> [macro.names]/2 forbids #defining macros with the same names as the
>> standard attributes.
>> The programs Martin shows as examples are not valid.
>
>
> But nonnull isn't a standard attribute though. So we can't use
> [[gnu::xxx]] attributes in
On 14 June 2018 at 20:08, Jonathan Wakely wrote:
>> Oops, indeed. But for gnu-attributes, surely we can decide whatever we
>> want about what's
>> valid and what's not?
>
>
> We could say that #defining 'nonnull' and/or 'gnu' as a macro is
> undefined, but then programs that the standard says are
On 14 June 2018 at 20:21, Ville Voutilainen wrote:
> On 14 June 2018 at 20:08, Jonathan Wakely wrote:
>>> Oops, indeed. But for gnu-attributes, surely we can decide whatever we
>>> want about what's
>>> valid and what's not?
>>
>>
>> We
On 14 June 2018 at 20:40, Jonathan Wakely wrote:
>> Namely "For an attribute-token (including an attribute-scoped-token)
>> not specified in this document, the behavior is
>> implementation-defined.", aka [dcl.attr.grammar]/6.
>
>
> As I said on IRC, if the user does
>
> #define gnu R"(
> ,= ,-_-.
On 17 June 2018 at 19:49, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> On 06/15/2018 11:52 AM, Jonathan Wakely wrote:
>>
>> C++20 adds a header, which should define all the library
>> feature test macros, as well as implementation-specific macros like
>> _GLIBCXX_RELEASE and __GLIBCXX__.
>>
>> W
On 16 June 2018 at 18:05, Marc Glisse wrote:
> On Sat, 16 Jun 2018, Glen Fernandes wrote:
>
>> Use __builtin_memmove for trivially copy assignable types
>>
>> 2018-06-14 Glen Joseph Fernandes
>>
>>* include/bits/stl_algobase.h
>>(__is_simple_copy_move): Defined helper.
>>
On 8 January 2018 at 15:36, Jonathan Wakely wrote:
> On 25/12/17 23:59 +0200, Ville Voutilainen wrote:
>>
>> In the midst of the holiday season, the king and ruler of all elves,
>> otherwise
>> known as The Elf, was told by little elves that users are complaining ho
Finishing testing the attached, OK for trunk?
2018-01-21 Ville Voutilainen
PR c++/83895
cp/
* decl.c (grokdeclarator): Don't diagnose extra parens
on typedefs.
testsuite/
* g++.dg/warn/83895.C: New.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 039ddd9..23
Tested partially on Linux-x64, will test with the full suite on Linux-PPC64.
Ok for trunk and the gcc-7 branch? This is theoretically a breaking change
for the branch, but the committee has decided that they don't want
the support for copyable-but-not-movable types.
2018-02-25 Ville Voutil
On 26 February 2018 at 22:52, Jonathan Wakely wrote:
> But those are just stylistic issues, the technical side of the patch
> is fine. I had to look up why we had two overloads for any_cast(any&&)
> and that seems to be a leftover from experimental::any, so thanks for
> cleaning that up too.
It
On 26 February 2018 at 22:52, Jonathan Wakely wrote:
> On 25/02/18 23:22 +0200, Ville Voutilainen wrote:
>>
>> Tested partially on Linux-x64, will test with the full suite on
>> Linux-PPC64.
>> Ok for trunk and the gcc-7 branch? This is theoretically a breaking chan
Partially tested on Linux-x64, will run full suite on Linux-PPC64.
2018-02-28 Ville Voutilainen
PR libstdc++/84601
* include/std/optional (_Optional_payload): Split into multiple
specializations that can handle different cases of trivial or
non-trivial assignment operators
On 28 February 2018 at 14:27, Ville Voutilainen
wrote:
> Partially tested on Linux-x64, will run full suite on Linux-PPC64.
Which didn't reveal anything I didn't know, but reminded me to adjust
the negative tests. :)
2018-02-28 Ville Voutilainen
PR libstdc++/84601
Tested on Linux-PPC64.
2018-03-22 Ville Voutilainen
gcc/cp/
Implement P0962
* parser.c (cp_parser_perform_range_for_lookup): Change
the condition for deciding whether to use members.
testsuite/
Implement P0962
* g++.dg/cpp0x/range-for13.C: Adjust.
diff --git a
Finishing testing with the full suite on Linux-PPC64, tested partially
on Linux-x64.
2018-04-03 Ville Voutilainen
gcc/cp
PR c++/65923
* parser.c (cp_parser_unqualified_id): Add a new parameter
and check it for the literal diagnostic.
(cp_parser_using_declaration): Adjust
On 3 April 2018 at 17:19, Ville Voutilainen wrote:
> * parser.c (cp_parser_unqualified_id): Add a new parameter
> and check it for the literal diagnostic.
As discussed on irc, we can indeed do better. With this approach, we
look at function declarations
only, so using-declaratio
Tested on Linux-PPC64.
2018-04-05 Ville Voutilainen
gcc/cp
Implement P0961
* decl.c (get_tuple_decomp_init): Check the templatedness
of a member get.
testsuite/
Implement P0961
* g++.dg/cpp1z/decomp10.C: Adjust.
* g++.dg/cpp1z/decomp37.C: New.
diff --git a
Tested on Linux-PPC64.
2018-04-05 Ville Voutilainen
gcc/cp
Implement P0969
* decl.c (find_decomp_class_base): Check accessibility instead
of declared access, adjust diagnostic.
testsuite/
Implement P0969
* g++.dg/cpp1z/decomp4.C: Adjust.
* g++.dg/cpp1z
On 5 April 2018 at 16:37, Jason Merrill wrote:
> On Wed, Apr 4, 2018 at 6:26 PM, Ville Voutilainen
> wrote:
>> + tree parm = TREE_VEC_ELT (TREE_VALUE (tparms), 0);
>
> I think you want to use INNERMOST_TEMPLATE_PARMS here rather than
> TREE_VALUE directly.
>
> Please
On 10 April 2018 at 17:10, Jakub Jelinek wrote:
> Hi!
>
> The "Implement P0962" change changed the
> if (member_begin != NULL_TREE || member_end != NULL_TREE)
> condition to
> if (member_begin != NULL_TREE && member_end != NULL_TREE)
> but that created a lot of dead-code, because now the diagnosti
Tested manually on Linux-x64, running full suite on Linux-PPC64. This
seems half-obvious. OK for trunk? Backports?
2018-09-10 Ville Voutilainen
gcc/cp
PR c++/87093
* method.c (constructible_expr): We're in an unevaluated context
in all cases, not just for class ta
Linux-x64, running full suite
on Linux-PPC64.
Thoughts? OK for trunk if the full suite passes?
2018-09-13 Ville Voutilainen
gcc/cp
PR c++/87051
* decl.c (grok_special_member_properties): Don't mark the class
as having a non-trivial copy constructor if the copy constructor
On 13 September 2018 at 10:38, Ville Voutilainen
wrote:
> Howdy! The tricky details of copy constructors, part 76.
> In this approach, I let the const-copy "dominate"; that is, if
> a const-copy was found, a non-const-copy will not turn off triviality
> of the copy constru
On 13 September 2018 at 12:08, Ville Voutilainen
wrote:
> Curses.. the resetting is over-eager; we might have a non-trivial base
> or a member, and in those cases we shouldn't
> reset the triviality when we see a non-user-provided const copy. I
> think I'll hack around thi
On 13 September 2018 at 13:03, Jakub Jelinek wrote:
> On Thu, Sep 13, 2018 at 12:56:59PM +0300, Ville Voutilainen wrote:
>> + else if (!TYPE_HAS_CONST_COPY_CTOR (class_type))
>> + TYPE_HAS_COMPLEX_COPY_CTOR (class_type) += 2;
>> + }
>>
On 13 September 2018 at 13:41, Ville Voutilainen
wrote:
>> How does this work when:
>> unsigned has_complex_copy_ctor : 1;
> It doesn't. I need more bits. Luckily, we have some available.
Here. I suppose this could theoretically be done in some later stage
of class comple
On 13 September 2018 at 19:36, Jason Merrill wrote:
> On Thu, Sep 13, 2018 at 9:41 AM, Ville Voutilainen
> wrote:
>> On 13 September 2018 at 13:41, Ville Voutilainen
>> wrote:
>>>> How does this work when:
>>>> unsigned has_complex_copy_ctor : 1;
>
On 13 September 2018 at 20:41, Jason Merrill wrote:
>> Okay. Do you think we should have an sfk_kind for non-canonical
>> copy/move operations? That would presumably make it a tad more
>> straightforward to go from
>> fndecl to whatever class bits, instead of what's currently there, where we
>>
On Mon, 17 Sep 2018 at 21:50, Jonathan Wakely wrote:
>"I used C++11 syntax because I find it nicer, and the compiler accepts
> >it in C++98 mode with just a warning, suppressed in a standard
> >header."
>
> Oh sorry, I just looked at the patch and replied without reading the
> top bit.
>
> >Even
On 1 May 2018 at 22:56, François Dumont wrote:
> Hi
>
> If not told otherwise I'll commit attached patch tomorrow.
Commit it where? The 8.1 release is not out yet, so we shouldn't be
pushing new stuff onto trunk yet.
Nor should we push such stuff into the release branch.
On 2 May 2018 at 00:28, Jakub Jelinek wrote:
> On Wed, May 02, 2018 at 12:23:27AM +0300, Ville Voutilainen wrote:
>> On 1 May 2018 at 22:56, François Dumont wrote:
>> > Hi
>> >
>> > If not told otherwise I'll commit attached patch tomorrow.
>>
&g
This just adds a missing test. The bug was in variant, not tuple,
so I added the test under variant. Ok for trunk (this is not going
to be backported)?
2018-05-12 Ville Voutilainen
PR libstdc++/80165
* testsuite/20_util/variant/80165.cc: New.
diff --git a/libstdc++-v3/testsuite
On 18 May 2018 at 19:13, Jonathan Wakely wrote:
> In C++11 and C++14 any odr-use of these constants requires a definition
> at namespace-scope. In C++17 they are implicitly inline and so the
> namespace-scope redeclarations are redundant (and allowing them is
> deprecated).
>
> PR libstdc
Tested manually on Linux-x64, finishing testing with the full suite
on Linux-PPC64. Ok for trunk?
2018-05-24 Ville Voutilainen
gcc/cp/
Pedwarn on a non-standard position of a C++ attribute.
* parser.c (cp_parser_namespace_definition): Pedwarn about attributes
after the
On 24 May 2018 at 19:57, Nathan Sidwell wrote:
> On 05/24/2018 10:48 AM, Ville Voutilainen wrote:
>>
>> Tested manually on Linux-x64, finishing testing with the full suite
>> on Linux-PPC64. Ok for trunk?
>>
>> 2018-05-24 Ville Voutilainen
>>
>
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 for null_node.
Tested manually on Linux-x64, running full suite on Linux-PPC64,
ok for trunk?
2018-05-25 Ville Voutilainen
gcc/cp
We shouldn't allow friend declarations and member templates to
have virt-specifiers, as neither of those can be virtual. Tested on
Linux x86-64.
Note that the standardese can be squinted at in a way that would allow
virt-specifiers on friends, there's a DR coming for that. I do not expect
the resol
On 12 August 2014 11:47, Ville Voutilainen wrote:
> We shouldn't allow friend declarations and member templates to
> have virt-specifiers, as neither of those can be virtual. Tested on
> Linux x86-64.
> Note that the standardese can be squinted at in a way that would allow
>
We didn't allow deleted friend definitions, because that was diagnosed
in grokdeclarator, which doesn't have knowledge of the kind of a function
declaration "initializer". Move the test to grokfield and adjust where
necessary. Tested on Linux x86-64.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index
On 14 August 2014 03:41, Jason Merrill wrote:
> On 08/13/2014 07:06 PM, Ville Voutilainen wrote:
>
> Looks good, but
>
>> + int friendp = 0;
>
>
> Let's declare friendp when it's initialized.
>
> And I still need a ChangeLog entry.
Ok, modified patch
Based on my quick tests with it, it seems to me that we need more
tests for static member variable templates. My first attempt at something
like that gave an ICE...
On 25 August 2014 05:54, Jason Merrill wrote:
> On 08/23/2014 06:29 PM, Ville Voutilainen wrote:
>>
>> Based on my quick tests with it, it seems to me that we need more
>> tests for static member variable templates. My first attempt at something
>> like that gave an I
On Mon Aug 25 2014 15:47:26 GMT+0300 (EEST), Jason Merrill wrote:
> On 08/25/2014 05:24 AM, Ville Voutilainen wrote:
> > Well, it's a bit premature to add tests when the implementation itself is
> > not
> > quite complete, I guess. :) Having ICEs makes it hard to a
On 25 August 2014 17:08, wrote:
>> Anyway, here's a fix for your recent test.
>
> Thanks, I'll take a look at the tests and will send a patch if something
> seems missing; static member variable templates of a class template and
> explicit specializations thereof are the likely starting point.
Tested on Linux-X64.
Massive thanks to Jason for doing the heavy lifting on the front-end side.
2014-10-08 Ville Voutilainen
PR libstdc++/60132
* include/std/type_traits (is_trivially_copyable,
is_trivially_constructible, is_trivially_default_constructible
c
@@ -0,0 +1,31 @@
+// { dg-options "-std=c++11" }
+// { dg-do compile }
+//
+// 2014-10-08 Ville Voutilainen
+//
+// Copyright (C) 2014 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or mod
Tested on Linux-x64. The {raw,}invocable_type trait and its variable templates
are not implemented yet.
2014-10-16 Ville Voutilainen
Implement the Library Fundamentals v1 variable templates for
type traits.
* include/Makefile.am: Add the new header.
* include/experimental
On 16 October 2014 22:25, Ville Voutilainen wrote:
> Tested on Linux-x64. The {raw,}invocable_type trait and its variable templates
> are not implemented yet.
>
>
> 2014-10-16 Ville Voutilainen
>
> Implement the Library Fundamentals v1 variable templates
Tested on Linux-x64.
2014-10-18 Ville Voutilainen
Implement more Library Fundamentals v1 variable templates for
type traits.
* include/Makefile.am: Add ratio, chrono and system_error.
* include/experimental/chrono: New.
* include/experimental/ratio: Likewise.
* include
On 18 October 2014 23:18, Ville Voutilainen wrote:
> Tested on Linux-x64.
>
> 2014-10-18 Ville Voutilainen
>
> Implement more Library Fundamentals v1 variable templates for
> type traits.
> * include/Makefile.am: Add ratio, chrono and system_error.
>
On 20 October 2014 15:38, Jonathan Wakely wrote:
> The templates should also use 'typename' not 'class' but I can make
> that change before committing it so no need for a new patch.
No, no, no! Contributors must be punished, otherwise they will never learn! ;)
Revised patch attached.
diff --git
Tested on Linux X86-64. Note that I have not bootstrapped this patch.
diff --git a/gcc/cp/search.c b/gcc/cp/search.c
index c3eed90..6907533 100644
--- a/gcc/cp/search.c
+++ b/gcc/cp/search.c
@@ -917,9 +917,10 @@ accessible_p (tree type, tree decl, bool consider_local_p)
/* Figure out where t
DR1206 allows explicit specializations of member enumerations
of class templates, so just remove the pedwarn about it.
Tested on Linux-x64. Not bootstrapped.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index d267a5c..97eadeb 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -967,11 +967,8 @@ maybe_process_
On 13 June 2014 01:37, Ville Voutilainen wrote:
> DR1206 allows explicit specializations of member enumerations
> of class templates, so just remove the pedwarn about it.
>
> Tested on Linux-x64. Not bootstrapped.
Argh, also remove the old comment, new patch attached.
diff --git a/g
On 13 June 2014 19:56, Jason Merrill wrote:
> This needs a test that we complain about a specialization of an unscoped
> enum. Perhaps just the test from 14.7p6??
Well, a specialization of an unscoped enum with the proper underlying type
is fine, and that example has ones that have the wrong un
On 13 June 2014 21:33, Jason Merrill wrote:
> On 06/13/2014 02:05 PM, Ville Voutilainen wrote:
>>
>> that example has ones that have the wrong underlying type.
>
>
> Good point. That was fixed after the DR was incorporated into the WP, which
> now says
>
>
&
On 15 June 2014 16:37, Jason Merrill wrote:
> Yes, but if there is a template definition for the enum available when the
> specialization is declared, the enum template is implicitly instantiated
> along with its containing class, so the specialization is ill-formed because
> you can't define a sp
nt,
I suggest we look at that separately. The constraints involve fair amounts
of evil black magic, but they do the job. Chances are they can be simplified,
but I again suggest we look at that separately.
Tested on Linux-PPC64.
Patch gzipped since it's 50kB otherwise. :)
2015-06-07 Ville V
On 7 June 2015 at 09:53, Marc Glisse wrote:
> Since the paper does not mention looking at _MoveConstructibleTuple or
> _ImplicitlyMoveConvertibleTuple here, could you add a comment explaining
> why that is needed?
Sure.
> Does the following code still compile with your patch?
> struct A { int a,
On 7 June 2015 at 11:12, Ville Voutilainen wrote:
>> Does the following code still compile with your patch?
>> struct A { int a,b; };
>> std::tuple a(3,4,{1,2});
>
> No. :/ And we have no test for it.. I'll need to look at that.
Ahem, yes, this is because the
On 7 June 2015 at 11:33, Ville Voutilainen wrote:
>>> You use a lot: typename enable_if::type=true
>>> while the current code seems to favor: class=typename enable_if::type.
>>> I don't really care which one is used, but it is easier to read when the
>>>
On 28 December 2014 at 20:21, Ville Voutilainen
wrote:
> Any comments on this?
Re-ping. :) The original message is
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01614.html
>
> On 19 December 2014 at 09:21, Ville Voutilainen
> wrote:
>> Tested on Linux-x64.
>>
>
, but only enables the parts that work in pre-c++14 modes.
- this patch does _not_ yet implement N4426.
Tested on Linux-x64.
2015-05-01 Ville Voutilainen
Add __is_nothrow_swappable and take it into use.
* libstdc++-v3/include/bits/algorithmfwd.h: Add constraints to the
forward-declar
On 1 May 2015 at 12:47, Ville Voutilainen wrote:
> This patch partially solves the problem described in N4426, which is
> basically LWG
> issue 2456, which in turn is caused by CWG DR 1330. Some remarks:
..and I forgot to mention that it fixes PR 63860.
Tested on Linux-x64.
2015-05-01 Ville Voutilainen
Implement observer_ptr.
* include/Makefile.am: Add new exported header.
* include/Makefile.in: Regenerate.
* include/experimental/memory: New.
* testsuite/experimental/memory/observer_ptr/assignment/assign.cc: Likewise
I didn't make the change conditional for C++14 or any other version. Volatile
scalars weren't memcpyable anyway, so I thought that this should just
apply to all standard versions we support. Tested on Linux-x64.
/cp
2014-11-20 Ville Voutilainen
PR c++/63959
Tested on Linux-x64. Remotely related to pr50645, which we should
probably close as invalid.
/cp
2014-11-26 Ville Voutilainen
Diagnose string constant conversion to char* in c++11 and above
as forbidden, not deprecated.
* typeck.c (string_conv_p): Do a pedwarn in c++11 and above
fully didn't look at the further tests.
>> to use the toplevel make-c++ target.
>
>
> Er, check-c++.
Yeah, I ran check-gcc-c++, but conveniently didn't look at the results
thoroughly
enough. New patch attached, tested until the very end including old-deja,
no regression
On 6 March 2015 at 23:58, Jason Merrill wrote:
> On 01/19/2015 11:28 AM, Ville Voutilainen wrote:
>>
>> * class.c (check_field_decls): If any field is volatile, make
>> the class type have complex copy/move operations.
>
>
> Discussion on the cxx-abi list p
The patch is a bit large since it does the baseline_symbols regeneration
and other new-version api-dance.
Hence attached gzipped.
Tested on Linux x86-64.
2015-04-13 Ville Voutilainen
Add support for std::uncaught_exceptions.
* acinclude.m4: Bump libtool_VERSION.
* config/abi/post
On 8 June 2015 at 18:37, Martin Sebor wrote:
> In the hunk below, should the sizes_match template parameter
> be privatized (since it isn't part of the public interface)?
> Or perhaps even removed if it's not used?
Yes, it should be uglified, thanks.
On 8 June 2015 at 18:53, Ville Voutilainen wrote:
> On 8 June 2015 at 18:37, Martin Sebor wrote:
>> In the hunk below, should the sizes_match template parameter
>> be privatized (since it isn't part of the public interface)?
>> Or perhaps even removed if it's
On 8 June 2015 at 19:01, Ville Voutilainen wrote:
>> Yes, it should be uglified, thanks.
> Ahem, yes, actually removed since it's there only to be specialized.
Another round! The new patch
- makes sure not to change non-deduced parameters to deduced ones, and adds
tests for that.
Tested on Linux-PPC64. Patch gzipped to avoid polluting people's
mailboxes with a 45k patch.
2015-07-03 Ville Voutilainen
Implement std::experimental::fundamentals_v2::propagate_const.
* include/Makefile.am: Add propagate_const.
* include/Makefile.in: Add propagate_
Duration, complex, char_traits and the random engines are already
properly constexprified in the library implementation.
I haven't built the manual with these changes. :) Also, I don't know
how doc patches
are usually submitted, so please be gentle. :P
2015-01-16 Ville Voutilainen
y, if there are some funny line-number
changes that need to be done elsewhere in the testsuite, I will
know in a couple of hours which quantifies to tomorrow morning,
since I won't stay up for it. ;)
2015-01-19 Ville Voutilainen
PR libstdc++/64656
* include/bits/range_access.h (cb
On 19 January 2015 at 00:11, Ville Voutilainen
wrote:
> This patch implements the free functions std::cbegin, std::cend,
> std::rbegin, std::rend, std::crbegin and std::crend, which were
> missing from our C++14 iterator library. I have run the added test
> manually but I haven't
leted testing this yet, I still need to run the full testsuite
to make sure there are no regressions. I'm not sure whether this
can go into gcc5, since we're at stage 4.
/cp
2015-01-19 Ville Voutilainen
PR c++/63959
* class.c (check_field_decls): If any field is volatile, make
On 19 January 2015 at 18:28, Ville Voutilainen
wrote:
> When I patched the triviality test for volatile types, I missed two cases:
> 1) volatile members in a class should make the class non-trivial.
> 2) a volatile class type should itself be non-trivial.
> (based on [basic.types]/
On 19 January 2015 at 21:12, Ville Voutilainen
wrote:
> On 19 January 2015 at 18:28, Ville Voutilainen
> wrote:
>> When I patched the triviality test for volatile types, I missed two cases:
>> 1) volatile members in a class should make the class non-trivial.
>> 2) a vo
On 20 January 2015 at 15:06, Jason Merrill wrote:
> On 01/19/2015 06:06 PM, Ville Voutilainen wrote:
>>
>> + return (trivial_type_p (type1)
>> + || (scalarish_type_p (type1) && CP_TYPE_VOLATILE_P (type1))
>> +
On 30 January 2015 at 19:46, Jason Merrill wrote:
> On 01/20/2015 09:27 AM, Ville Voutilainen wrote:
>>
>> +#define YES2(type) TRY(std::is_trivial::value); \
>> + TRY(std::is_trivial::value); \
>> TRY(std::is_trivial::value)
>
>
>> +YES2(void *);
&
On 30 January 2015 at 20:25, Jason Merrill wrote:
> On 01/30/2015 01:13 PM, Ville Voutilainen wrote:
>>>
>>> Why would void *const volatile still be trivial?
>>
>>
>> Ah. It isn't. YES and YES2 are macros, so YES2(void*) expands to
On 30 January 2015 at 21:59, Ville Voutilainen
wrote:
> So, a new patch attached. The only change to the previous one is the change
> to the trivial1.C test.
Oops. The No-template was borken and there was remnants of the macros
in commented
code. Let's try that again, shall we? :) Att
Let's drop libstdc++, this discussion is about a test that doesn't
really concern them.
On 30 January 2015 at 22:51, Jason Merrill wrote:
> The patch changes all the static_assert strings to "", which is not very
> useful; let's keep the macro.
Ok. How about this one? It reuses the macro and ke
On 30 January 2015 at 23:06, Ville Voutilainen
wrote:
> Let's drop libstdc++, this discussion is about a test that doesn't
> really concern them.
>
> On 30 January 2015 at 22:51, Jason Merrill wrote:
>> The patch changes all the static_assert strings to "&quo
The modified test has been tested, I'm currently running the full testsuite,
so testing is incomplete. I wanted to send this in asap, since this is a
bad regression.
/cp
2015-02-02 Ville Voutilainen
PR c++/64901
* decl.c (duplicate_decls): Also duplicate DECL_FINAL_
On 2 February 2015 at 20:50, Ville Voutilainen
wrote:
> The modified test has been tested, I'm currently running the full testsuite,
> so testing is incomplete. I wanted to send this in asap, since this is a
> bad regression.
>
> /cp
> 2015-02-02 Ville Voutilainen
On 4 February 2015 at 12:22, Paolo Carlini wrote:
> I see that Jason applied the fix to mainline. Today I noticed that this is
> also a regression in the 4_9-branch: shall I regression test the fix there
> too, in case apply and close the bug?
Please do, thanks.
On Wed, 29 May 2019 at 23:00, Jonathan Wakely wrote:
> Does anybody think we should keep __gnu_cxx::size_t,
> __gnu_cxx::input_iterator_tag, __gnu_cxx::vector, __gnu_cxx::pair etc.
> or should I go ahead and commit this?
+1 go ahead.
On Sat, 1 Jun 2019 at 01:24, Ed Smith-Rowland via libstdc++
wrote:
>
> Greetings,
>
> Iterators for and are usabe in a constexpr context
> since C++2017.
>
> This just adds a compile test to make sure and check a box for C++20
> p0858 - ConstexprIterator requirements.
Those tests don't use the
Tested on Linux-PPC64, acked by Jason on irc. Applying to trunk
on Saturday.
2019-06-01 Ville Voutilainen
gcc/cp
PR c++/85254
* class.c (fixup_type_variants): Handle CLASSTYPE_FINAL.
testsuite/
PR c++/85254
* g++.dg/ext/is_final.C: Amend.
diff --git a/gcc/cp
On Sat, 1 Jun 2019 at 21:09, Ed Smith-Rowland <3dw...@verizon.net> wrote:
>
> On 5/31/19 6:29 PM, Ville Voutilainen wrote:
> > On Sat, 1 Jun 2019 at 01:24, Ed Smith-Rowland via libstdc++
> > wrote:
> >> Greetings,
> >>
> >> Iterators for and
On Sat, 1 Jun 2019 at 22:40, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> Ok, third time's a charm.
>
> I was brain dead about the constexpr patch.?? I'm now setting a constexpr
> variable from test() in a caller.
Looks good. Jonathan needs to approve it, though.
> But static_assert is a const
101 - 200 of 632 matches
Mail list logo
