[Bug c++/61182] Forming pointer to qualified function type

["jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> ---
8.3.5/6 says,

A function type with a cv-qualifier-seq or a ref-qualifier ... shall appear
only as:
— the function type for a non-static member function,
— the function type to which a pointer to member refers,
— the top-level function type of a function typedef declaration or
alias-declaration,
— the type-id in the default argument of a type-parameter (14.1), or
— the type-id of a template-argument for a type-parameter (14.3.1).

Which I read as meaning no (non-member) pointers to such a type.
>From gcc-bugs-return-451563-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 14 05:04:40 2014
Return-Path: <gcc-bugs-return-451563-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2534 invoked by alias); 14 May 2014 05:04:40 -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 2454 invoked by uid 48); 14 May 2014 05:04:32 -0000
From: "quantheory at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/60928] gfortran issue with allocatable components and OpenMP
Date: Wed, 14 May 2014 05:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.3
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: quantheory at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60928-4-IQiRYkDsBx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60928-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60928-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: 2014-05/txt/msg01255.txt.bz2
Content-length: 1949

https://gcc.gnu.org/bugzilla/show_bug.cgi?id`928

--- Comment #3 from Sean Santos <quantheory at gmail dot com> ---
OpenMP 4.0 is strange. Sure, it does refer to "allocatable enhancement" as an
unsupported feature, which is vague. It might refer to the TR unofficially
known as the "Allocatable Enhancements" update, or it might refer to everything
at all that changed between 95 and 2003, or it might just be meant as a
disclaimer that some allocatable changes may not be covered. But at the same
time, OpenMP 4.0 contains an update that specifically discusses in the test
case I gave.

The language in OpenMP 4.0 (page 160):


'For a list item or the subobject of a list item with the ALLOCATABLE
attribute:

- if the allocation status is "not currently allocated", the new list item or
the subobject of the new list item will have an initial allocation status of
"not currently allocated";

- if the allocation status is "currently allocated", the new list item or the
subobject of the new list item will have an initial allocation status of
"currently allocated". If the new list item or the subobject of the new list
item is an array, its bounds will be the same as those of the original list
item or the subobject of the original list item.'


In comparison, the first line of the same section in OpenMP 3.1 (page 97):

'For a list item with the ALLOCATABLE attribute:'


There are other, similar lines that are changed throughout the standard. To me,
this seems like a specific statement of how to handle allocatable components,
which is new in OpenMP 4.0, and is more explicit than the vague statement about
unsupported features at the top of the standard.

However, if you disagree and think that this is not part of the standard, I'd
like to suggest it as a reasonable enhancement anyway, since I would assert
that there is only one reasonable behavior here, and most other Fortran
compilers (notably excepting ifort) act the same way.