Bug 38907 - [4.3 Regression ] ICE when contained function has same name as module function and used in expression
Summary: [4.3 Regression ] ICE when contained function has same name as module functio...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.4.0
: P4 normal
Target Milestone: 4.3.4
Assignee: Paul Thomas
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2009-01-18 21:21 UTC by Dick Hendrickson
Modified: 2009-01-26 06:16 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.2.5 4.3.1
Known to fail: 4.3.3 4.4.0
Last reconfirmed: 2009-01-18 21:44:29


Attachments
A patch for the PR (2.02 KB, patch)
2009-01-19 23:08 UTC, Paul Thomas
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dick Hendrickson 2009-01-18 21:21:25 UTC
The following program gives an internal compiler error.  If the line
RDA = -1 is commented out, there is a different ICE.  If the unary +
before the function reference in the assignment to RDA(1,2) is removed
the ICE goes away.

Dick Hendrickson


      module sa0054_stuff

! fails on Windows XP
! gcc version 4.4.0 20081219 (experimental) [trunk revision 142842] (GCC)

      contains

      PURE FUNCTION S_REAL_SUM_I (A,B)
      REAL  ::  S_REAL_SUM_I
      REAL, INTENT(IN), OPTIONAL  ::  A,B
      X = 0
      S_REAL_SUM_I = X

      END FUNCTION S_REAL_SUM_I

      SUBROUTINE SA0054(RDA, NF10,nf1,nf2,nf3,nf4)
      REAL RDA(NF10,NF10)

      RDA    = -1                  !changes ICE if commented out

          RDA(1,2) = + S_REAL_SUM_I(1.0,2.0)

!         RDA(1,2) =   S_REAL_SUM_I(1.0,2.0)     !This one works

      CONTAINS

      PURE FUNCTION S_REAL_SUM_I (A,B)
      REAL  ::  S_REAL_SUM_I
      REAL, INTENT(IN), OPTIONAL  ::  A,B
      S_REAL_SUM_I = 0
      END FUNCTION S_REAL_SUM_I

      END SUBROUTINE

      end module sa0054_stuff
 

With RDA = -1
C:\gfortran>gfortran try_sa0054.f
f951.exe: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


With RDA = -1 commented out
C:\gfortran>gfortran try_sa0054.f
f951.exe: internal compiler error: in check_host_association, at fortran/resolve
.c:4369
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Comment 1 kargl 2009-01-18 21:44:28 UTC
Confirmed for both ICEs.
Comment 2 kargl 2009-01-18 21:47:04 UTC
Both variations of the program work with 4.2.5, so this is
a regression.
Comment 3 Tobias Burnus 2009-01-18 22:27:54 UTC
Confirm. Thanks for the report!

Valgrind shows:

==20941== Conditional jump or move depends on uninitialised value(s)
==20941==    at 0x46C602: gfc_resolve_expr (resolve.c:4353)
==20941==    by 0x46BC22: gfc_resolve_expr (resolve.c:3057)
==20941==    by 0x472944: resolve_code (resolve.c:6676)

==20941== Use of uninitialised value of size 8
==20941==    at 0x46C608: gfc_resolve_expr (resolve.c:4353)

==20941== Invalid read of size 8
==20941==    at 0x46C608: gfc_resolve_expr (resolve.c:4353)

That line is:

  4349            gfc_match_rvalue (&expr);
  4350            gfc_clear_error ();
  4351            gfc_buffer_error (0);
  4352
  4353            gcc_assert (expr && sym == expr->symtree->n.sym);

I added some debug printfs and valgrind shows invalid reads for:
  expr == NULL
and
  expr->symtree
where the latter results in a segfault.

I think the problem occurs if gfc_match_rvalue does not match. Then the argument "&expr" will remain unmodified.

If one applies the following patch, the compilation will fail with the bogus error

          RDA(1,2) = + S_REAL_SUM_I(1.0,2.0)
                                   1
Error: Unclassifiable statement at (1)


