[Bug fortran/34945] New: LBOUND fails for array with KIND(complex) used in zero-sized dimension

[Bug fortran/34945] New: LBOUND fails for array with KIND(complex) used in zero-sized dimension

[dick dot hendrickson at gmail dot com]

With compiler
gcc version 4.3.0 20080109 (experimental) [trunk revision 131426] (GCC)

I get the following error message


>gfortran vf0009.f
vf0009.f: In function 'vf0009':
vf0009.f:11: error: size of variable 'test_array' is too large

If I replace the second line in the declaration of test_array with
any of
     $   KIND(IDA1):5,
     $   KIND(YDA):9,
     $   8:5,
the program compiles without an error message.
The LBOUND function is needed to trigger the error message

Dick Hendrickson

      SUBROUTINE VF0009(IDA1,IDA2,YDA,HDA)
      INTEGER(4) IDA1(4)
      INTEGER(4) IDA2(4)
      COMPLEX(8) YDA(2)
      INTEGER(4) HDA(3)
!  I N I T I A L I Z A T I O N  S E C T I O N
      COMPLEX(KIND=4) :: TEST_ARRAY
     $(  4:5,
     $   KIND(YDA):5,
     $   4:5,
     $   4:5  )
!  T E S T  S T A T E M E N T S
       IDA1(1:4) = LBOUND(TEST_ARRAY)
      END SUBROUTINE


-- 
           Summary: LBOUND fails for array with KIND(complex) used in zero-
                    sized dimension
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dick dot hendrickson at gmail dot com


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

[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2008-01-28 18:09 -------
I think the size is simply calculated as:
   ubound[n] + 1 - lbound[n];
which means:
   5+1-8 = -2
At some point the variable is regarded as unsigned which means (for 8 byte
variables): 18446744073709551614, which is not unexpected to be too large. (I'm
ignoring here the byte-size of complex(4) and the other dimensions).

The actual size is of cause "0" as the shape is 2 0 2 2.

I think we have several places where a zero-sized array makes problems (cf.
e.g. PR34980 for SHAPE). For this PR one probably needs to fix
gfc_trans_create_temp_array, where "size" is calculated as follows:
     size = 1;
     for (n = 0; n < rank; n++)
       {
         stride[n] = size
         delta = ubound[n] + 1 - lbound[n];
         size = size * delta;
       }
     size = size * sizeof(element);

But maybe also something else.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |32834
              nThis|                            |
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |rejects-valid
   Last reconfirmed|0000-00-00 00:00:00         |2008-01-28 18:09:22
               date|                            |


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

[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension

[pault at gcc dot gnu dot org]

------- Comment #2 from pault at gcc dot gnu dot org  2008-01-29 11:24 -------
(In reply to comment #1)

Note the comment in trans-expr.c(gfc_map_intrinsic_function) :

    case GFC_ISYM_LBOUND:
    case GFC_ISYM_UBOUND:
        /* TODO These implementations of lbound and ubound do not limit if
           the size < 0, according to F95's 13.14.53 and 13.14.113.  */

We need an intrinsic function that translates to cond ? a : b to do the right
thing here.  I could not see how to do it with existing front-endery.

Paul


-- 


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

[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension

[burnus at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]



------- Comment #3 from burnus at gcc dot gnu dot org  2008-01-29 13:22 -------
> Note the comment in trans-expr.c(gfc_map_intrinsic_function) :
>     case GFC_ISYM_LBOUND:
>     case GFC_ISYM_UBOUND:
>         /* TODO These implementations of lbound and ubound do not limit if
>            the size < 0, according to F95's 13.14.53 and 13.14.113.  */

I had the impression that the problem is the array itself and not only
ubound/lbound.

You can replace LBOUND(TEST_ARRAY) by "print *, TEST_ARRAY", "SIZE(TEST_ARRAY)"
etc. You will always get the middle end error:
   a.f:11: error: size of variable ‘test_array’ is too large
(gcc/varasm.c:2095).

What I find puzzling is the following:

implicit none
integer :: i(kind(4):1)
integer :: j(4:1)
print *, i(4:3)
print *, j(4:3)
end

"j" works but "i" gives the same error message. If the size is not known at
compile time (e.g. an automatic array) it seems to work.

Actually, replacing "j(4:1)" by "j((4):1)" is enough to make it fail. I think
"4:1" is replaced by "1:0" while "(4):1" is replaced by "4:1".


-- 


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

[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension

[jvdelisle at gcc dot gnu dot org]

------- Comment #4 from jvdelisle at gcc dot gnu dot org  2008-01-30 05:18 -------
Reply to comment two:

There is front-endery code to do "cond ? a : b" in the handling of missing
optional dummy arguments. You can borrow from that.


-- 


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

[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension

[pault at gcc dot gnu dot org]

------- Comment #5 from pault at gcc dot gnu dot org  2008-01-31 08:30 -------
(In reply to comment #4)
> Reply to comment two:
> 
> There is front-endery code to do "cond ? a : b" in the handling of missing
> optional dummy arguments. You can borrow from that.
> 

I know about the TREE_SSA expressions - what I need is a frontend, ie. a
gfc_expr  that delivers this functionality.  The bit of code that needs sorting
is manipulating gfc_expressions.  The reason that this is necessary, is that
the conditional operators carry over the magnitude of the conditional
expression:

i = 4   => (i > 0) * f  => 4*f  when implemented with gfc binops.

In writing this, I realise that I never tried to convert the (i > 0) to logical
but I do not think that it would make any difference.

Paul


-- 


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

[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension

[pault at gcc dot gnu dot org]

------- Comment #6 from pault at gcc dot gnu dot org  2008-02-03 12:55 -------
(In reply to comment #3)

> I had the impression that the problem is the array itself and not only
> ubound/lbound.

Quite right, Tobias!

Paul


-- 


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

[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension

[pault at gcc dot gnu dot org]

------- Comment #7 from pault at gcc dot gnu dot org  2008-02-03 14:05 -------
Created an attachment (id=15085)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15085&action=view)
Patch and testcase for this PR

This one is regtesting right now.

Cheers

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


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

[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension

[dominiq at lps dot ens dot fr]

------- Comment #8 from dominiq at lps dot ens dot fr  2008-02-03 22:46 -------
Test suite run without new regression on ppc/intel-darwin9, 32 and 64 bit
modes, with the patch in http://gcc.gnu.org/ml/fortran/2008-02/msg00008.html.

Thanks for the fix.


-- 


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

[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension

[pault at gcc dot gnu dot org]

------- Comment #9 from pault at gcc dot gnu dot org  2008-02-05 13:34 -------
Subject: Bug 34945

Author: pault
Date: Tue Feb  5 13:33:35 2008
New Revision: 132121

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

        PR fortran/34945
        * array.c (match_array_element_spec): Remove check for negative
        array size.
        (gfc_resolve_array_spec): Add check for negative size.

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

        PR fortran/34945
        * gfortran.dg/bounds_check_13.f: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/bounds_check_13.f
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/array.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension

[pault at gcc dot gnu dot org]

------- Comment #10 from pault at gcc dot gnu dot org  2008-02-05 13:37 -------
Fixed on trunk - thanks, Dick!

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=34945