Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier
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 correctly in libcpp/init.c or wherever. Do you see a problem with changing it from its current value of 201300? We don't use the actual number AFAICT. I guess we could also use a fake date for c++1z/c++17. Say 201500? Sounds good. I've been thinking of adding a thing or two to C++1z like clang has - The Disabling trigraph expansion by default looks easy. Aren't trigraphs off by default already? They are *off* by default with gnu++NN and *on* by default with c++NN. We want them *off* by default for all (gnu|c)++(1z|17). But -trigraphs will restore them for all versions. OK. Jason
Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier
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 to doubt that it will be done soon. The __cplusplus date is 201402L. I guess we should set this correctly in libcpp/init.c or wherever. Do you see a problem with changing it from its current value of 201300? We don't use the actual number AFAICT. I guess we could also use a fake date for c++1z/c++17. Say 201500? I've been thinking of adding a thing or two to C++1z like clang has - The Disabling trigraph expansion by default looks easy. Aren't trigraphs off by default already? They are *off* by default with gnu++NN and *on* by default with c++NN. We want them *off* by default for all (gnu|c)++(1z|17). But -trigraphs will restore them for all versions. Jason
Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier
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 __cplusplus date is 201402L. I've been thinking of adding a thing or two to C++1z like clang has - The Disabling trigraph expansion by default looks easy. Aren't trigraphs off by default already? Jason
Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier
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
Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier
On 06/26/2014 12:23 PM, Jason Merrill wrote: We could add -std=c++1z and add it to that, though. Added. Jason
Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier
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 have our work cut out for us without fighting these bugs. Also agreed. Maybe a c++11-bootstrap branch could be started to work the c++1* bootstrap out. I don't think a separate branch is necessary; people can bootstrap with -std=c++11 locally and fix issues they find on the trunk. As for flags. I vote for concepts switched on for -std=c++1y. As for -fconcepts turning on c++1y I'm less sure. We could allow concepts for C++11 (I don't think c++98 would work because of constexpr and maybe new template syntax). I hadn't thought about that. Personally I leave -std=c++14 and use all the things... ;-) -fconcepts should not be implied by -std=c++1[4y], because concepts are not part of C++14. We could add -std=c++1z and add it to that, though. I lean weakly against having -fconcepts imply a particular -std level, but it should definitely require c++11 or higher. Jason
Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier
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 branch. IIRC, aggregate initialization requires the initializer-clause to match the structure exactly (or at least not omit any const initializers?) I think this was something Gaby wanted when we created the branch, but I'm not sure it's worth keeping because of the bootstrapping errors. I could reset the default dialect to 98 and turn on concepts iff 1y is enabled, or I could turn on 1y if -fconcepts is enabled. Thoughts? Andrew I did --disable-bootstrap and it worked a charm. 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. On the other hand, I don't think c++-concepts branch should be the leader on this. We have our work cut out for us without fighting these bugs. Maybe a c++11-bootstrap branch could be started to work the c++1* bootstrap out. As long as gcc defaults to bootstrappng with c++98 I think we should do that if it won't preclude concepts work. Put it this way: I want concepts in trunk faster than I think we could get c++11 bootstrapping gcc working and set as default. I could be wrong - maybe c++11-bootstrap won't be that hard. As for flags. I vote for concepts switched on for -std=c++1y. As for -fconcepts turning on c++1y I'm less sure. We could allow concepts for C++11 (I don't think c++98 would work because of constexpr and maybe new template syntax). I hadn't thought about that. Personally I leave -std=c++14 and use all the things... ;-) I'm CCing Jason.
Re: Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier
> 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 the initializer-clause to match the structure exactly (or at least not omit any const initializers?) I think this was something Gaby wanted when we created the branch, but I'm not sure it's worth keeping because of the bootstrapping errors. I could reset the default dialect to 98 and turn on concepts iff 1y is enabled, or I could turn on 1y if -fconcepts is enabled. Thoughts? Andrew
Re: Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier
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 *look* like a regression caused by concepts -- I don't think I'm touching the initializer code at all. Andrew Sutton Andrew, I did a full 3-stage bootstrap which is the default these days. I'll try --disable-bootstrap and see what happens. In other news: I think the lvalue to bitfield issue is resolved in 4.9 and trunk. Note to self: Add a testcase for that if not done already. Ed
Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier
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 -- I don't
think I'm touching the initializer code at all.
Andrew Sutton
On Tue, Jun 24, 2014 at 11:42 AM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> 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
> ---
> static stringop_algs ix86_size_memcpy[2] = {
> {rep_prefix_1_byte, {{-1, rep_prefix_1_byte, false}}},
> {rep_prefix_1_byte, {{-1, rep_prefix_1_byte, false;
> static stringop_algs ix86_size_memset[2] = {
> {rep_prefix_1_byte, {{-1, rep_prefix_1_byte, false}}},
> {rep_prefix_1_byte, {{-1, rep_prefix_1_byte, false;
>
Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier
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
---
static stringop_algs ix86_size_memcpy[2] = {
{rep_prefix_1_byte, {{-1, rep_prefix_1_byte, false}}},
{rep_prefix_1_byte, {{-1, rep_prefix_1_byte, false;
static stringop_algs ix86_size_memset[2] = {
{rep_prefix_1_byte, {{-1, rep_prefix_1_byte, false}}},
{rep_prefix_1_byte, {{-1, rep_prefix_1_byte, false;
Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier
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/
-B/home/ed/bin_concepts/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/home/ed/obj_concepts/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/ed/obj_concepts/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/home/ed/obj_concepts/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/home/ed/obj_concepts/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/home/ed/gcc_concepts/libstdc++-v3/libsupc++
-L/home/ed/obj_concepts/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/ed/obj_concepts/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc_concepts/gcc
-I../../gcc_concepts/gcc/. -I../../gcc_concepts/gcc/../include
-I../../gcc_concepts/gcc/../libcpp/include -I/home/ed/obj_concepts/./gmp
-I/home/ed/gcc_concepts/gmp -I/home/ed/obj_concepts/./mpfr/src
-I/home/ed/gcc_concepts/mpfr/src -I/home/ed/gcc_concepts/mpc/src
-I../../gcc_concepts/gcc/../libdecnumber
-I../../gcc_concepts/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc_concepts/gcc/../libbacktrace -DCLOOG_INT_GMP
-I/home/ed/obj_concepts/./cloog/include
-I/home/ed/gcc_concepts/cloog/include -I../gcc_concepts/cloog/include
-I/home/ed/obj_concepts/./isl/include
-I/home/ed/gcc_concepts/isl/include -o i386.o -MT i386.o -MMD -MP -MF
./.deps/i386.TPo ../../gcc_concepts/gcc/config/i386/i386.c
../../gcc_concepts/gcc/config/i386/i386.c:113:56: error: uninitialized
const member ‘stringop_algs::stringop_strategy::max’
{rep_prefix_1_byte, {{-1, rep_prefix_1_byte, false;
^
../../gcc_concepts/gcc/config/i386/i386.c:113:56: error: missing
initializer for member ‘stringop_algs::stringop_strategy::max’
[-Werror=missing-field-initializers]
../../gcc_concepts/gcc/config/i386/i386.c:113:56: error: uninitialized
const member ‘stringop_algs::stringop_strategy::alg’
../../gcc_concepts/gcc/config/i386/i386.c:113:56: error: missing
initializer for member ‘stringop_algs::stringop_strategy::alg’
[-Werror=missing-field-initializers]
../../gcc_concepts/gcc/config/i386/i386.c:113:56: error: missing
initializer for member ‘stringop_algs::stringop_strategy::noalign’
[-Werror=missing-field-initializers]
Am I the only one seeing this?
Do you turn off the warning when you compile?
Ed
Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier
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
===
--- parser.c (revision 211591)
+++ parser.c (working copy)
@@ -15175,9 +15175,15 @@ cp_parser_allows_constrained_type_specif
static tree
cp_maybe_constrained_type_specifier (cp_parser *parser, tree decl, tree args)
{
- gcc_assert (TREE_CODE (decl) == OVERLOAD);
gcc_assert (args ? TREE_CODE (args) == TREE_VEC : true);
+ // If we get a reference to a member function, allow the referenced
+ // functions to participate in this resolution: the baselink may refer
+ // to a static member concept.
+ if (BASELINK_P (decl))
+decl = BASELINK_FUNCTIONS (decl);
+ gcc_assert (TREE_CODE (decl) == OVERLOAD);
+
// Don't do any heavy lifting if we know we're not in a context
// where it could succeed.
if (!cp_parser_allows_constrained_type_specifier (parser))
Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier
I saw this during bootstrap. I've verified that the patch works (I was working on similar). Ed
Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier
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 wrote: > 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 also caused > a test case in my next patch to fail. The solution is to check for a > BASELINK and extract the functions from it. > > The possibility of decl being a BASELINK is asserted near the call in > cp_parser_template_id (cp_maybe_partial_concept_id just calls the function > in question at this time). > > 2014-06-17 Braden Obrzut > * gcc/cp/parser.c (cp_maybe_constrained_type_specifier): Fix assertion > failure if baselink was passed in as decl. >
