Bug 21177 - wrong code with NULL()
Summary: wrong code with NULL()
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.0.1
Assignee: Not yet assigned to anyone
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords: patch, wrong-code
Depends on:
Blocks:
 
Reported: 2005-04-23 13:45 UTC by Joost VandeVondele
Modified: 2005-04-27 15:44 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-04-23 22:07:59

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Joost VandeVondele 2005-04-23 13:45:24 UTC 
The following should not abort:

MODULE MYMOD
INTERFACE TT
MODULE PROCEDURE TT_I,TT_R
END INTERFACE TT
CONTAINS
FUNCTION TT_I(X) RESULT(I)
  INTEGER :: I
  INTEGER,POINTER :: X
  I=1
END FUNCTION
FUNCTION TT_R(X) RESULT(I)
  INTEGER :: I
  REAL,POINTER :: X
  I=2
END FUNCTION
END MODULE MYMOD

USE MYMOD
REAL, POINTER :: R
INTEGER, POINTER :: I
INTEGER :: K
IF (TT(I).NE.1) CALL ABORT()
IF (TT(R).NE.2) CALL ABORT()
IF (TT(NULL(I)).NE.1) CALL ABORT()
IF (TT(NULL(R)).NE.2) CALL ABORT()
END
Comment 1 Andrew Pinski 2005-04-23 15:20:54 UTC 
Confirmed, the real version is being called for both of the NULL()'s.
Comment 2 Francois-Xavier Coudert 2005-04-23 22:07:57 UTC 
In interface.c, we use compare_parameter to match an actual argument to
one of the formal arguments. The type is used to determine which member
of the interface (tt_r or tt_i) we will call.

Unfortunately, compare_parameter has a special case for EXPR_NULL:

  if (actual->expr_type != EXPR_NULL
      && !gfc_compare_types (&formal->ts, &actual->ts))
    return 0;

That is: actual and formal arguments match if they have the same type,
unless the are NULL, in which case they always match (and the member of
the interface chosen for execution is the first one in the list, which in
the case of this PR is TT_R).

I'm not sure whether this restriction should be completely lifted, since
there must have been a reason why it was here in the first place...
Comment 3 Francois-Xavier Coudert 2005-04-24 10:59:23 UTC 
This test was introduced to fix PR 12841. Something more subtle is needed
(maybe, check not only for EXPR_NULL, but for EXPR_NULL with no type?).
Comment 4 Francois-Xavier Coudert 2005-04-24 13:06:31 UTC 
Found a patch (after a good night's sleep, it seemed to easy!):

Instead of 
  if (actual->expr_type != EXPR_NULL
      && !gfc_compare_types (&formal->ts, &actual->ts))
    return 0;
we need to use
  if ((actual->expr_type != EXPR_NULL ||
       actual->ts.type != BT_UNKNOWN)
      && !gfc_compare_types (&formal->ts, &actual->ts))
    return 0;

I'm regtesting it right now, and will post it in good form on monday (internet
dial-up access problems).
Comment 5 Andrew Pinski 2005-04-25 13:31:15 UTC 
Patch was posted.
Comment 6 GCC Commits 2005-04-27 15:38:22 UTC 
Subject: Bug 21177

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	fxcoudert@gcc.gnu.org	2005-04-27 15:37:55

Modified files:
	gcc/fortran    : ChangeLog interface.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gfortran.dg: pr21177.f90 

Log message:
	PR fortran/21177
	
	* interface.c (compare_parameter): Ignore type for EXPR_NULL
	only if type is BT_UNKNOWN.
	
	* gfortran.dg/pr21177.f90: New test

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.406&r2=1.407
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/interface.c.diff?cvsroot=gcc&r1=1.17&r2=1.18
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5405&r2=1.5406
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr21177.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
Comment 8 Francois-Xavier Coudert 2005-04-27 15:44:50 UTC 
Fixed.