From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17380 invoked by alias); 14 May 2014 03:12:46 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 17306 invoked by uid 48); 14 May 2014 03:12:41 -0000 From: "jason at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/61182] Forming pointer to qualified function type Date: Wed, 14 May 2014 03:12:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jason at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED 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: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-05/txt/msg01254.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D61182 --- Comment #5 from Jason Merrill --- 8.3.5/6 says, A function type with a cv-qualifier-seq or a ref-qualifier ... shall appear only as: =E2=80=94 the function type for a non-static member function, =E2=80=94 the function type to which a pointer to member refers, =E2=80=94 the top-level function type of a function typedef declaration or alias-declaration, =E2=80=94 the type-id in the default argument of a type-parameter (14.1), or =E2=80=94 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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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=60928 --- Comment #3 from Sean Santos --- 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.