http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58099 --- Comment #13 from janus at gcc dot gnu.org --- (In reply to janus from comment #12) > (In reply to Tobias Burnus from comment #10) > > (In reply to janus from comment #7) > > > The following patch makes the error go away, but (as expected) causes a > > > failure of proc_ptr_result_8.f90 in the testsuite ... > > > - if (!gfc_compare_interfaces (s2, s1, name, 0, 1, > > > - err, sizeof(err), NULL, NULL)) > > > - { > > > - gfc_error ("Interface mismatch in procedure pointer assignment " > > > - "at %L: %s", &rvalue->where, err); > > > - return false; > > > - } > > > > > > Doesn't that remove too much? I had expected some special case for PURE, > > while checking otherwise that the interface matches. > > No, I don't think it removes too much. It seems that the other parts of > 'gfc_compare_interfaces' are already symmetrized appropriately, expect for > the check on the result characteristics. Here is another recent example where more symmetrization was done (this time in check_dummy_characteristics): http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=199375 In case we need more symmetrization, it should be done 'locally'. Duplicate calls of gfc_compare_interfaces to symmetrize it are clearly wrong, as the case with PURE shows. >From gcc-bugs-return-427654-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Aug 10 14:31:58 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 29191 invoked by alias); 10 Aug 2013 14:31:57 -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 29127 invoked by uid 48); 10 Aug 2013 14:31:55 -0000 From: "mikael at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/44978] derived types are resolved more than once Date: Sat, 10 Aug 2013 14:31: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.6.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: mikael at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: janus at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created 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: 2013-08/txt/msg00578.txt.bz2 Content-length: 1210 http://gcc.gnu.org/bugzilla/show_bug.cgi?idD978 --- Comment #12 from Mikael Morin --- Created attachment 30630 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id0630&actioníit Janus' patch with void functions (In reply to janus from comment #11) > IMHO it is probably not worth the hassle. I wouldn't like to do this without > having a concrete reason for it (and with a clean testsuite I don't see any). > The reason is: the sym->resolved flag is an internal detail that should not be externally visible; it shouldn't change the return value. > > Well, the advantage of my original patch is obviously that it not only > avoids the double errors, but it also prevents us from doing double the work > in resolving the symbols, so it might even give a performance improvement > for large codes, in particular with heavy OOP (not sure if it's anywhere > close to being significant, though). All right, the only one solution left that I see is the one making the functions void. See the attached patch (comments welcome). I ran the testsuite partially on it and it was clean, but I don't have the time to finish that right now. It looked as slow as usual by the way. ;-)