Bug 34861 - ICE in function with entry (and result?)
Summary: ICE in function with entry (and result?)
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2008-01-18 22:59 UTC by Dick Hendrickson
Modified: 2008-01-20 17:07 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.1.3 4.2.2 4.3.0
Last reconfirmed: 2008-01-18 23:53:05


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dick Hendrickson 2008-01-18 22:59:33 UTC
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
Comment 1 Dominique d'Humieres 2008-01-18 23:32:42 UTC
Confirmed on i686-apple-darwin9, rev. 131629 (trunk) and gfortran 4.2.2.

Comment 2 Tobias Burnus 2008-01-19 18:09:14 UTC
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.
Comment 3 Dominique d'Humieres 2008-01-19 18:42:13 UTC
Is really "SIZE(IDA2,NF3)" done on purpose? or is this a typo for "SIZE(IDA2,3)"? It does not change the ICE AFAICT.

Comment 4 Dick Hendrickson 2008-01-20 01:21:12 UTC
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.
>
Comment 5 Paul Thomas 2008-01-20 16:59:04 UTC
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

Comment 6 Paul Thomas 2008-01-20 17:07:23 UTC
Fixed on trunk - thanks for the report.

Paul