[Bug c++/65575] New: [c++-concepts] Parse error for requires clause on functions that return a reference type

[Bug c++/65575] New: [c++-concepts] Parse error for requires clause on functions that return a reference type

[tom at honermann dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575

            Bug ID: 65575
           Summary: [c++-concepts] Parse error for requires clause on
                    functions that return a reference type
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tom at honermann dot net

Encountered with the latest revision of the gcc c++-concepts branch (r221681). 
Parse errors are issued for function declarations that specify a requires
clause and return a reference type.  The parse error occurs whether the
function return type is specifed with a trailing return type or not.  The error
occurs for member functions as well as non-member functions.

A test case follows.  Changing the return type of f() from int& to just int
avoids the error.  Replacing the return type with a type alias for int& also
avoids the problem.

$ svn info   # From my local svn gcc repo.
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 221681
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 221669
Last Changed Date: 2015-03-25 14:07:42 -0400 (Wed, 25 Mar 2015)

$ cat t.cpp 
template<typename T>
concept bool C = true;
auto f() -> int& requires C<int>;

$ g++ -c -std=c++1z t.cpp
t.cpp:3:16: error: requires clause after non-function declaration
 auto f() -> int& requires C<int>;
                ^

[Bug c++/65575] [c++-concepts] Parse error for requires clause on functions that return a reference type

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575

--- Comment #1 from Andrew Sutton <andrew.n.sutton at gmail dot com> ---
Confirmed and resolved in r221695. 

Removed the check for trailing requires-clauses on non-function declarators.
This should make the presence of a trailing-requires clause in a context where
it doesn't belong a syntax error (expected 'XXX', but got 'requires', for
example).

[Bug c++/65575] [c++-concepts] Parse error for requires clause on functions that return a reference type

[tom at honermann dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575

--- Comment #2 from Tom Honermann <tom at honermann dot net> ---
r221695 does correct the specific test case in comment 0.  However, I'm still
seeing similar errors for function declarations that don't specify the return
type with a trailing return type:

$ svn info   # From my local svn gcc repo.
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 221697
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 221695
Last Changed Date: 2015-03-26 09:35:54 -0400 (Thu, 26 Mar 2015)

$ cat t2.cpp 
template<typename T>
concept bool C = true;
int& f() requires C<int>;

$ g++ -c -std=c++1z t2.cpp 
t2.cpp:3:10: error: expected initializer before ‘requires’
 int& f() requires C<int>;
          ^
>From gcc-bugs-return-481940-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 27 04:03:05 2015
Return-Path: <gcc-bugs-return-481940-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 114649 invoked by alias); 27 Mar 2015 04:03:05 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 114556 invoked by uid 55); 27 Mar 2015 04:03:02 -0000
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
Date: Fri, 27 Mar 2015 07:13:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65076-4-xZEcdZluNw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65076-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65076-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg03084.txt.bz2
Content-length: 613

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide076

--- Comment #24 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Fri Mar 27 04:02:28 2015
New Revision: 221719

URL: https://gcc.gnu.org/viewcvs?rev"1719&root=gcc&view=rev
Log:

    PR ipa/65076
    * passes.def: Add pass_nothrow.
    * ipa-pure-const.c: (pass_data_nothrow): New.
    (pass_nothrow): New.
    (pass_nothrow::execute): New.
    (make_pass_nothrow): New.
    * tree-pass.h (make_pass_nothrow): Declare.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-pure-const.c
    trunk/gcc/passes.def
    trunk/gcc/tree-pass.h

[Bug c++/65575] [c++-concepts] Parse error for requires clause on functions that return a reference type

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575

--- Comment #3 from Andrew Sutton <andrew.n.sutton at gmail dot com> ---
Created attachment 35163
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35163&action=edit
Patch applied in r221733

[Bug c++/65575] [c++-concepts] Parse error for requires clause on functions that return a reference type

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575

