Bug 19926 - [4.0 only] Incorrect rank with PARAMETER and array element.
Summary: [4.0 only] Incorrect rank with PARAMETER and array element.
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.0.2
Assignee: Not yet assigned to anyone
URL:
Keywords: patch, rejects-valid
: 20334 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-02-12 16:24 UTC by Steve Kargl
Modified: 2005-07-08 21:26 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.1.0
Known to fail:
Last reconfirmed: 2005-02-12 16:51:12


Attachments
p.diff (335 bytes, text/plain)
2005-06-11 05:59 UTC, Steve Kargl
Details
pr19926.f90 (210 bytes, text/plain)
2005-06-11 05:59 UTC, Steve Kargl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Kargl 2005-02-12 16:24:06 UTC
From Richard Maine, editor of the F2003 standard

    subroutine string_comp
       integer, parameter :: map(0:50) = 0
       integer :: i
       i = map(42)
    end subroutine string_comp

    In file bug2.f90:4

       i = map(42)
           1
    Error: Incompatible ranks 0 and 1 in assignment at (1)

    Note that it works without the parameter attribute.
Comment 1 Andrew Pinski 2005-02-12 16:51:12 UTC
Confirmed.
Comment 2 Toon Moene 2005-03-12 12:57:08 UTC
*** Bug 20334 has been marked as a duplicate of this bug. ***
Comment 3 Erik Edelmann 2005-06-10 23:35:16 UTC
This patch seems to fixe the bug:

Index: gcc/fortran/primary.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/fortran/primary.c,v
retrieving revision 1.22.2.3
diff -u -p -r1.22.2.3 primary.c
--- gcc/fortran/primary.c       25 Apr 2005 00:09:14 -0000      1.22.2.3
+++ gcc/fortran/primary.c       10 Jun 2005 23:17:45 -0000
@@ -1804,7 +1804,10 @@ gfc_match_rvalue (gfc_expr ** result)
     case FL_PARAMETER:
       if (sym->value
          && sym->value->expr_type != EXPR_ARRAY)
