On 06/26/2014 11:28 PM, Jason Merrill wrote:
On 06/26/2014 09:38 PM, Ed Smith-Rowland wrote:
So is C++14 a done deal with a __cplusplus date and all?
The C++14 draft was finalized at the February meeting in Issaquah; the
ratification process isn't quite done, but I haven't heard any reason
On 06/27/2014 09:41 AM, Ed Smith-Rowland wrote:
The C++14 draft was finalized at the February meeting in Issaquah; the
ratification process isn't quite done, but I haven't heard any reason
to doubt that it will be done soon. The __cplusplus date is 201402L.
I guess we should set this
On 06/25/2014 10:03 AM, Andrew Sutton wrote:
I did a full 3-stage bootstrap which is the default these days.
I'll try --disable-bootstrap and see what happens.
I just did a full bootstrap build and got the same errors. The errors
are correct for C++11, which was enabled by default in this
On 06/26/2014 11:15 AM, Ed Smith-Rowland wrote:
I, for one, would like gcc to bootstrap with c++11/c++14. I think we
should be starting to shake down that path. I'm probably not alone in
this.
Agreed.
On the other hand, I don't think c++-concepts branch should be the
leader on this. We
On 06/26/2014 12:23 PM, Jason Merrill wrote:
We could add -std=c++1z and add it to that, though.
Added.
Jason
So is C++14 a done deal with a __cplusplus date and all?
I've been waiting for some news or a trip report from Rapperswil and
have seen nothing on isocpp.
I've been thinking of adding a thing or two to C++1z like clang has -
The Disabling trigraph expansion by default looks easy.
Ed
On 06/26/2014 09:38 PM, Ed Smith-Rowland wrote:
So is C++14 a done deal with a __cplusplus date and all?
The C++14 draft was finalized at the February meeting in Issaquah; the
ratification process isn't quite done, but I haven't heard any reason to
doubt that it will be done soon. The
I did a full 3-stage bootstrap which is the default these days.
I'll try --disable-bootstrap and see what happens.
I just did a full bootstrap build and got the same errors. The errors
are correct for C++11, which was enabled by default in this branch.
IIRC, aggregate initialization requires
Braden,
Did you have a specific test case that causes this breakage? I have a
feeling that if we're missing base-link nodes in one place, we'll miss
them in others too.
Andrew
On Tue, Jun 17, 2014 at 4:54 AM, Braden Obrzut ad...@maniacsvault.net wrote:
cp_maybe_constrained_type_specifier
I saw this during bootstrap. I've verified that the patch works (I was
working on similar).
Ed
Committed as r211935. I updated the patch to add a more appropriate
comment and changelog entry.
Andrew
On Tue, Jun 24, 2014 at 8:07 AM, Ed Smith-Rowland 3dw...@verizon.net wrote:
I saw this during bootstrap. I've verified that the patch works (I was
working on similar).
Ed
Index: parser.c
I am still having problems doing a full build.
I get stuck on something that I think can't be a concepts problem in
gcc/config/i386/i386.c:
make[3]: Entering directory `/home/ed/obj_concepts/gcc'
/home/ed/obj_concepts/./prev-gcc/xg++
-B/home/ed/obj_concepts/./prev-gcc/
I'm not sure the warning is correct in any case...
In i386.h
struct stringop_algs
{
const enum stringop_alg unknown_size;
const struct stringop_strategy {
const int max;
const enum stringop_alg alg;
int noalign;
} size [MAX_STRINGOP_ALGS];
};
in i386.c
---
Weird. Any chance you're doing a bootstrap build?
There was an earlier bootstrapping issue with this branch. We had
turned on -std=c++1y by default, and it was causing some conversion
errors with lvalue references to bitfields in libasan.
This doesn't *look* like a regression caused by concepts
On 06/24/14, Andrew Sutton wrote:
Weird. Any chance you're doing a bootstrap build?
There was an earlier bootstrapping issue with this branch. We had
turned on -std=c++1y by default, and it was causing some conversion
errors with lvalue references to bitfields in libasan.
This doesn't
cp_maybe_constrained_type_specifier asserted that the decl passed in
would be of type OVERLOAD, however a clean build of the compiler was
broken since it could also be a BASELINK. I'm not entirely sure when
this is the case, except that it seems to happen with class member
templates as it
16 matches
Mail list logo
