This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/52059] [4.7 Regression] ICE in gfc_conv_variable
- From: "burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 31 Jan 2012 11:35:15 +0000
- Subject: [Bug fortran/52059] [4.7 Regression] ICE in gfc_conv_variable
- Auto-submitted: auto-generated
- References: <bug-52059-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52059
--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-31 11:35:15 UTC ---
(In reply to comment #1)
> It works if one undoes the change to trans-expr.c, i.e. [...]
Completely untested patch (neither compiled nor tested in gdb):
Index: trans-expr.c
===================================================================
--- trans-expr.c (revision 183722)
+++ trans-expr.c (working copy)
@@ -3528,3 +3528,3 @@ gfc_conv_procedure_call (gfc_se * se, gf
- if (se->ss->dimen > 0
+ if (se->ss->dimen > 0 && e->rank > 0
&& se->ss->info->data.array.ref == NULL)
* * *
> Side note:
> real(kind=8) :: a(99)
> a = foo (bar(0,35), ...
> The a(99) should be a(35) as "foo(bar()..." returns an array
> of dimension(35-0).
(In reply to comment #2)
> Then plplot is buggy.
Indeed, though with gfortran, the excess elements are simply not touched and
keep their original value, which usually is fine. (For compilers which
scalarize the LHS [such as ifort] instead of the RHS, one reads too many bytes
on the RHS, which is problematic but often also works, unless the LHS is much
larger than the RHS -> invalid memory access/segfault.)
The proper assignment should use
a(:35) = foo (bar(0,35), ...
or some variant of it. (One also can make make "a" allocatable; for "a = ", the
the LHS is then (re)allocated to match the shape of the RHS [Fortran 2003/GCC
4.6 feature].)