Oohh... I can commit to trunk?
Yes, you're on the write-after-approval list in MAINTAINERS. :)
True, but it's my first commit to trunk :) Incidentally, that's committed now.
Andrew
* pt.c (lookup_template_variable): Make the type unspecified if
any template arguments are dependent.
This hunk is OK.
Hi Jason, did you apply this hunk of the patch, or should I just
resend this by itself?
Andrew
On 08/12/2014 04:21 PM, Andrew Sutton wrote:
* pt.c (lookup_template_variable): Make the type unspecified if
any template arguments are dependent.
This hunk is OK.
Hi Jason, did you apply this hunk of the patch, or should I just
resend this by itself?
I thought you
Oohh... I can commit to trunk? I can do it tomorrow morning.
Andrew Sutton
On Tue, Aug 12, 2014 at 4:59 PM, Jason Merrill ja...@redhat.com wrote:
On 08/12/2014 04:21 PM, Andrew Sutton wrote:
* pt.c (lookup_template_variable): Make the type unspecified
if
any template
On 08/12/2014 05:17 PM, Andrew Sutton wrote:
Oohh... I can commit to trunk?
Yes, you're on the write-after-approval list in MAINTAINERS. :)
Jason
On 08/07/2014 09:22 AM, Andrew Sutton wrote:
* pt.c (lookup_template_variable): Make the type unspecified if
any template arguments are dependent.
This hunk is OK.
* decl.c (cp_finish_decl): Don't check the initializer if it is
value-dependent.
Why is
* decl.c (cp_finish_decl): Don't check the initializer if it is
value-dependent.
Why is this needed?
I thought that check_initializer was evaluating the constant
expression, and was resulting in errors because a template-id
referring to a variable template with a concrete
Hi,
On 08/06/2014 06:41 AM, Braden Obrzut wrote:
I can confirm that this is caused by a change to pt.c that happened, I
think, the day before my last patch.
This can be fixed by first checking that the template is a function
template at that line in pt.c. Since variable templates can't be
Here's a patch for the more conservative option.
- Braden Obrzut
2014-08-06 Braden Obrzut ad...@maniacsvault.net
* pt.c (check_explicit_specialization): Ensure tmpl is a function
template before checking if it is inline for COMDAT.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index
On 08/05/2014 04:06 PM, Paolo Carlini wrote:
Great. I will double check but var-templ4.C fails for me with an ICE.
Hunh, I wonder how I missed that.
Here's what I'm checking in; we want to unset DECL_COMDAT for variable
templates, too.
commit b79ecb5928b875ba38b78a3fadb0dd70d6262513
Applied with a few formatting/comment tweaks, thanks!
Jason
Hi,
On 08/05/2014 08:26 PM, Jason Merrill wrote:
Applied with a few formatting/comment tweaks, thanks!
Great. I will double check but var-templ4.C fails for me with an ICE.
Can anybody reproduce?
Thanks!
Paolo.
/.../gcc/testsuite/g++.dg/cpp1y/var-templ4.C:8:17: internal
I can confirm that this is caused by a change to pt.c that happened, I
think, the day before my last patch.
This can be fixed by first checking that the template is a function
template at that line in pt.c. Since variable templates can't be
friends, it might also be suitable to skip that
On 07/31/2014 08:53 AM, Jason Merrill wrote:
In the original mail you mentioned doing it in cp_parser_template_id;
I agree that we probably don't want to do it there because of the
complications you are seeing. I was thinking about doing it when we
normally resolve an id-expression that
Here's an updated patch with cp_parser_id_expression instantiating the
variable templates if this is indeed what we want to do.
The previous implementation did seem to make the distinction between
static template class member variables and variable templates a bit more
obvious. See the first
On 07/30/2014 05:33 PM, Braden Obrzut wrote:
On 07/30/2014 04:44 PM, Jason Merrill wrote:
Why not do this in cp_parser_id_expression?
I did mention this in the original mail, is this definitely the way it
should be done?
In the original mail you mentioned doing it in cp_parser_template_id;
On 07/29/2014 07:56 AM, Braden Obrzut wrote:
@@ -6289,6 +6289,14 @@ cp_parser_postfix_expression (cp_parser *parser, bool
address_p, bool cast_p,
break;
default:
+ /* Convert variable template into VAR_DECL. */
+ if (TREE_CODE (postfix_expression) ==
On 07/30/2014 04:44 PM, Jason Merrill wrote:
Why not do this in cp_parser_id_expression?
I did mention this in the original mail, is this definitely the way it
should be done? Andrew pointed this out to me before sending in the
patch, my initial investigation into doing so seemed to show it
This version of the patch should pass the entire test suite.
g++.dg/parse/error50.C noted that wasn't handling the case of empty
template parameters properly (accepted silently). As a result,
grokvardecl now calls check_explicit_specialization more liberally and
may return NULL_TREE.
The
On 2014-07-28 3:06, Braden Obrzut wrote:
So given this, should I leave the test cases that fail for this
reason alone or should I still change them to dg-message?
I'm not sure what GCC's policy is here, Jason will.
It sounds like GCC's behavior with auto in function parameters
needs to be
It sounds like GCC's behavior with auto in function parameters
needs to be changed, but that definitely sounds like a separate
patch to me.
I think so. It's definitely a different patch.
Agreed.
I've been
thinking about a simple way for your patch to add to the
constraints for
On 07/27/2014 10:06 PM, Braden Obrzut wrote:
So given this, should I leave the test cases that fail for this reason
alone or should I still change them to dg-message? It sounds like GCC's
behavior with auto in function parameters needs to be changed, but that
definitely sounds like a separate
On 2014-07-28 13:09, Andrew Sutton wrote:
3) auto (*f (auto)) (auto); // generic function 'f' constrained to
returning a unary function pointer deduced from the return
expression.
Really? I've read the comment and I'm still not sure how to read this
declaration.
The first and last 'auto'
On 2014-07-26 17:14, Jason Merrill wrote:
On 07/26/2014 12:11 PM, Jason Merrill wrote:
On 07/26/2014 03:04 AM, Braden Obrzut wrote:
On 07/25/2014 05:24 PM, Jason Merrill wrote:
Fair enough, but in that case let's use 'sorry' rather then
'error' to
be clear that it's a missing feature.
In the 59638 case, the declarations
void (*a)(auto);
void (*b)(auto) = 0;
are shorthand for
template typename T void (*a)(T);
template typename T void (*b)(T) = 0;
which, unless there's some constraint with variable templates that I'm not
aware of, ought to define two variable
On 2014-07-27 19:01, Andrew Sutton wrote:
In the 59638 case, the declarations
void (*a)(auto);
void (*b)(auto) = 0;
are shorthand for
template typename T void (*a)(T);
template typename T void (*b)(T) = 0;
which, unless there's some constraint with variable templates that
I'm not
So given this, should I leave the test cases that fail for this reason
alone or should I still change them to dg-message? It sounds like GCC's
behavior with auto in function parameters needs to be changed, but that
definitely sounds like a separate patch to me.
- Braden Obrzut
Ed, I looked into partial specializations and it looks like, while not
trivial, it would be easy enough for me to do them. However, it is not
required for concepts (which can not be specialized), so should I fix
them for this patch or as a separate patch later?
On 07/25/2014 05:24 PM, Jason
On 07/26/2014 03:04 AM, Braden Obrzut wrote:
On 07/25/2014 05:24 PM, Jason Merrill wrote:
Fair enough, but in that case let's use 'sorry' rather then 'error' to
be clear that it's a missing feature.
Tests like g++.dg/cpp1y/pr59638.C produce extra failures if this is
changed. Is there
On 07/26/2014 12:11 PM, Jason Merrill wrote:
On 07/26/2014 03:04 AM, Braden Obrzut wrote:
On 07/25/2014 05:24 PM, Jason Merrill wrote:
Fair enough, but in that case let's use 'sorry' rather then 'error' to
be clear that it's a missing feature.
Tests like g++.dg/cpp1y/pr59638.C produce extra
On 07/26/2014 03:04 AM, Braden Obrzut wrote:
Ed, I looked into partial specializations and it looks like, while not
trivial, it would be easy enough for me to do them. However, it is
not required for concepts (which can not be specialized), so should I
fix them for this patch or as a separate
-constexpr variable
%qD, decl);
+}
As Ed and Andrew pointed out, non-constexpr variable templates are fine.
This patch only covers constexpr variable templates, so it makes sense
to produce an error for now. Otherwise more confusing linker errors
will be thrown regarding duplicate
How difficult would it be to make partial specializations work:
// Write n*pi once for every possible type
templatetypename Tp, std::size_t N
constexpr Tp npi = N * Tp(3.1415926535897932385L);
// Partial specialization for int type.
templatestd::size_t N
constexpr double npiint, N = N *
On 07/25/2014 07:43 AM, Braden Obrzut wrote:
This patch only covers constexpr variable templates, so it makes sense
to produce an error for now.
Fair enough, but in that case let's use 'sorry' rather then 'error' to
be clear that it's a missing feature.
I ran the testsuite with your patch
First of all, thanks a lot for taking this on! A few nitpicks:
On 07/21/2014 11:06 PM, Braden Obrzut wrote:
grokvardecl (tree type,
tree name,
+tree orig_declarator,
const cp_decl_specifier_seq *declspecs,
int initialized,
Braden,
Great work on this. In addition to helping with constraints there is at
least one new library feature that depends on constexpr variable templates.
For my two cents it would be good to get just the constexpr variable
templates, aka n3651, in now as a first stage - it's quite usable.
But someday we'll want non-constexpr too. I have only seen a sentence
somewhere stating that non-constexpr variable templates are allowed but have
seen no paper or wording anywhere. Does anyone know where such exists?
When variable templates were proposed, EWG decided they wanted
Braden,
I've played with this and it seems to work nicely.
Only one comment: Could you put the test cases in the C++14 subdirectory?
g++.dg/template/cpp1y/var-templ1.C
^
We should CC Jason on all this.
Also, do you have your FSF paperwork in place?
Thanks,
Ed
Sure, test cases moved.
My FSF paperwork is in place. I don't have write access to the
repository though of course.
- Braden Obrzut
2014-07-21 Braden Obrzut ad...@maniacsvault.net
* decl.c (grokvardecl): Handle specializations of variable templates.
(grokdeclarator): Handle
While working on variable concepts, I noticed that one of the added
blocks of code was no longer needed due to a previous simplification and
caused problems. Also included a new test case which triggered the
problem, and fixed a minor formatting issue.
As before, if the plan is to revive the
Here is a patch that expands on Gabriel Dos Reis's initial var-template
patch ( https://gcc.gnu.org/ml/gcc-patches/2013-03/msg01295.html ). I
just noticed now that those patches were committed to a branch, so if
need be I can resubmit the patch with Gaby's changes not included.
The purpose
41 matches
Mail list logo
