User account creation filtered due to spam.

Bug 37411 - ICE (segfault) in trans-array.c
Summary: ICE (segfault) in trans-array.c
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 major
Target Milestone: ---
Assignee: Daniel Kraft
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2008-09-07 18:52 UTC by Kristján Jónasson
Modified: 2008-09-09 09:49 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.2.3 4.3.2 4.4.0
Last reconfirmed: 2008-09-09 07:56:33


Attachments
Regtested patch, including test case (960 bytes, patch)
2008-09-08 09:23 UTC, Tobias Burnus
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kristján Jónasson 2008-09-07 18:52:39 UTC
The following module file causes gfortran to give segmentation fault. Specifically, given the command "gfortran -c b1.f90" produces:

  b1.f90: In function 'sub':
  b1:12: internal compiler error: Segmentation fault

This happens with several different versions of the compiler (4.3.1, 4.3.0, 4.2.3, 4.2.1) on a few different platforms (cygwin, ubuntu linux, suse linux).

The module is compiled correctly by g95, nag f95, ifort and absoft af95.

Finally, here is the error producing file:

MODULE B1
CONTAINS
  subroutine sub()
    integer :: x(1)
    character(3) :: st
    st = fun(x)
  end subroutine sub

  function fun(x) result(st)
    integer, intent(in) :: x(1)
    character(lenf(x)) :: st
    st = 'abc'
  end function fun

  pure integer function lenf(x)
    integer, intent(in) :: x(1)
    lenf = x(1)
  end function lenf
END MODULE B1
Comment 1 Dominique d'Humieres 2008-09-07 19:01:19 UTC
Confirmed on powerpc-apple-darwin9 (4.2.3, 4.3.2 and trunk):

pr37411.f90: In function 'sub':
pr37411.f90:12: internal compiler error: Bus error

Comment 2 Tobias Burnus 2008-09-07 20:09:05 UTC
==17304== Invalid read of size 4
==17304==    at 0x49F779: gfc_conv_array_parameter (trans-array.c:5179)
==17304==    by 0x4B05C0: gfc_conv_function_call (trans-expr.c:2582)
==17304==    by 0x4B1A7D: gfc_conv_function_expr (trans-expr.c:3252)
==17304==    by 0x4B62F9: gfc_apply_interface_mapping (trans-expr.c:2036)

The following seems to fix it (not extensively tested):

--- trans-array.c       (revision 140091)
+++ trans-array.c       (working copy)
@@ -5176,7 +5176,7 @@ gfc_conv_array_parameter (gfc_se * se, g

       if (sym->ts.type == BT_CHARACTER)
        se->string_length = sym->ts.cl->backend_decl;
-      if (!sym->attr.pointer && sym->as->type != AS_ASSUMED_SHAPE
+      if (!sym->attr.pointer && sym->as && sym->as->type != AS_ASSUMED_SHAPE
           && !sym->attr.allocatable)
         {
          /* Some variables are declared directly, others are declared as
Comment 3 Tobias Burnus 2008-09-08 09:23:48 UTC
Created attachment 16254 [details]
Regtested patch, including test case

The same as patch. However, I'm not sure the fix is right.
a) Why is sym->as NULL even though "X" is an array?
b) Without the if-branch, one misses:
      tmp = gfc_get_symbol_decl (sym);
            se->expr = tmp;
I'm not sure whether it matters as the test case works OK, but I have the feeling the patch is wrong and one rather needs to fix sym->as and needs to add a "gcc_assert (sym->as)".
Comment 4 Dominique d'Humieres 2008-09-08 09:46:53 UTC
I am not 100% sure, but I somehow got the impression that the patch for pr37199 also fixed this pr. Could you check if this is the case?
Comment 5 Dominique d'Humieres 2008-09-08 13:53:31 UTC
I have reverted the patch in comment #3 on intel/Darwin9 and updated to r140104 on ppc/Darwin9 and in both cases the original test compiles without error. Is it another fix due to the one for pr37199?

Anyway, it would be safe to add a "gcc_assert (sym->as)" and to include the new test case.
 
Comment 6 Daniel Kraft 2008-09-08 18:37:18 UTC
Reading the comments, this sounds really like the problem fixed for PR 37199 (sym->as "wrongly" NULL after interface-remapping).  I agree that adding the test and gcc_assert sounds like a good idea for me.

I will work on this tomorrow morning if no-one confirms and makes these changes this evening :)
Comment 7 Daniel Kraft 2008-09-09 09:48:13 UTC
Subject: Bug 37411

Author: domob
Date: Tue Sep  9 09:46:51 2008
New Revision: 140141

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140141
Log:
2008-09-09  Daniel Kraft  <d@domob.eu>

	PR fortran/37411
	* trans-array.c (gfc_conv_array_parameter): Added assertion that the
	symbol has an array spec.

2008-09-09  Daniel Kraft  <d@domob.eu>

	PR fortran/37411
	* gfortran.dg/array_function_4.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/array_function_4.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/testsuite/ChangeLog

Comment 8 Daniel Kraft 2008-09-09 09:49:01 UTC
This was indeed fixed with PR 37199, I committed the test-case as well as the assertion mentioned.  Fixed.