Today is the first day I've had to look at these comments.
>>if (TEMPLATE_PARM_CONSTRAINTS (current_template_parms))
>> -TYPE_CANONICAL (type) = type;
>> +SET_TYPE_STRUCTURAL_EQUALITY (type);
>
>
> This seems like papering over an underlying issue. What was the testcase
> that motiva
> It looks like things are coming together pretty well. What's your feeling
> about readiness to merge into the trunk? Is the branch down to no
> regressions?
They are coming together pretty well. We have one major unit test
failure involving template introductions (Braden is working on it),
one
It looks like things are coming together pretty well. What's your
feeling about readiness to merge into the trunk? Is the branch down to
no regressions?
See you on Monday!
@@ -4146,21 +4146,21 @@ build_new_function_call (tree fn, vec
**args, bool koenig_p,
if (TREE_CODE (fn) == TEMP
On 06/21/2013 08:46 AM, Andrew Sutton wrote:
I can move those patches over to git and push the changes in separate
branches in addition to the usual submission mechanism. Would that be
appropriate? Can I create a bunch of different git branches for small
feature sets?
Sure, that sounds fine.
J
I think I will continue to work from SVN branches, because I'm a lot
more familiar with that process. I'm also going to start working on a
couple of different checkouts of the c++-concepts branch
independently, so this should be a little easier for me.
I can move those patches over to git and push
On 06/20/2013 01:23 PM, Jason Merrill wrote:
Since Gaby prefers SVN, let's keep using the SVN branch; it really isn't
much less convenient than a git-only branch. The main difference is
'git svn rebase'/'git svn dcommit' instead of 'git pull'/'git push'.
The one caveat is that git-svn historic
On 06/20/2013 11:50 AM, Andrew Sutton wrote:
The c++-concepts SVN branch won't come in with a clone; you need to add it
to the fetch list with
git config --add remote.origin.fetch
refs/remotes/c++-concepts:refs/remotes/origin/c++-concepts
Then you can check out a local branch based on it.
Alr
> The c++-concepts SVN branch won't come in with a clone; you need to add it
> to the fetch list with
>
> git config --add remote.origin.fetch
> refs/remotes/c++-concepts:refs/remotes/origin/c++-concepts
>
> Then you can check out a local branch based on it.
Already did that. I probably need to do
Jason Merrill writes:
| On 06/20/2013 11:22 AM, Gabriel Dos Reis wrote:
| > Jason Merrill writes:
| >
| > | On 06/20/2013 10:17 AM, Andrew Sutton wrote:
| > | > It looks like I should be able to switch directly to the c++-concepts
| > | > branch. Or is there some configuration that has to happen
On 06/20/2013 11:22 AM, Gabriel Dos Reis wrote:
Jason Merrill writes:
| On 06/20/2013 10:17 AM, Andrew Sutton wrote:
| > It looks like I should be able to switch directly to the c++-concepts
| > branch. Or is there some configuration that has to happen on the
| > remote site?
|
| The c++-concep
Jason Merrill writes:
| On 06/20/2013 10:17 AM, Andrew Sutton wrote:
| > It looks like I should be able to switch directly to the c++-concepts
| > branch. Or is there some configuration that has to happen on the
| > remote site?
|
| The c++-concepts SVN branch won't come in with a clone; you nee
Andrew Sutton writes:
| That works. I think the current patch addresses all of Jason's comments.
OK, that sounds good.
| I'll also create a github version of this branch, so can avoid email patches.
Well, actually I prefer the email patches because I can read them them
right away when I have o
On 06/20/2013 10:17 AM, Andrew Sutton wrote:
It looks like I should be able to switch directly to the c++-concepts
branch. Or is there some configuration that has to happen on the
remote site?
The c++-concepts SVN branch won't come in with a clone; you need to add
it to the fetch list with
g
I didn't know it existed! Even better. Except that I'm not a git
expert. I'm reading through the docs on that site while I clone the
repo.
It looks like I should be able to switch directly to the c++-concepts
branch. Or is there some configuration that has to happen on the
remote site?
How will t
On 06/20/2013 09:18 AM, Andrew Sutton wrote:
I'll also create a github version of this branch, so can avoid email patches.
Why there rather than in the gcc.gnu.org git repository?
http://gcc.gnu.org/wiki/GitMirror
Jason
That works. I think the current patch addresses all of Jason's comments.
I'll also create a github version of this branch, so can avoid email patches.
On Thu, Jun 20, 2013 at 8:09 AM, Gabriel Dos Reis wrote:
> Jason Merrill writes:
>
> | On 06/20/2013 01:30 AM, Gabriel Dos Reis wrote:
> | > As
Jason Merrill writes:
| On 06/20/2013 01:30 AM, Gabriel Dos Reis wrote:
| > As I discussed
| > with Andrew a couple of weeks ago, I have been holding back the
| > merge from trunk because he has these patch series in the queue.
|
| Incidentally, since the code is going onto a branch, we don't re
On 06/20/2013 01:30 AM, Gabriel Dos Reis wrote:
As I discussed
with Andrew a couple of weeks ago, I have been holding back the
merge from trunk because he has these patch series in the queue.
Incidentally, since the code is going onto a branch, we don't really
need to delay checkins based on c
On Wed, Jun 19, 2013 at 9:21 AM, Jason Merrill wrote:
> On 06/18/2013 12:27 PM, Andrew Sutton wrote:
>>
>> There was a bug in instantiation_dependent_expr_r that would cause
>> trait expressions like __is_class(int) to be marked as type dependent.
>> It was always testing the 2nd operand, even for
>> +// If the types of the underlying templates match, compare
>> +// their constraints. The declarations could differ there.
>> +if (types_match)
>> + types_match = equivalent_constraints (get_constraints
>> (olddecl),
>> +
On 06/18/2013 12:27 PM, Andrew Sutton wrote:
There was a bug in instantiation_dependent_expr_r that would cause
trait expressions like __is_class(int) to be marked as type dependent.
It was always testing the 2nd operand, even for unary traits
(NULL_TREE turns out to be type dependent).
I fixed
On Mon, Jun 17, 2013 at 2:20 PM, Jason Merrill wrote:
>> I have not thought deeply about constrained friend declarations. What
>> would a friend temploid look like?
>
>
> I was thinking something like
>
> template struct A {
> T t;
> requires Addable()
> friend A operator+(const A& a1, cons
On 06/17/2013 02:10 PM, Andrew Sutton wrote:
You mean you don't need anymore in logic.cc? I think we want
the include in general if we're going to support people using the
C++ standard library.
I don't. Those decisions are above my pay grade, so I'm doing my best
not to make them.
If you d
>> 2. I left the include in system.h, because removing it will
>> result in errors due to an inclusion of . It's probable
>> that both can be removed, but I didn't test it with this patch.
>
>
> You mean you don't need anymore in logic.cc? I think we want
> the include in general if we're going
On Fri, Jun 14, 2013 at 8:40 PM, Jason Merrill wrote:
>> +// \Gamma, P |- Delta\Gamma, Q |- \Delta
>
>
> Are the \ for TeX markup or something? You're missing one on the left Delta
> here.
yes, I think the backslash was for LaTeX, but we get warnings about having
backslash in comments, so
1. tree_template_info still contains constraint_info. That will change
in a subsequent patch. I'm kind of waiting for specializations to get
TEMPLATE_DECLs.
Makes sense.
2. I left the include in system.h, because removing it will
result in errors due to an inclusion of . It's probable
that bo
On 06/12/2013 11:53 AM, Gabriel Dos Reis wrote:
I am still surprised though that we don't generate TEMPLATE_DECLs for
partial instantiations (since they are still morally templates.)
Yes, we should.
Jason
On Mon, Jun 10, 2013 at 2:30 PM, Jason Merrill wrote:
> On 06/08/2013 09:34 AM, Andrew Sutton wrote:
>>
>> I think I previously put constraint_info in lang_decl_min, right next
>> to template_info no less. It was easy to manage there, and initialized
>> as part of build_template_decl. But this obv
On 06/11/2013 11:09 AM, Andrew Sutton wrote:
And you need to do this even when the call is type-dependent?
Yes. Especially when the call is type-dependent. That's how I generate
the constraint sets, which are used to determine the most constrained
template during overload resolution.
Ah, that
> And you need to do this even when the call is type-dependent?
Yes. Especially when the call is type-dependent. That's how I generate
the constraint sets, which are used to determine the most constrained
template during overload resolution.
On 06/11/2013 10:49 AM, Andrew Sutton wrote:
After investigating, neither call_expr nor resolve_nondeduced_context
do what I need. I need a resolution of a call expression that does not
return overload sets, especially in the case where the initial call
expression is already dependent.
Does thi
>> After investigating, neither call_expr nor resolve_nondeduced_context
>> do what I need. I need a resolution of a call expression that does not
>> return overload sets, especially in the case where the initial call
>> expression is already dependent.
>
>
> Does this have to do with restrictions
On 06/11/2013 09:45 AM, Andrew Sutton wrote:
After investigating, neither call_expr nor resolve_nondeduced_context
do what I need. I need a resolution of a call expression that does not
return overload sets, especially in the case where the initial call
expression is already dependent.
Does thi
>> I think I previously put constraint_info in lang_decl_min, right next
>> to template_info no less. It was easy to manage there, and initialized
>> as part of build_template_decl. But this obviously doesn't work for
>> partial specializations unless they get template_decls.
>
>
> Right. And we w
On 6/10/13, Diego Novillo wrote:
> On 2013-06-09 20:34 , Gabriel Dos Reis wrote:
> > So, my advice is for GCC source code to forget about the
> > headers for the most part. I can see an instance where
> > or would make a difference but given point (1) above,
> > no it doesn't. Just use the tr
On 06/08/2013 09:34 AM, Andrew Sutton wrote:
I think I previously put constraint_info in lang_decl_min, right next
to template_info no less. It was easy to manage there, and initialized
as part of build_template_decl. But this obviously doesn't work for
partial specializations unless they get tem
On 06/09/2013 08:49 PM, Gabriel Dos Reis wrote:
If you put the function in an unnamed namespace
you would expect GCC to treat is as if it was of internal
linkage for many purposes including automatic inlining, but
it doesn't:-( For example, you lose the "defined but not used
warning", and the "
On 06/09/2013 08:34 PM, Gabriel Dos Reis wrote:
I strongly suggest prefering over for GCC source code
base.
The problem is that including does not define
_GLIBCXX_CSTDLIB, so if one of the C++ library headers includes
the contents are added then, but by that point e.g. "malloc"
is poison
On 2013-06-09 20:34 , Gabriel Dos Reis wrote:
So, my advice is for GCC source code to forget about the
headers for the most part. I can see an instance where or
would make a difference but given point (1) above, no it doesn't.
Just use the traditional headers and be done with it.
Maybe I s
On Sat, Jun 8, 2013 at 8:34 AM, Andrew Sutton wrote:
>> template
>> tree
>> extract_goals (proof_state& s)
>> ...
>> return extract_goals(s);
>>
>> but I suppose STL style is OK, too.
>
>
> Huh. I didn't realize that could be inlined. Neat.
We do -- we have been doing so for quite some time
now
On Sun, Jun 9, 2013 at 3:34 PM, Oleg Endo wrote:
> On Thu, 2013-06-06 at 16:29 -0400, Jason Merrill wrote:
>> On 06/06/2013 01:47 PM, Andrew Sutton wrote:
>> > I never did understand why this happens. Compiling with GCC-4.6, I get
>> > these errors originating in logic.cc from an include of .
>> >
On Thu, 2013-06-06 at 16:29 -0400, Jason Merrill wrote:
> On 06/06/2013 01:47 PM, Andrew Sutton wrote:
> > I never did understand why this happens. Compiling with GCC-4.6, I get
> > these errors originating in logic.cc from an include of .
> > This is what I get:
> >
> > /usr/include/c++/4.6/cstdli
>> +C++ ObjC++ Var(flag_concepts, true)
>
> This line declares flag_concepts implicitly.
Ah... I see. Fixed.
>> That's the long and short of it. Gaby suggested writing constraints
>> here so that, for any instantiation, you would have easy access to the
>> constraints for that declaration.
>
> I
On 06/06/2013 01:47 PM, Andrew Sutton wrote:
I never did understand why this happens. Compiling with GCC-4.6, I get
these errors originating in logic.cc from an include of .
This is what I get:
/usr/include/c++/4.6/cstdlib:76:8: error: attempt to use poisoned "calloc"
Ah, I see: adding the inc
Hi Jason,
Thanks for the comments. I just went ahead and fixed all the editorial
issues. Comments and questions below:
>> * gcc/system.h (cstdlib): Include to avoid poisoned
>> declaration errors.
>
> Poisoned declarations of what? This seems redundant with the #include
> just
Hi, I'm finally going through the current code on the branch, sorry for
the delay.
* gcc/system.h (cstdlib): Include to avoid poisoned
declaration errors.
Poisoned declarations of what? This seems redundant with the #include
just below.
+ /* Concepts-related keywords *
46 matches
Mail list logo
