From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6635 invoked by alias); 13 Jan 2013 09:07:58 -0000 Received: (qmail 6614 invoked by uid 22791); 13 Jan 2013 09:07:57 -0000 X-SWARE-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-vb0-f44.google.com (HELO mail-vb0-f44.google.com) (209.85.212.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 13 Jan 2013 09:07:53 +0000 Received: by mail-vb0-f44.google.com with SMTP id fc26so2691896vbb.31 for ; Sun, 13 Jan 2013 01:07:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.106.133 with SMTP id x5mr19299672vco.61.1358068072017; Sun, 13 Jan 2013 01:07:52 -0800 (PST) Received: by 10.220.241.212 with HTTP; Sun, 13 Jan 2013 01:07:51 -0800 (PST) In-Reply-To: References: Date: Sun, 13 Jan 2013 09:07:00 -0000 Message-ID: Subject: Re: [Patch, fortran] PR54286 - [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result From: Paul Richard Thomas To: Janus Weil Cc: "fortran@gcc.gnu.org" , gcc-patches , Mikael Morin Content-Type: text/plain; charset=ISO-8859-1 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-01/txt/msg00653.txt.bz2 Dear Janus (and Dominique), Thanks for the review. I found that the symmetrization is necessary experimentally :-) I did not think anything of it, since I have encountered such asymmetries elsewhere in interface.c. When I have a quiet moment, I'll try to understand why this is necessary for this patch. Committed as r195133. Overnight, class_optional_2.f90 started failing at -Os. I double checked that this patch did not cause the regression. If somebody else does not beat me to it, I'll investigate tonight. Cheers Paul On 12 January 2013 20:35, Janus Weil wrote: > Hi Paul, > >> It is something of an exaggeration to say that this PR is a regession, >> although it is true that gcc-4.7 gives error messages for the testcase >> in the correct places. In fact, these messages disappear if IMPLICIT >> INTEGER (a) at the start of the testcase. >> >> The fix ensures that the interfaces are selected and checked >> symmetrically in gfc_compare_interfaces. >> >> The submitted testcase only checks the errors. The other tests in the >> testsuite adequately check the functionality of procedure pointer >> assignments. >> >> Bootstrapped and regtested on FC17/i86_64 - OK for trunk > > thanks for the patch. It looks mostly good to me. > > Just one question: Why is the symmetrization actually needed? I.e. in > what respect is 'gfc_compare_interfaces' asymmetric? I don't directly > see that. To the contrary, it seems to me that gfc_compare_interfaces > is (at least in parts) already symmetrized internally, as e.g. in: > > if (count_types_test (f1, f2, p1, p2) > || count_types_test (f2, f1, p2, p1)) > return 0; > if (generic_correspondence (f1, f2, p1, p2) > || generic_correspondence (f2, f1, p2, p1)) > return 0; > > Also, note that gfc_compare_interfaces is never really called in a > symmetrized fashion elsewhere. Would we need this symmetrization in > other places too? > > Cheers, > Janus > > > >> 2013-01-12 Paul Thomas >> >> PR fortran/54286 >> * expr.c (gfc_check_pointer_assign): Ensure that both lvalue >> and rvalue interfaces are presented to gfc_compare_interfaces. >> Simplify references to interface names by using the symbols >> themselves. Call gfc_compare_interfaces with s1 and s2 inter- >> changed to overcome the asymmetry of this function. Do not >> repeat the check for the presence of s1 and s2. >> >> 2013-01-12 Paul Thomas >> >> PR fortran/54286 >> * gfortran.dg/proc_ptr_result_8.f90 : New test. -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy