Re: Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

Re: Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

[Ed Smith-Rowland]

 
 

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: Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

[Andrew Sutton]

> 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: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

[Ed Smith-Rowland]

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: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

[Jason Merrill]

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

[Jason Merrill]

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

[Ed Smith-Rowland]

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

[Jason Merrill]

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

[Ed Smith-Rowland]

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

[Jason Merrill]

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

[Ed Smith-Rowland]

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

[Andrew Sutton]

[-- Attachment #1: Type: text/plain, Size: 290 bytes --]

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 <3dw4rd@verizon.net> wrote:
> I saw this during bootstrap.  I've verified that the patch works (I was
> working on similar).
>
> Ed
>

[-- Attachment #2: baselink-fix-2.patch --]
[-- Type: text/x-patch, Size: 863 bytes --]

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

[Ed Smith-Rowland]

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

[Ed Smith-Rowland]

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

[Andrew Sutton]

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 <3dw4rd@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}}}};
>

[c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

[Braden Obrzut]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

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  <admin@maniacsvault.net>
     * gcc/cp/parser.c (cp_maybe_constrained_type_specifier): Fix assertion
     failure if baselink was passed in as decl.


[-- Attachment #2: baselink-fix.diff --]
[-- Type: text/x-patch, Size: 479 bytes --]

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 1eaf863..40d1d63 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -15175,6 +15175,9 @@ cp_parser_allows_constrained_type_specifier (cp_parser *parser)
 static tree
 cp_maybe_constrained_type_specifier (cp_parser *parser, tree decl, tree args)
 {
+  if (BASELINK_P (decl))
+    decl = BASELINK_FUNCTIONS (decl);
+
   gcc_assert (TREE_CODE (decl) == OVERLOAD);
   gcc_assert (args ? TREE_CODE (args) == TREE_VEC : true);
 

Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

[Andrew Sutton]

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 <admin@maniacsvault.net> 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  <admin@maniacsvault.net>
>     * gcc/cp/parser.c (cp_maybe_constrained_type_specifier): Fix assertion
>     failure if baselink was passed in as decl.
>