[Bug fortran/46945] New: [4.6 Regression] gfortran.dg/unpack_zerosize_1.f90 FAILs with -ftree-vrp -fno-tree-ccp -fno-tree-fre

[Bug fortran/46945] New: [4.6 Regression] gfortran.dg/unpack_zerosize_1.f90 FAILs with -ftree-vrp -fno-tree-ccp -fno-tree-fre

[zsojka at seznam dot cz]

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

           Summary: [4.6 Regression] gfortran.dg/unpack_zerosize_1.f90
                    FAILs with -ftree-vrp -fno-tree-ccp -fno-tree-fre
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: zsojka@seznam.cz


Created attachment 22755
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22755
reduced testcase

Output:
$ gfortran -O -ftree-vrp -fno-tree-ccp -fno-tree-fre testcase.f90
$ ./a.out 
Fortran runtime error: Integer overflow when calculating the amount of memory
to allocate

In the testcase.f90.067t.vrp1 dump, there is unconditional call to
_gfortran_runtime_error().

Maybe will be fixed by http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01026.html

Tested revisions:
r167770 - fail
r167643 - fail
r165699 - OK
4.5 r166509 - OK

[Bug fortran/46945] [4.6 Regression] gfortran.dg/unpack_zerosize_1.f90 FAILs with -ftree-vrp -fno-tree-ccp -fno-tree-fre

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |jb at gcc dot gnu.org
   Target Milestone|---                         |4.6.0

[Bug fortran/46945] [4.6 Regression] gfortran.dg/unpack_zerosize_1.f90 FAILs with -ftree-vrp -fno-tree-ccp -fno-tree-fre

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-15 11:15:30 UTC ---
The problem is probably that the -1 in
D.1556 = ((logical(kind=4)) __builtin_expect ((<unnamed-unsigned:64>) D.1555 >
-1, 0) ? 1 : 0) + D.1554;
has TREE_OVERFLOW set, D.1555 is determined by VRP to be 0 and from the
overflowed constant VRP determines that 0 > -1 (the type of both is
sizetype, i.e. unsigned, but with the weirdo semantics).
This is created in gfc_array_init_size:
4160      /* First check for overflow. Since an array of type character can
4161         have zero element_size, we must check for that before
4162         dividing.  */
4163      tmp = fold_build2_loc (input_location, TRUNC_DIV_EXPR, 
4164                 sizetype, 
4165                 TYPE_MAX_VALUE (sizetype), element_size);
4166      tmp = fold_build3_loc (input_location, COND_EXPR, integer_type_node,
4167                 gfc_unlikely (fold_build2_loc (input_location, LT_EXPR, 
4168                                boolean_type_node, tmp, 
4169                                stride)),
4170                 integer_one_node, integer_zero_node);

I'd say it is very questionable to use sizetype here.

[Bug fortran/46945] [4.6 Regression] gfortran.dg/unpack_zerosize_1.f90 FAILs with -ftree-vrp -fno-tree-ccp -fno-tree-fre

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2010.12.15 11:28:11
         AssignedTo|unassigned at gcc dot       |jakub at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-15 11:28:11 UTC ---
Created attachment 22762
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22762
gcc46-pr46945.patch

Untested fix.

[Bug fortran/46945] [4.6 Regression] gfortran.dg/unpack_zerosize_1.f90 FAILs with -ftree-vrp -fno-tree-ccp -fno-tree-fre

[jb at gcc dot gnu.org]

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

--- Comment #3 from Janne Blomqvist <jb at gcc dot gnu.org> 2010-12-15 11:57:28 UTC ---
The offending patch is most likely

http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02499.html

Wrt. the recent changes in the definition of size_t, there is

http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02111.html

Apart from the change suggested by Jakub in comment #2, is there anything else
suspect in those patches?

[Bug fortran/46945] [4.6 Regression] gfortran.dg/unpack_zerosize_1.f90 FAILs with -ftree-vrp -fno-tree-ccp -fno-tree-fre

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-15 20:20:19 UTC ---
Author: jakub
Date: Wed Dec 15 20:20:10 2010
New Revision: 167871

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167871
Log:
    PR fortran/46945
    * trans-array.c (gfc_array_init_size): Perform stride overflow
    checking and multiplication by element_size in size_type_node instead
    of sizetype, return value with size_type_node type instead of
    sometimes with sizetype and sometimes with gfc_array_index_type.

    * gfortran.dg/pr46945.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/pr46945.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/46945] [4.6 Regression] gfortran.dg/unpack_zerosize_1.f90 FAILs with -ftree-vrp -fno-tree-ccp -fno-tree-fre

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

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

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-16 15:05:59 UTC ---
Fixed.