--- Comment #4 from Andrew Sutton <andrew.n.sutton at gmail dot com> ---
Apparently I do not understand declarators. The attached patch searches through
the declarator structure to filter out declarator structures to which a
requires-clause cannot be attached.

I updated the pr665575.C test to include more examples (positive and negative),
but that's not reflected in the attached patch. I haven't been able to test as
thoroughly as I'd like because I'm at the airport, but this seems like the
right thing to do.

[Bug c++/65575] [c++-concepts] Parse error for requires clause on functions that return a reference type

[tom at honermann dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575

--- Comment #5 from Tom Honermann <tom at honermann dot net> ---
r221733 seems to address the case in comment 2 for me.

I have one more for you.  This one is a little different (no return type
involved), so let me know if you want me to open a different bug for it.

$ cat t3.cpp 
struct S {
    S() = default requires true;
};

$ svn info   # From my local svn gcc repo.
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 221742
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 221733
Last Changed Date: 2015-03-27 10:44:22 -0400 (Fri, 27 Mar 2015)

$ g++ -c -std=c++1z t3.cpp 
t3.cpp:2:11: error: expected ‘;’ at end of member declaration
     S() = default requires true;
           ^
t3.cpp:2:19: error: expected unqualified-id before ‘requires’
     S() = default requires true;
                   ^
>From gcc-bugs-return-482110-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 27 20:13:46 2015
Return-Path: <gcc-bugs-return-482110-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 53912 invoked by alias); 27 Mar 2015 20:13:45 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 53709 invoked by uid 48); 27 Mar 2015 20:13:40 -0000
From: "wschmidt at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65456] powerpc64le autovectorized copy loop missed optimization
Date: Fri, 27 Mar 2015 21:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: wschmidt at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: wschmidt at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65456-4-JSTPvCAx4t@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65456-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65456-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg03254.txt.bz2
Content-length: 1132

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide456

--- Comment #12 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
The problem is this declaration in rs6000.h, which forces unaligned vector
stores to be scalarized during expand:

/* Define this macro to be the value 1 if unaligned accesses have a cost
   many times greater than aligned accesses, for example if they are
   emulated in a trap handler.  */
/* Altivec vector memory instructions simply ignore the low bits; SPE vector
   memory instructions trap on unaligned accesses; VSX memory instructions are
   aligned to 4 or 8 bytes.  */
#define SLOW_UNALIGNED_ACCESS(MODE, ALIGN)                              \
  (STRICT_ALIGNMENT                                                     \
   || (((MODE) == SFmode || (MODE) == DFmode || (MODE) == TFmode        \
        || (MODE) == SDmode || (MODE) == DDmode || (MODE) == TDmode)    \
       && (ALIGN) < 32)                                                 \
   || (VECTOR_MODE_P ((MODE)) && (((int)(ALIGN)) < VECTOR_ALIGN (MODE))))

The last condition needs to be relaxed for POWER8 hardware.

[Bug c++/65575] [c++-concepts] Parse error for requires clause on functions that return a reference type

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575

--- Comment #6 from Andrew Sutton <andrew.n.sutton at gmail dot com> ---
The requires-clause comes before the = default (the = xxx) is considered part
of the function definition. So:

  void f() requires true = default;


As a side note, the production following the requires-clause is a
logical-or-expression, so the '=' would not be interpreted as part of the
constraint.

But I don't think there are test cases for that.

If you find a problem, please open a new issue.

[Bug c++/65575] [c++-concepts] Parse error for requires clause on functions that return a reference type

[tom at honermann dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575

Tom Honermann <tom at honermann dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Tom Honermann <tom at honermann dot net> ---
(In reply to Andrew Sutton from comment #6)
> The requires-clause comes before the = default (the = xxx) is considered
> part of the function definition. So:
> 
>   void f() requires true = default;

Ah, thank you.  The syntax I used is accepted by a long ago built gcc revision
(r211824) (and that old build doesn't accept the syntax above).

Closing this bug as resolved/fixed as of r221733.  Thank you!