From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23355 invoked by alias); 10 Dec 2014 22:02:56 -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 23312 invoked by uid 48); 10 Dec 2014 22:02:52 -0000 From: "janus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/63674] procedure pointer and non/pure procedure Date: Wed, 10 Dec 2014 22:02: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.9.1 X-Bugzilla-Keywords: accepts-invalid X-Bugzilla-Severity: normal X-Bugzilla-Who: janus 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords bug_status cf_reconfirmed_on cc everconfirmed 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-12/txt/msg01203.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63674 janus at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed| |2014-12-10 CC| |janus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- (In reply to Valery Weber from comment #0) > the following code is compiling fine with 4.9.1, but shouldnt gcc complain > about calling a nonpure procedure from a pure one? It definitely should, and the problem also occurs with the 5.0 trunk. The part that checks for pureness in 'resolve_function' is apparently not applied to procedure-pointer components, but could e.g. be transferred to 'resolve_expr_ppc' like this: Index: gcc/fortran/resolve.c =================================================================== --- gcc/fortran/resolve.c (Revision 218598) +++ gcc/fortran/resolve.c (Arbeitskopie) @@ -6048,6 +6048,7 @@ static bool resolve_expr_ppc (gfc_expr* e) { gfc_component *comp; + const char *name = NULL; comp = gfc_get_proc_ptr_comp (e); gcc_assert (comp != NULL); @@ -6074,6 +6075,32 @@ resolve_expr_ppc (gfc_expr* e) if (!update_ppc_arglist (e)) return false; + if (!pure_function (e, &name)) + { + if (forall_flag) + { + gfc_error ("Reference to non-PURE function '%s' at %L inside a " + "FORALL %s", comp->name, &e->where, + forall_flag == 2 ? "mask" : "block"); + return false; + } + else if (gfc_do_concurrent_flag) + { + gfc_error ("Reference to non-PURE function '%s' at %L inside a " + "DO CONCURRENT %s", comp->name, &e->where, + gfc_do_concurrent_flag == 2 ? "mask" : "block"); + return false; + } + else if (gfc_pure (NULL)) + { + gfc_error ("Reference to non-PURE function '%s' at %L " + "within a PURE procedure", comp->name, &e->where); + return false; + } + + gfc_unset_implicit_pure (NULL); + } + gfc_ppc_use (comp, &e->value.compcall.actual, &e->where); return true; This is sufficient to trigger the right error for the test case, but more work needs to be done: 'pure_function' needs to be taught to handle PPCs and one needs to add a pureness check for procedure-pointer assignments. Finally it should be checked if the same problem also applies to 'ordinary' procedure pointers (which are not a type component) and to the case of subroutines (instead of functions).