[Bug fortran/35680] New: [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[Bug fortran/35680] New: [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[fxcoudert at gcc dot gnu dot org]

program main
  print *, foo()
contains
  function foo()
    integer foo(size(transfer(x, [1])))
    real x
  end function
end program

gives: a.f90:2: internal compiler error: Segmentation fault

gfortran 4.1.2 20070626 (Red Hat 4.1.2-14) says:
 In file a.f90:5

    integer foo(size(transfer(x, [1])))
                             1
Error: Variable 'x' cannot appear in the expression at (1)


-- 
           Summary: [4.3/4.4 regression] ICE on invalid transfer in variable
                    declaration
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Keywords: ice-on-invalid-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: fxcoudert at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[pault at gcc dot gnu dot org]

------- Comment #1 from pault at gcc dot gnu dot org  2008-03-25 20:45 -------
g95 correctly gives:
In file pr35680.f90:5

    integer foo(size(transfer(x, [1])))
                              1
Error: Variable 'x' cannot appear in restricted expression at (1)

Lahey gives:

  1175-S: "SOURCE.F90", line 5, column 13: Lower and upper bounds in array
specifier for 'foo' must be specification expression.


Confirmed

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-03-25 20:45:37
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.3.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2008-06-06 14:59 -------
4.3.1 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.1                       |4.3.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2008-07-22 12:11 -------
Analogously for:
    integer foo(size([x]))
    real x

As ifort writes:
error #6279: A specification expression object must be a dummy argument, a
COMMON block object, or an object accessible through host or use association


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[jsm28 at gcc dot gnu dot org]

------- Comment #4 from jsm28 at gcc dot gnu dot org  2008-08-27 22:03 -------
4.3.2 is released, changing milestones to 4.3.3.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.2                       |4.3.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[pault at gcc dot gnu dot org]

------- Comment #5 from pault at gcc dot gnu dot org  2008-09-17 08:55 -------
(In reply to comment #4)
> 4.3.2 is released, changing milestones to 4.3.3.
> 
Although this passes Lahey with only a warning that the return value is not
set, it manifestly is standard defying according to 7.1.6.2

A variable in a specification expression shall have its type and type
parameters, if any, specified by a previous declaration in the same scoping
unit, or by the implicit typing rules in effect for the scoping unit, or by
host or use association. If a variable in a specification expression is typed
by
the implicit typing rules, its appearance in any subsequent type declaration
statement shall confirm the implied type and type parameters.

Inverting the order of the declarations should make the code legal.

Paul 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[pault at gcc dot gnu dot org]

------- Comment #6 from pault at gcc dot gnu dot org  2008-09-28 19:33 -------
Created an attachment (id=16421)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16421&action=view)
A tentative fix for this PR

This allows the testcase to compile and run correctly.  I am now not sure if x
does need to be declared before foo, simply because it is not needed to
determine the size of the transfer result.

At very least, it is an obvious addition to resolve_transfer.  We can worry
about statement order some other time.

I cannot regtest or commit because of a catastrophe with the Windows installer,
followed by a rash decision to install FC9.

Volunteers?

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[pault at gcc dot gnu dot org]

------- Comment #7 from pault at gcc dot gnu dot org  2008-09-28 19:48 -------
Why don't I take it too? :-)

paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-03-25 20:45:37         |2008-09-28 19:48:37
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[dominiq at lps dot ens dot fr]

------- Comment #8 from dominiq at lps dot ens dot fr  2008-09-28 20:49 -------
With the patch in comment #6, gfortran.dg/transfer_array_intrinsic_4.f90 fails:

/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_4.f90:16.8:

      ia = TRANSFER (s1, (/ 0_4 /))
       1
Error: Different shape for array assignment at (1) on dimension 1 (3 and 1)
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_4.f90:22.8:

      ba = TRANSFER (trim (s1)//'       JK' , (/ 0_1 /))
       1
Error: Different shape for array assignment at (1) on dimension 1 (12 and 1)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[dominiq at lps dot ens dot fr]

------- Comment #9 from dominiq at lps dot ens dot fr  2008-09-29 20:25 -------
Although I am not familiar with the gfortran code, gfc_array_size (mold, &tmp)I
think the reason why gfortran.dg/transfer_array_intrinsic_4.f90 fails with the
patch in comment #6,
is because gfc_array_size (mold, &tmp) looks at the size of mold, while the
relevant part of the TRANSFER definition is:

If SIZE is absent but MOLD is an array (of any size or shape), the result is a
one-dimensional array of the minimum length needed to contain the entirety of
the bitwise representation of SOURCE.

So I think tmp should contain
(number_of_bytes_in_SOURCE+size_in_bytes_of_a_MOLD_element-1)/size_in_bytes_of_a_MOLD_element.

Note that it would be interesting to test the code for [1_1], [1_2], [1_8], and
-fdefault-integer-8 to rule out side effects.

BTW I think the code in comment #0 is valid for both statement order: if 'real
x' is before TRANSFER, it value is not defined, but not necessary to get the
size; if 'real x' is after TRANSFER, x is implicitely defined as  real and I
think it is legal to confirm it by the 'real x' statement. At least the
following code

real :: y=epsilon(x)
real :: x
print *, y
end

is accepted by gfortran, ifort, and g95.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[pault at gcc dot gnu dot org]

------- Comment #10 from pault at gcc dot gnu dot org  2008-10-02 15:20 -------
(In reply to comment #9)
As usual, the DEC manual puts in succinctly:
If MOLD is an array and SIZE is omitted, the result is a rank-one array. Its
size is the smallest that is possible to hold all of SOURCE". 

This is what I have now implemented (and by the way, what I implemented for
simplify_transfer and the trans-intrinsic version....).  However,

"If the physical representation of the result is smaller than SOURCE, the
result contains the right-most bits of SOURCE's bit pattern.
is a killer at this stage in the compilation, since the physical reprentation
of the result is unknown.

I might signal, I guess, that it is the actual argument of an inquiry
function....  Anyway, the logic is there, I just have to figure out where to
deploy it.  Otherwise, I break transfer_array_intrinsic_2.f90, which has an
assignment from an over-large 'transfer' result.

*sigh*

Paul 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[dominiq at lps dot ens dot fr]

------- Comment #11 from dominiq at lps dot ens dot fr  2008-10-02 15:48 -------
> "If the physical representation of the result is smaller than SOURCE, ...

>From the xlf manual, I read this for scalar cases, i.e., transfer(x,i) with x
real(4) and i integer(8), or when size is given:
transfer((/1.1,2.2,3.3/),(/(0.0,0.0)/),1) gives (/(1.1,2.2)/), while
transfer((/1.1,2.2,3.3/),(/(0.0,0.0)/)) gives (/(1.1,2.2),(3.3,??)/), where the
imaginary part ?? is undefined.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[pault at gcc dot gnu dot org]

------- Comment #12 from pault at gcc dot gnu dot org  2008-10-03 12:12 -------
(In reply to comment #11)
Happily, I have come to the conclusion that the code is invalid no matter which
order the declarations come in;

In a restricted expression... (7.1.6.2):

(7) A reference to an intrinsic function that is
(a) an array inquiry function (13.11.15) other than ALLOCATED,
       ....SIZE in this case....
....
and where each argument of the function is
(a) a restricted expression or
(b) a variable whose properties inquired about are not
the TRANSFER (x, [1]) argument is manifestly not consistent with (b) and should
fail by (a) with exactly the g95 message.

I will make it so.

In fact the ICE is precisely due to the argument not being a restricted
expression, since the size of x and its kind are unavailable to the caller and
the interfacing cannot be made to work.  This is why restricted expressions
only permit dummy, host- or use-associated or common variables and why my
attempts to evaluate the transfer are failing.

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[dominiq at lps dot ens dot fr]

------- Comment #13 from dominiq at lps dot ens dot fr  2008-10-03 22:23 -------
> Happily, I have come to the conclusion that the code is invalid no matter which
> order the declarations come in;
> ....
> (a) a restricted expression or
> (b) a variable whose properties inquired about are not
> the TRANSFER (x, [1]) argument is manifestly not consistent with (b) and should
> fail by (a) with exactly the g95 message.

After having knotted my neurones, I agree with that: size(transfer(x, [1])) is
not a "restricted expression".

> I will make it so.

Good!

> In fact the ICE is precisely due to the argument not being a restricted
> expression, since the size of x and its kind are unavailable to the caller and
> the interfacing cannot be made to work.  This is why restricted expressions
> only permit dummy, host- or use-associated or common variables and why my
> attempts to evaluate the transfer are failing.

However I disagree with this part of the analysis:

size(transfer(real(1.0,kind(x)), [1_1])) is a "restricted expression" (happily
accepted by gfortran) that uses exactly the same information as
size(transfer(x, [1])) as shown by the following code:

program main
  print *, foo()
  print *, size(transfer(real(1.0,kind(x)), [1_1])),&
           size(transfer(x, [1_1]))
  if (size(foo()) /= kind(x)) call abort()
contains
  function foo()
    integer foo(size(transfer(real(1.0,kind(x)), [1_1])))
    real x
    foo=transfer(real(1.0,kind(x)), [1_1])
  end function
end program

giving on intel machines (without the patch in comment #6)

           0           0        -128          63
           4           4

(with the patch the second line is 4 1) or

           0           0           0           0           0           0       
 -16          63
           8           8

when compiled with -fdefault-real-8. On ppc I get

          63        -128           0           0
           4           4

and

          63         -16           0           0           0           0       
   0           0
           8           8


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[pault at gcc dot gnu dot org]

------- Comment #14 from pault at gcc dot gnu dot org  2008-10-04 11:56 -------
(In reply to comment #13)

> > In fact the ICE is precisely due to the argument not being a restricted
> > expression, since the size of x and its kind are unavailable to the caller and
> > the interfacing cannot be made to work.  This is why restricted expressions
> > only permit dummy, host- or use-associated or common variables and why my
> > attempts to evaluate the transfer are failing.
> 
> However I disagree with this part of the analysis:
> 
> size(transfer(real(1.0,kind(x)), [1_1])) is a "restricted expression" (happily
> accepted by gfortran) that uses exactly the same information as

The real transfer(real(1.0,kind(x)) simplifies to a constant, which is why it
can be evaluated.  size(transfer(x, [1])) needs the variable, 'x'; even though
the inquiry function does not need the value.  My attempts to bypass this
produced all manner of regressions.

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[pault at gcc dot gnu dot org]

------- Comment #15 from pault at gcc dot gnu dot org  2008-10-05 18:54 -------
Subject: Bug 35680

Author: pault
Date: Sun Oct  5 18:53:19 2008
New Revision: 140892

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140892
Log:
2008-10-05  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/35680
        * gfortran.h : Add 'error' bit field to gfc_expr structure.
        * expr.c (check_inquiry): When checking a restricted expression
        check that arguments are either variables or restricted.
        (check_restricted): Do not emit error if the expression has
        'error' set.  Clean up detection of host-associated variable.

2008-10-05  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/35680
        * gfortran.dg/transfer_array_intrinsic_5.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_5.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[pault at gcc dot gnu dot org]

------- Comment #16 from pault at gcc dot gnu dot org  2008-10-11 09:59 -------
Subject: Bug 35680

Author: pault
Date: Sat Oct 11 09:58:38 2008
New Revision: 141056

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141056
Log:
2008-10-11  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/35680
        * gfortran.h : Add 'error' bit field to gfc_expr structure.
        * expr.c (check_inquiry): When checking a restricted expression
        check that arguments are either variables or restricted.
        (check_restricted): Do not emit error if the expression has
        'error' set.  Clean up detection of host-associated variable.

2008-10-11  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/35680
        * gfortran.dg/transfer_array_intrinsic_5.f90: New test.

Added:
   
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_5.f90
Modified:
    branches/gcc-4_3-branch/gcc/fortran/ChangeLog
    branches/gcc-4_3-branch/gcc/fortran/expr.c
    branches/gcc-4_3-branch/gcc/fortran/gfortran.h
    branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[pault at gcc dot gnu dot org]

------- Comment #17 from pault at gcc dot gnu dot org  2008-10-11 10:02 -------
Fixed on trunk and 4.3

Thanks for the report, FX (I hope that you still keep an eye on the PRs!)

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680