>> 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
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
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 wrote:
> On 08/12/2014 04:21 PM, Andrew Sutton wrote:
* pt.c (lookup_template_variable): Make the type unspecified
if
any template ar
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 woul
>> * 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
>> * 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 conc
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 thi
This patch prevents the initializer from being checked when it is
dependent. It also sets the type of a dependent template-id referring
to a variable template to be unknown, making such expressions type
dependent.
2014-08-07 Andrew Sutton
* pt.c (lookup_template_variable): Make the typ
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
Author
Here's a patch for the more conservative option.
- Braden Obrzut
2014-08-06 Braden Obrzut
* 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 57e7216..3bc3961 100644
--- a
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
f
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 enti
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 com
Applied with a few formatting/comment tweaks, thanks!
Jason
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 refers
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;
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 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 w
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) == TEMPLATE_I
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 ot
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' in
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 pa
>> 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 fo
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 cha
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
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 void (*a)(T);
template void (*b)(T) = 0;
which, unless there's some constraint with variable templates that
I'm not
aware of, ought to def
> In the 59638 case, the declarations
>
> void (*a)(auto);
> void (*b)(auto) = 0;
>
> are shorthand for
>
> template void (*a)(T);
> template void (*b)(T) = 0;
>
> which, unless there's some constraint with variable templates that I'm not
> aware of, ought to define two variable templates
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.
Tes
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
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:
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 somethi
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 M
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 ap
How difficult would it be to make partial specializations work:
// Write n*pi once for every possible type
template
constexpr Tp npi = N * Tp(3.1415926535897932385L);
// Partial specialization for int type.
template
constexpr double npi = N * double(3.1415926535897932385L);
On 07/24/2014 04:56 PM, Jason Merrill wrote:
+ /* Variable templates will need to have the class context. */
+ if (VAR_P (value))
+DECL_CONTEXT (value) = current_class_type;
Why isn't this covered by grokvardecl?
Oops, as the changelog indicated, this was to satisfy the old
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,
int
> 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
non-conste
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.
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
* decl.c (grokvardecl): Handle specializations of variable templates.
(grokdeclarator): Handle variable template id express
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
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 of
42 matches
Mail list logo