--- resolve.c   (Revision 143486)
+++ resolve.c
@@ -4348,3 +4348,4 @@ check_host_association (gfc_expr *e)
    only integers and vectors can be involved.  */
-         gfc_match_rvalue (&expr);
+         if (gfc_match_rvalue (&expr) == MATCH_YES)
+           {
          gfc_clear_error ();
@@ -4359,2 +4360,3 @@ check_host_association (gfc_expr *e)
          gfc_current_locus = temp_locus;
+           }
        }
Comment 4 Mikael Morin 2009-01-19 22:33:49 UTC
This removes the ICE:

Index: primary.c
===================================================================
--- primary.c	(révision 143501)
+++ primary.c	(copie de travail)
@@ -2370,6 +2370,8 @@
   bool implicit_char;
   gfc_ref *ref;
 
+  where = gfc_current_locus;
+
   m = gfc_match_name (name);
   if (m != MATCH_YES)
     return m;
@@ -2385,7 +2387,6 @@
 
   sym = symtree->n.sym;
   e = NULL;
-  where = gfc_current_locus;
 
   /* If this is an implicit do loop index and implicitly typed,
      it should not be host associated.  */
Comment 5 Dominique d'Humieres 2009-01-19 22:39:55 UTC
> This removes the ICE: ...

Do you understand why?
Comment 6 Paul Thomas 2009-01-19 23:08:33 UTC
Created attachment 17148 [details]
A patch for the PR

This regtests and bootstraps on FC9/x86_i64.  I'll do ChangeLogs and so on tomorrow.

Thanks for the report, Dick!

Paul
Comment 7 Mikael Morin 2009-01-20 19:48:27 UTC
(In reply to comment #5)
> > This removes the ICE: ...
> 
> Do you understand why?
> 
In the following:
          RDA(1,2) = + S_REAL_SUM_I(1.0,2.0)

gfc_match_rvalue sets where for the rhs to the marked position below:
          RDA(1,2) = + S_REAL_SUM_I(1.0,2.0)
                                   ^
check_host_association (before Paul's patch) calls gfc_match_rvalue again starting at the e->where position (which is wrong). The match fails and there is no code to handle it as it is unexpected. 

With my patch where is set at the beginning of the function name, permitting proper match. This patch is needed I think, independently of Paul's one. For 4.5 if I don't forget about it. 
Comment 8 Paul Thomas 2009-01-20 21:57:01 UTC
Subject: Bug 38907

Author: pault
Date: Tue Jan 20 21:56:49 2009
New Revision: 143530

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143530
Log:
2009-01-20  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/38907
	* resolve.c (check_host_association): Remove the matching to
	correct an incorrect host association and use manipulation of
	the expression instead.

2009-01-20  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/38907
	* gfortran.dg/host_assoc_function_7.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/host_assoc_function_7.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog

Comment 9 Paul Thomas 2009-01-20 21:59:17 UTC
Fixed on trunk

Thanks for the report.

Paul
Comment 10 Paul Thomas 2009-01-26 06:15:53 UTC
Subject: Bug 38907

Author: pault
Date: Mon Jan 26 06:15:41 2009
New Revision: 143671

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143671
Log:
2009-01-26  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/38907
	Backport from trunk
	* resolve.c (check_host_association): Remove the matching to
	correct an incorrect host association and use manipulation of
	the expression instead.

2009-01-26  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/38907
	Backport from trunk
	* gfortran.dg/host_assoc_function_7.f90: New test.

Added:
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_function_7.f90
Modified:
    branches/gcc-4_3-branch/gcc/fortran/ChangeLog
    branches/gcc-4_3-branch/gcc/fortran/resolve.c
    branches/gcc-4_3-branch/gcc/testsuite/ChangeLog

Comment 11 Paul Thomas 2009-01-26 06:16:33 UTC
Fixed on trunk and 4.3

Thanks for the report and thanks to Mikael for the fix.

Paul