An ICE happens when trying to allocate an allocatable array with explicit array bounds in combination with a source expression: gfortran -c processes.f90 processes.f90:31:0: source = t3%int_born%func ()) 1 internal compiler error: in gfc_conv_procedure_call, at fortran/trans-expr.c:5754 processes.f90:31:0: internal compiler error: Abort trap: 6 with the following code (maybe can be reduced even a little further): module processes implicit none private type :: t1_t real :: p = 0.0 end type t1_t type :: t2_t private type(t1_t), dimension(:), allocatable :: p contains procedure :: func => t2_func end type t2_t type :: t3_t type(t2_t), public :: int_born end type t3_t contains function t2_func (int) result (p) class(t2_t), intent(in) :: int type(t1_t), dimension(:), allocatable :: p end function t2_func subroutine evaluate (t3) class(t3_t), intent(inout) :: t3 type(t1_t), dimension(:), allocatable :: p_born allocate (p_born(1:size(t3%int_born%func ())), & source = t3%int_born%func ()) end subroutine evaluate end module processes
Forgot: my gcc svn revision is r224763.
Revision r223090 (2015-05-12) is OK, revision r223694 (2015-05-26) gives the ICE.
F2008, C633 says: (R631) If allocate-object is an array either allocate-shape-spec-list shall appear or source-expr shall appear and have the same rank as allocate-object. If allocate-object is scalar, allocate-shape-spec-list shall not appear. So you can fix your code, by removing the array-description from the object to allocate. I am aware, that this kind of code is motivated by former gfortran not being able to take the array-spec from the source= expression. But now it is.
Actually, we are using now allocate (obj(1:size (func ())) obj = func () as you are saying allocate (obj, source = func ()) had problems in gfortran 4.7.X. So the issue is not a problem for our code(s). But you are saying that the code triggering the ICE violates the Fortran standard?
I am not that bold anymore to interpret the nasty standard. I wanted to express, that the allocate(obj, source=func()) is now sufficient. I made some bad experience trying to interpret the standard and was told off not to do so. Therefore, I will not say "yes, it violates the standard" nor "no, it doesn't". Given there are many programs, that use the work-around you've shown, I am unsure what to do here. But you are right, ICE'ing is a no go.
This fixes the issue: diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c index 6409f7f..181cbce 100644 --- a/gcc/fortran/trans-stmt.c +++ b/gcc/fortran/trans-stmt.c @@ -5189,7 +5189,9 @@ gfc_trans_allocate (gfc_code * code) /* Get the descriptor for all arrays, that are not allocatable or pointer, because the latter are descriptors already. */ attr = gfc_expr_attr (code->expr3); - if (code->expr3->rank != 0 && !attr.allocatable && !attr.pointer) + if (code->expr3->rank != 0 && ((!attr.allocatable && !attr.pointer) + || (code->expr3->expr_type == EXPR_FUNCTION + && code->expr3->ts.type != BT_CLASS))) gfc_conv_expr_descriptor (&se, code->expr3); else gfc_conv_expr_reference (&se, code->expr3);
Currently checking whether the bug can be fixed more elegantly.
More elaborate patch available at: https://gcc.gnu.org/ml/fortran/2015-09/msg00142.html This patch also handles functions for source= that return a class object.
Author: vehre Date: Sun Oct 25 12:28:57 2015 New Revision: 229294 URL: https://gcc.gnu.org/viewcvs?rev=229294&root=gcc&view=rev Log: gcc/fortran/ChangeLog: 2015-10-25 Andre Vehreschild <vehre@gcc.gnu.org> PR fortran/66927 PR fortran/67044 * trans-array.c (build_array_ref): Modified call to gfc_get_class_array_ref to adhere to new interface. (gfc_conv_expr_descriptor): For one-based arrays that are filled by a loop starting at one the start index of the source array has to be mangled into the offset. * trans-expr.c (gfc_get_class_array_ref): When the tree to get the _data component is present already, add a way to supply it. (gfc_copy_class_to_class): Allow to copy to a derived type also. * trans-stmt.c (gfc_trans_allocate): Do not conv_expr_descriptor for functions returning a class or derived object. Get the reference instead. * trans.h: Interface change of gfc_get_class_array_ref. gcc/testsuite/ChangeLog: 2015-10-25 Andre Vehreschild <vehre@gmx.de> PR fortran/66927 PR fortran/67044 * gfortran.dg/allocate_with_source_10.f08: New test. * gfortran.dg/allocate_with_source_11.f08: New test. * gfortran.dg/class_array_15.f03: Changed count of expected _builtin_frees to 11. One step of temporaries is spared, therefore the allocatable component of that temporary is not to be freeed. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/class_array_15.f03
Author: vehre Date: Sun Oct 25 13:02:32 2015 New Revision: 229295 URL: https://gcc.gnu.org/viewcvs?rev=229295&root=gcc&view=rev Log: Added missing testcases of r229294 for patch of PR fortran/66927. Added: trunk/gcc/testsuite/gfortran.dg/allocate_with_source_10.f08 trunk/gcc/testsuite/gfortran.dg/allocate_with_source_11.f08
On Linux/ia32, I got spawn [open ...]^M *** Error in `./allocate_with_source_10.exe': free(): invalid next size (fast): 0x09dcebc8 *** Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0xf7766bdf in ??? #1 0x456e2e68 in ??? #2 0x456e5a03 in ??? #3 0x456e7c5e in ??? #4 0x45658960 in ??? #5 0x4565ebf2 in ??? #6 0x4565a4e3 in ??? #7 0x4565e481 in ??? #8 0x457a35fb in ??? #9 0x4565a4e3 in ??? #10 0x457a36f0 in ??? #11 0x45777192 in ??? #12 0x45777424 in ??? #13 0x45688969 in ??? #14 0x456dbf12 in ??? #15 0x456e4899 in ??? #16 0x456e7f3f in ??? #17 0x804916e in ??? #18 0x80492a2 in ??? #19 0x80492e2 in ??? #20 0x456896f4 in ??? #21 0x8048780 in ??? FAIL: gfortran.dg/allocate_with_source_10.f08 -O0 execution test GCC is configured with --prefix=/usr/6.0.0 --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld --enable-libmpx i686-linux --with-fpmath=sse --enable-languages=c,c++,fortran,java,lto,objc
I can confirm that issue. Don't know how to fix it yet, though. Looks like the scalarizer is not coping correctly with a AS_DEFERRED array.
Author: vehre Date: Mon Oct 26 13:03:22 2015 New Revision: 229353 URL: https://gcc.gnu.org/viewcvs?rev=229353&root=gcc&view=rev Log: gcc/fortran/ChangeLog: 2015-10-26 Andre Vehreschild <vehre@gcc.gnu.org> PR fortran/66927 * trans-array.c (evaluate_bound): For deferred length arrays get the bounds directly from the descriptor, i.e., prevent using constant zero lower bound from the gfc_conv_array_lbound () routine. (gfc_conv_section_startstride): Hand deferred array status to evaluate_bound (). (gfc_conv_expr_descriptor): Same. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c
These changes seem to break our code. Will provide an example in a minute.
Here it it: {{{ module lexers implicit none private type :: template_t private character(256) :: charset1 integer :: len1 end type template_t contains subroutine match_quoted (tt, s, n) type(template_t), intent(in) :: tt character(*), intent(in) :: s integer, intent(out) :: n character(tt%len1) :: ch1 ch1 = tt%charset1 end subroutine match_quoted end module lexers }}} I believe this comes from your commit, so I don't open up a new ticket. Would be cool if this can be solved quickly.
(In reply to Jürgen Reuter from comment #15) > Here it it: > {{{ > module lexers > implicit none > private > type :: template_t > private > character(256) :: charset1 > integer :: len1 > end type template_t > > contains > > subroutine match_quoted (tt, s, n) > type(template_t), intent(in) :: tt > character(*), intent(in) :: s > integer, intent(out) :: n > character(tt%len1) :: ch1 > ch1 = tt%charset1 > end subroutine match_quoted > > end module lexers > }}} > I believe this comes from your commit, so I don't open up a new ticket. > Would be cool if this can be solved quickly. I doubt that it is related to Andre's patch as nothing in the above code uses ALLOCATE. The error messages is also one that I just introduced. So, submit a PR.
Done, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68108
On Tue, Oct 27, 2015 at 01:01:37AM +0000, juergen.reuter at desy dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66927 > > --- Comment #17 from Jürgen Reuter <juergen.reuter at desy dot de> --- > Done, > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68108 > I may have a patch already written. Need to run testsuite.
Given that 68108 is marked as fixed and there are no other complaints, I am closing.
*** Bug 67123 has been marked as a duplicate of this bug. ***