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 the kind of type-parameter-key specified, or none_type to
indicate
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 ville.voutilai...@gmail.com
PR c++/63959
Tested on Linux-x64. Remotely related to pr50645, which we should
probably close as invalid.
/cp
2014-11-26 Ville Voutilainen ville.voutilai...@gmail.com
Diagnose string constant conversion to char* in c++11 and above
as forbidden, not deprecated.
* typeck.c (string_conv_p): Do
Ville Voutilainen ville.voutilai...@gmail.com
Diagnose string constant conversion to char* in c++11 and above
as forbidden, not deprecated.
* g++.dg/warn/write-strings-default.C: Adjust.
* g++.dg/warn/write-strings.C: Likewise.
* g++.old-deja/g++.bob/inherit1.C: Likewise
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 support
On 1 October 2014 11:11, Paolo Carlini paolo.carl...@oracle.com 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 class T, class... Args void bar() {
static_assert(__is_trivially_constructible(T
On 1 October 2014 20:20, Jason Merrill ja...@redhat.com 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
Tested on Linux-X64.
Massive thanks to Jason for doing the heavy lifting on the front-end side.
2014-10-08 Ville Voutilainen ville.voutilai...@gmail.com
PR libstdc++/60132
* include/std/type_traits (is_trivially_copyable,
is_trivially_constructible, is_trivially_default_constructible
Ville Voutilainen ville.voutilai...@gmail.com
PR libstdc++/60132
* include/std/type_traits (is_trivially_copyable,
is_trivially_constructible, is_trivially_default_constructible,
is_trivially_copy_constructible, is_trivially_move_constructible,
is_trivially_assignable
Tested on Linux-x64. The {raw,}invocable_type trait and its variable templates
are not implemented yet.
2014-10-16 Ville Voutilainen ville.voutilai...@gmail.com
Implement the Library Fundamentals v1 variable templates for
type traits.
* include/Makefile.am: Add the new header
On 16 October 2014 22:25, Ville Voutilainen ville.voutilai...@gmail.com wrote:
Tested on Linux-x64. The {raw,}invocable_type trait and its variable templates
are not implemented yet.
2014-10-16 Ville Voutilainen ville.voutilai...@gmail.com
Implement the Library Fundamentals v1
Tested on Linux-x64.
2014-10-18 Ville Voutilainen ville.voutilai...@gmail.com
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
On 18 October 2014 23:18, Ville Voutilainen ville.voutilai...@gmail.com wrote:
Tested on Linux-x64.
2014-10-18 Ville Voutilainen ville.voutilai...@gmail.com
Implement more Library Fundamentals v1 variable templates for
type traits.
* include/Makefile.am: Add ratio, chrono
On 20 October 2014 15:38, Jonathan Wakely jwak...@redhat.com 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
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 __
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
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 @@
On 13 June 2014 01:37, Ville Voutilainen ville.voutilai...@gmail.com 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
On 13 June 2014 19:56, Jason Merrill ja...@redhat.com 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
On 13 June 2014 21:33, Jason Merrill ja...@redhat.com 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
templateclass T struct A {
enum E
On 15 June 2014 16:37, Jason Merrill ja...@redhat.com 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
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 ville.voutilai...@gmail.com
Implement is_trivially_default_constructible.
* doc/xml/manual/status_cxx2011.xml: Remove mention
On 12 September 2014 05:05, Jason Merrill ja...@redhat.com 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
On 12 September 2014 17:41, Jason Merrill ja...@redhat.com 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 give information about former bugs
Tested on Linux-x64.
/cp
2014-09-14 Ville Voutilainen ville.voutilai...@gmail.com
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 ville.voutilai...@gmail.com
Tested on Linux-x64.
/testsuite
2014-09-14 Ville Voutilainen ville.voutilai...@gmail.com
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
On 14 September 2014 21:36, Paolo Carlini paolo.carl...@oracle.com 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 compile.
Sure
On 15 September 2014 18:51, Jason Merrill ja...@redhat.com 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 the dg-error c++11_only
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 ==
On 21 September 2011 02:18, Ville Voutilainen
ville.voutilai...@gmail.com 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
ville.voutilai...@gmail.com 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
Tested on X86-32 linux.
2011-10-21 Ville Voutilainen ville.voutilai...@gmail.com
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
Tested on Linux/X86-32.
2011-07-21 Ville Voutilainen ville.voutilai...@gmail.com
ville.voutilai...@symbio.com
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
On 21 July 2011 18:23, Ville Voutilainen ville.voutilai...@gmail.com 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
On 22 July 2011 22:43, Jason Merrill ja...@redhat.com 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 ville.voutilai...@gmail.com
2012-06-16 Ville Voutilainen ville.voutilai...@gmail.com
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
On 20 June 2012 10:35, Jason Merrill ja...@redhat.com 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
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 ma...@lysator.liu.se 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 ja...@redhat.com 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
On 4 November 2011 20:53, Jason Merrill ja...@redhat.com 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
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
On 25 April 2011 18:32, Gabriel Dos Reis g...@integrable-solutions.net 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
On 28 April 2011 00:56, Gabriel Dos Reis g...@integrable-solutions.net 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,
On 28 April 2011 01:40, Gabriel Dos Reis g...@integrable-solutions.net 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
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 ville.voutilai...@gmail.com
ville.voutilai
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 ville.voutilai...@gmail.com
ville.voutilai...@symbio.com
Fixes for override/final
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
---
On 13 May 2011 20:46, Jason Merrill ja...@redhat.com 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
At Fri, 13 May 2011 14:13:52 -0400,
Jason Merrill wrote:
Yes, the order affects the handling of
struct Undeclaredint 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.
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,
Tested on Linux/X86-32.
2011-09-20 Ville Voutilainen ville.voutilai...@gmail.com
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
On 5 December 2011 17:51, Jason Merrill ja...@redhat.com 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
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 paolo.carl...@oracle.com 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
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
On 12 August 2014 11:47, Ville Voutilainen ville.voutilai...@gmail.com 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 ja...@redhat.com 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 attached. The changelog entry
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 ja...@redhat.com 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 ICE...
Yeah, 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 add tests, too. :P
But tests
On 25 August 2014 17:08, ville.voutilai...@gmail.com 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
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 ville.voutilai...@gmail.com
C++14 constexpr min, max, minmax
On 18 December 2014 at 02:16, Ville Voutilainen
ville.voutilai...@gmail.com 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-12-18
Tested on Linux-x64.
/cp
2014-12-19 Ville Voutilainen ville.voutilai...@gmail.com
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
Any comments on this?
On 19 December 2014 at 09:21, Ville Voutilainen
ville.voutilai...@gmail.com wrote:
Tested on Linux-x64.
/cp
2014-12-19 Ville Voutilainen ville.voutilai...@gmail.com
Reject trailing return type for an operator auto().
* decl.c (grokdeclarator): Reject
On 2 February 2015 at 20:50, Ville Voutilainen
ville.voutilai...@gmail.com 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
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 ville.voutilai...@gmail.com
PR c++/64901
* decl.c (duplicate_decls): Also duplicate
On 4 February 2015 at 12:22, Paolo Carlini paolo.carl...@oracle.com 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.
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
On 19 January 2015 at 21:12, Ville Voutilainen
ville.voutilai...@gmail.com wrote:
On 19 January 2015 at 18:28, Ville Voutilainen
ville.voutilai...@gmail.com wrote:
When I patched the triviality test for volatile types, I missed two cases:
1) volatile members in a class should make the class
On 20 January 2015 at 15:06, Jason Merrill ja...@redhat.com 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))
+ || type_code1 == REFERENCE_TYPE
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 ville.voutilai...@gmail.com
PR c++/63959
* class.c (check_field_decls): If any field is volatile
On 19 January 2015 at 18:28, Ville Voutilainen
ville.voutilai...@gmail.com 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 19 January 2015 at 00:11, Ville Voutilainen
ville.voutilai...@gmail.com 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
, 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 ville.voutilai...@gmail.com
PR libstdc++/64656
* include/bits
On 30 January 2015 at 23:06, Ville Voutilainen
ville.voutilai...@gmail.com 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 ja...@redhat.com wrote:
The patch changes all the static_assert strings
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 ja...@redhat.com 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
On 30 January 2015 at 21:59, Ville Voutilainen
ville.voutilai...@gmail.com 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
On 30 January 2015 at 19:46, Jason Merrill ja...@redhat.com wrote:
On 01/20/2015 09:27 AM, Ville Voutilainen wrote:
+#define YES2(type) TRY(std::is_trivialtype::value); \
+ TRY(std::is_trivialtype[]::value); \
TRY(std::is_trivialconst volatile type::value)
+YES2(void *);
+YES2(int
On 30 January 2015 at 20:25, Jason Merrill ja...@redhat.com 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
is_trivialconst volatile void*::value, which is true
Tested on Linux-x64.
/cp
2015-01-05 Ville Voutilainen ville.voutilai...@gmail.com
PR c++/64489
* class.c (check_field_decls): Make copy assignment operators
complex only in c++98 mode.
/testsuite
2015-01-05 Ville Voutilainen ville.voutilai...@gmail.com
PR c++/64489
* g
On 6 March 2015 at 23:58, Jason Merrill ja...@redhat.com 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 points out
, 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 ville.voutilai...@gmail.com
Add __is_nothrow_swappable and take it into use.
* libstdc++-v3/include/bits/algorithmfwd.h: Add constraints
On 1 May 2015 at 12:47, Ville Voutilainen ville.voutilai...@gmail.com 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 ville.voutilai...@gmail.com
Implement observer_ptr.
* include/Makefile.am: Add new exported header.
* include/Makefile.in: Regenerate.
* include/experimental/memory: New.
* testsuite/experimental/memory/observer_ptr
On 28 December 2014 at 20:21, Ville Voutilainen
ville.voutilai...@gmail.com 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
ville.voutilai...@gmail.com wrote:
Tested
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 ville.voutilai...@gmail.com
Add support for std::uncaught_exceptions.
* acinclude.m4: Bump
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 Voutilainen
On 8 June 2015 at 18:53, Ville Voutilainen ville.voutilai...@gmail.com wrote:
On 8 June 2015 at 18:37, Martin Sebor mse...@redhat.com 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 18:37, Martin Sebor mse...@redhat.com 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 7 June 2015 at 11:12, Ville Voutilainen ville.voutilai...@gmail.com wrote:
Does the following code still compile with your patch?
struct A { int a,b; };
std::tupleint,int,A 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
On 7 June 2015 at 11:33, Ville Voutilainen ville.voutilai...@gmail.com wrote:
You use a lot: typename enable_ifX, bool::type=true
while the current code seems to favor: class=typename enable_ifX::type.
I don't really care which one is used, but it is easier to read when the
style is consistent
On 7 June 2015 at 09:53, Marc Glisse marc.gli...@inria.fr 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?
On 8 June 2015 at 19:01, Ville Voutilainen ville.voutilai...@gmail.com 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
Tested on Linux-PPC64. Patch gzipped to avoid polluting people's
mailboxes with a 45k patch.
2015-07-03 Ville Voutilainen ville.voutilai...@gmail.com
Implement std::experimental::fundamentals_v2::propagate_const.
* include/Makefile.am: Add propagate_const.
* include/Makefile.in: Add
On 19 August 2015 at 23:37, Paolo Carlini paolo.carl...@oracle.com wrote:
Ah, Ok, I didn't actually try to compile your snippet. Then I suspect you
mean c++/66606?!? Please double check if something is missing in Martin's
bug!
That looks fairly comprehensive to me, I don't think I have cases
On 19 August 2015 at 23:26, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi Ville,
On 08/19/2015 10:12 PM, Ville Voutilainen wrote:
submitter noticed that, in violation of [basic.start.main], we don't
reject
as ill-formed the declaration of a 'main' variable in the global
namespace
1 - 100 of 614 matches
Mail list logo
