User account creation filtered due to spam.

Bug 52059 - [4.7 Regression] ICE in gfc_conv_variable
Summary: [4.7 Regression] ICE in gfc_conv_variable
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.7.0
: P4 normal
Target Milestone: 4.7.0
Assignee: Not yet assigned to anyone
Keywords: ice-on-valid-code
: 52063 (view as bug list)
Depends on:
Reported: 2012-01-30 20:54 UTC by Jakub Jelinek
Modified: 2012-02-01 19:12 UTC (History)
3 users (show)

See Also:
Known to work: 4.6.3
Known to fail: 4.7.0
Last reconfirmed: 2012-01-30 00:00:00


Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Jelinek 2012-01-30 20:54:55 UTC
subroutine baz
  real(kind=8) :: a(99), b
  interface bar
    function bar (x, y)
      integer, intent(in) :: x, y
      real(kind=8), dimension((y-x)) :: bar
    end function bar
  end interface
  b = 1.0_8
  a = foo (bar(0,35) / dble(34), b)
  elemental real(kind=8) function foo(x, y)
    real(kind=8), intent(in) :: x, y
    foo = 1
  end function foo
end subroutine baz

ICEs starting with
(and, when b in the call is replaced with say 1.0_8, ICEs in gfc_conv_constant
and when the y argument from y is removed and the caller is adjusted too, ICEs in gfc_trans_assignment.
Comment 1 Tobias Burnus 2012-01-30 23:03:28 UTC
In gfc_conv_variable, it fails at the assert:
1183          gcc_assert (ss_info->expr == expr);

Here, "expr" is the variable "b" while "ss_info->expr" is a BT_REAL constant.

If one replaces "b" by "1.0_8", one has the same issue (except that than both values are constants.)

And without "y" argument, it fails for:
6919                      && == gfc_ss_terminator);
One has>info->type = GFC_SS_SCALAR and>info->expr->expr_type == EXPR_CONSTANT.

It works if one undoes the change to trans-expr.c, i.e.

 * * *

Side note:
  real(kind=8) :: a(99)
  real(kind=8), dimension((y-x)) :: bar
  a = foo (bar(0,35), ...

The a(99) should be a(35) as "foo(bar()..." returns a array of dimension(35-0).
Comment 2 Jakub Jelinek 2012-01-30 23:33:11 UTC
Then plplot (see ) is buggy.
Anyway, it ICEs even with the same bounds.
Comment 3 Andrew Pinski 2012-01-31 03:42:22 UTC
*** Bug 52063 has been marked as a duplicate of this bug. ***
Comment 4 Tobias Burnus 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].)
Comment 5 Tobias Burnus 2012-02-01 08:34:32 UTC
Submitted patch:
Comment 6 Tobias Burnus 2012-02-01 19:01:54 UTC
Author: burnus
Date: Wed Feb  1 19:01:49 2012
New Revision: 183807

2012-02-01  Tobias Burnus

        PR fortran/52059
        * trans-expr.c (gfc_conv_procedure_call): Add array ref
        only to variables.

2012-02-01  Tobias Burnus

        PR fortran/52059
        * gfortran.dg/elemental_function_1.f90: New.

Comment 7 Tobias Burnus 2012-02-01 19:12:27 UTC
FIXED on the trunk (4.7).