[Bug fortran/34861] New: ICE in function with entry (and result?)

[Bug fortran/34861] New: ICE in function with entry (and result?)

[dick dot hendrickson at gmail dot com]

The following generates:
i_1_mods_bug.f:10.72:

      END FUNCTION
                                                                       1
Internal Error at (1):
gfc_compare_array_spec(): Array spec clobbered

 4.3.0 20080109 (experimental) [trunk revision 131426] (GCC)

It works fine if I delete all 3 ENTRY statements.  I don't know if the
RESULT clause is necessary or not.

Dick Hendrickson



      FUNCTION I_IMFUD0 ( IDA2 , NDS4, NDS3) RESULT(I_IMFUDP)
      INTEGER  ::   NDS4, NDS3
      INTEGER  ::   IDA2(5,NDS4,NDS3,2)
      INTEGER  ::   I_IMFUDP(SIZE(IDA2,1), SIZE(IDA2,2),
     $              SIZE(IDA2,NF3), SIZE(IDA2,4))
      ENTRY I_IMFUDX (NDS4, NDS3, IDA2) RESULT(I_IMFUDP)
      ENTRY I_IMFUDY (NDS3, NDS4, IDA2) RESULT(I_IMFUDP)
      ENTRY I_IMFUDZ (NDS3, IDA2, NDS4) RESULT(I_IMFUDP)
      I_IMFUDP = 1-IDA2(:,:,:,::NDS4-NDS3)
      END FUNCTION


-- 
           Summary: ICE in function with entry (and result?)
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dick dot hendrickson at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861

[Bug fortran/34861] ICE in function with entry (and result?)

[dominiq at lps dot ens dot fr]

------- Comment #1 from dominiq at lps dot ens dot fr  2008-01-18 23:32 -------
Confirmed on i686-apple-darwin9, rev. 131629 (trunk) and gfortran 4.2.2.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861

[Bug fortran/34861] ICE in function with entry (and result?)

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |32834
              nThis|                            |
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |ice-on-valid-code
      Known to fail|                            |4.1.3 4.2.2 4.3.0
   Last reconfirmed|0000-00-00 00:00:00         |2008-01-18 23:53:05
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861

[Bug fortran/34861] ICE in function with entry (and result?)

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2008-01-19 18:09 -------
It fails in array.c's
compare_bounds (gfc_expr *bound1, gfc_expr *bound2)
{
  if (bound1 == NULL || bound2 == NULL
      || bound1->expr_type != EXPR_CONSTANT
      || bound2->expr_type != EXPR_CONSTANT
      || bound1->ts.type != BT_INTEGER
      || bound2->ts.type != BT_INTEGER)
    gfc_internal_error ("gfc_compare_array_spec(): Array spec clobbered");

which is called in turn in gfc_compare_array_spec as:
  if (as1->type == AS_EXPLICIT)
    for (i = 0; i < as1->rank; i++)
      {
        if (compare_bounds (as1->lower[i], as2->lower[i]) == 0)
          return 0;

which is called by resolve.c's resolve_entries:

          else if (as && fas && gfc_compare_array_spec (as, fas) == 0)
            gfc_error ("Function %s at %L has entries with mismatched "
                       "array specifications", ns->entries->sym->name,
                       &ns->entries->sym->declared_at);

The problem is therefore that SIZE(IDA2,NF3) does not evaluate at compile time
to an integer, but that this is expected as the type is AS_EXPLICIT.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861

[Bug fortran/34861] ICE in function with entry (and result?)

[dominiq at lps dot ens dot fr]

------- Comment #3 from dominiq at lps dot ens dot fr  2008-01-19 18:42 -------
Is really "SIZE(IDA2,NF3)" done on purpose? or is this a typo for
"SIZE(IDA2,3)"? It does not change the ICE AFAICT.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861

[Bug fortran/34861] ICE in function with entry (and result?)

[dick dot hendrickson at gmail dot com]

------- Comment #4 from dick dot hendrickson at gmail dot com  2008-01-20 01:21 -------
Subject: Re:  ICE in function with entry (and result?)

Sorry, basically a typo on my part.  This is part of a large test suite and I
cut it down to a small case.  The "variable" NF3 has the value 3 and the
value is set in a way that the compiler shouldn't be able to use the
value in any optimizations.  You can either replace the NF3 by 3, add
NF3 to the argument list, or put the function in a module and declare
NF3 above the contains.

I try to run these small examples through another compiler as a check on
my typing skills.  This one clearly slipped by without the check.  I hope it
didn't cause too much trouble.

Dick Hendrickson

On 19 Jan 2008 18:42:13 -0000, dominiq at lps dot ens dot fr
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #3 from dominiq at lps dot ens dot fr  2008-01-19 18:42 -------
> Is really "SIZE(IDA2,NF3)" done on purpose? or is this a typo for
> "SIZE(IDA2,3)"? It does not change the ICE AFAICT.
>
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861

[Bug fortran/34861] ICE in function with entry (and result?)

[pault at gcc dot gnu dot org]

------- Comment #5 from pault at gcc dot gnu dot org  2008-01-20 16:59 -------
Subject: Bug 34861

Author: pault
Date: Sun Jan 20 16:58:15 2008
New Revision: 131679

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

        PR fortran/34861
        * resolve.c (resolve_entries): Do not do an array bounds check
        if the result symbols are the same.

        PR fortran/34854
        * module.c (read_module) : Hide the symtree of the previous
        version of the symbol if this symbol is renamed.

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

        PR fortran/34784
        * gfortran.dg/mapping_2.f90: Correct ubound expression for h4.

        PR fortran/34861
        * gfortran.dg/entry_array_specs_3.f90: New test.

        PR fortran/34854
        * gfortran.dg/use_rename_1.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/entry_array_specs_3.f90
    trunk/gcc/testsuite/gfortran.dg/use_rename_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/module.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/mapping_2.f90


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861

[Bug fortran/34861] ICE in function with entry (and result?)

[pault at gcc dot gnu dot org]

------- Comment #6 from pault at gcc dot gnu dot org  2008-01-20 17:07 -------
Fixed on trunk - thanks for the report.

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861