-       e = gfc_copy_expr (sym->value);
+        {
+         e = gfc_copy_expr (sym->value);
+         e->rank = 0;
+        }
       else
        {
          e = gfc_get_expr ();

However, I suspect that this patch only hides the real problem instead of
solving it.  I'll have to investigate it some more before I send the patch for
review/committing.
Comment 4 Steve Kargl 2005-06-11 05:59:31 UTC
Subject: Re:  Incorrect rank with PARAMETER and array element.

On Fri, Jun 10, 2005 at 11:35:17PM -0000, eedelman at acclab dot helsinki dot fi wrote:
> 
> This patch seems to fixe the bug:

(patch elided)

> However, I suspect that this patch only hides the real problem instead of
> solving it.  I'll have to investigate it some more before I send the patch for
> review/committing.

I tested the attached patch, which is equivalent to Erik's
patch with the exception that I remove an unnecesary \n in
the conditional of the if ().

I've also attached a test case.  If no one has any objections,
I'll apply the patch after my current regression test completes.

Comment 5 Steve Kargl 2005-06-11 05:59:32 UTC
Created attachment 9065 [details]
p.diff
Comment 6 Steve Kargl 2005-06-11 05:59:32 UTC
Created attachment 9066 [details]
pr19926.f90
Comment 7 Erik Edelmann 2005-06-11 09:39:12 UTC
(In reply to comment #4) 
> I tested the attached patch, which is equivalent to Erik's
> patch with the exception that I remove an unnecesary \n in
> the conditional of the if ().
> 
> I've also attached a test case.  If no one has any objections,
> I'll apply the patch after my current regression test completes.

Just to elaborate on what I meant with suspecting thet the patch only hides the
problem instead of solving it.

One thing that slightly worries my is, why isn't e->rank zero by itself?  If you
make string_comp in the fortran code a PROGRAM instead of SUBROUTINE, e->rank
_is_ zero (even without the patch).  I feel there is something fishy going on,
and I don't feel completely comfortable with the patch before I know what it is.
Comment 8 Erik Edelmann 2005-06-11 12:43:53 UTC
(In reply to comment #7) 
> One thing that slightly worries my is, why isn't e->rank zero by itself?  If you
> make string_comp in the fortran code a PROGRAM instead of SUBROUTINE, e->rank
> _is_ zero (even without the patch).  I feel there is something fishy going on,
> and I don't feel completely comfortable with the patch before I know what it is.

Ok, I've messed up a bit -- when I changed SUBROUTINE to PROGRAM, I did some
other changes to the code as well.  Apperantly, it was one of those other
changes that made it work.  I have no objections against applying the patch.
Comment 9 Steve Kargl 2005-06-11 13:49:03 UTC
Subject: Re:  Incorrect rank with PARAMETER and array element.

On Sat, Jun 11, 2005 at 09:39:13AM -0000, eedelman at acclab dot helsinki dot fi wrote:
> 
> Just to elaborate on what I meant with suspecting thet the patch only hides the
> problem instead of solving it.
> 
> One thing that slightly worries my is, why isn't e->rank zero by itself?

You might be right that this is papering over the true bug.

The code looks like 

  case FL_PARAMETER:
    if (sym->value && sym->value->expr_type != EXPR_ARRAY)
      {
         e = gfc_copy_expr (sym->value);
         e->rank = 0;
      }

e = gfc_copy_expr (sym->value) literally copies the sym->value expression
node into the e expression node.  sym->value->rank is 1.  We've probably
kludged around the bug by setting e->rank = 0.  So, how do we get here.
sym->value->expr_type == EXPR_CONSTANT because of PARAMETER in "REAL,
PARAMETER :: map(0:50) = 0".  I'll look at this sometime today.

Comment 10 kargl 2005-06-13 01:49:25 UTC
New patch.

http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01088.html
Comment 11 CVS Commits 2005-06-18 18:16:31 UTC
Subject: Bug 19926

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	kargl@gcc.gnu.org	2005-06-18 18:16:22

Modified files:
	gcc/fortran    : ChangeLog primary.c 

Log message:
	PR fortran/19926
	* primary.c (gfc_match_rvalue):  expr_type can be EXPR_CONSTANT
	for an array; check that sym->as is NULL.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.465&r2=1.466
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/primary.c.diff?cvsroot=gcc&r1=1.25&r2=1.26

Comment 12 kargl 2005-06-18 18:20:55 UTC
Fixed in 4.1.  I close this when I commit to 4.0.2.
Comment 13 CVS Commits 2005-06-18 18:27:14 UTC
Subject: Bug 19926

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	kargl@gcc.gnu.org	2005-06-18 18:27:06

Modified files:
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gfortran.dg: pr19926.f90 

Log message:
	PR fortran/19926
	* gfortran.dg/pr19926.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5653&r2=1.5654
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr19926.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1

Comment 14 CVS Commits 2005-07-08 21:19:41 UTC
Subject: Bug 19926

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	kargl@gcc.gnu.org	2005-07-08 21:19:28

Modified files:
	gcc/fortran    : ChangeLog intrinsic.c match.c primary.c 
	                 trans-array.c trans-array.h trans-decl.c 
	                 trans-stmt.c 

Log message:
	Backport from the mainline:
	PR fortran/21257
	(port from g95)
	* match.c (gfc_match_label): Detect duplicate labels.
	* gfortran.dg/duplicate_labels.f90: New test.
	
	PR fortran/19926
	* primary.c (gfc_match_rvalue):  expr_type can be EXPR_CONSTANT
	for an array; check that sym->as is NULL.
	* gfortran.dg/pr19926.f90: New test.
	
	PR fortran/17792
	PR fortran/21375
	* trans-array.c (gfc_array_deallocate): pstat is new argument
	(gfc_array_allocate): update gfc_array_deallocate() call.
	(gfc_trans_deferred_array): ditto.
	* trans-array.h: update gfc_array_deallocate() prototype.
	* trans-decl.c (gfc_build_builtin_function_decls): update declaration
	* trans-stmt.c (gfc_trans_deallocate): Implement STAT= feature.
	
	* intrinsic.c (gfc_intrinsic_func_interface): Enable errors for generic
	functions whose simplification routine return FAILURE.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.76&r2=1.335.2.77
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/intrinsic.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.44.2.3&r2=1.44.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.31.8.7&r2=1.31.8.8
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/primary.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.22.2.4&r2=1.22.2.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.39.2.5&r2=1.39.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.7.18.1&r2=1.7.18.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.54.2.3&r2=1.54.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-stmt.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.24.6.5&r2=1.24.6.6

Comment 16 kargl 2005-07-08 21:26:05 UTC
Back ported to 4.0