[Bug fortran/28105] New: Check for memory allocations bigger than size_t

[Bug fortran/28105] New: Check for memory allocations bigger than size_t

[tobias dot burnus at physik dot fu-berlin dot de]

sizeof(size_t) on ia32 is 4 thus 2^32 = 4,294,967,296 Byte can be accessed by
unsigned.
   real(4), dimension(1025*1024*1024) :: m
can thus not be accessed on ia32. Currently, gfortran does detect this overflow
at compile time.

Expected: The same as ifort:
fortcom: Error: mem.f, line 3: A common block or variable may not exceed
2147483647 bytes
      REAL(4), DIMENSION(1074790400) :: T
-----------------------------------^)

(2147483647 = 2^31-1 -> signed int32.)

Analogously for allocate() of pointers and arrays. Currently this does not fail
even if sizeof(datatype)*size overflows size_t. As size_t is always possitive,
the malloc() works sucessfully. In my case it produces:
1074790400*4 = 4194304. I get a coredump if I access T(1048577) as I only
allocated T(1:1048576:1).

Other compilers seem to have an overflow check somewhere. Maybe it works the
following [symbolically written]
  if(size > 2**sizeof(size_t)/sizeof(datatype)) call error()
at least they return a non-successful status with allocate.


-- 
           Summary: Check for memory allocations bigger than size_t
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tobias dot burnus at physik dot fu-berlin dot de


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

[Bug fortran/28105] Check for memory allocations bigger than size_t

[manu at gcc dot gnu dot org]

------- Comment #1 from manu at gcc dot gnu dot org  2007-02-14 15:43 -------
Will this be appropriate for all front-ends? Then, this is a duplicate of (or
very related to) bug 18063.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org


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

[Bug fortran/28105] Check for memory allocations bigger than size_t

[fxcoudert at gcc dot gnu dot org]

------- Comment #2 from fxcoudert at gcc dot gnu dot org  2007-04-18 07:05 -------
(In reply to comment #1)
> Will this be appropriate for all front-ends? Then, this is a duplicate of (or
> very related to) bug 18063.

We probably want runtime checks generated by the Fortran front-end for this
case, unlike what people want for C, thus it's not a complete duplicate.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |diagnostic
   Last reconfirmed|0000-00-00 00:00:00         |2007-04-18 07:05:54
               date|                            |


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

[Bug fortran/28105] Check for memory allocations bigger than size_t

[dfranke at gcc dot gnu dot org]

------- Comment #3 from dfranke at gcc dot gnu dot org  2009-04-15 12:30 -------
*** Bug 39772 has been marked as a duplicate of this bug. ***


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jv244 at cam dot ac dot uk


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

[Bug fortran/28105] Check for memory allocations bigger than size_t

[jb at gcc dot gnu.org]

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

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jb at gcc dot gnu.org
         AssignedTo|unassigned at gcc dot       |jb at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #4 from Janne Blomqvist <jb at gcc dot gnu.org> 2010-11-19 23:48:39 UTC ---
Assigning to myself.

[Bug fortran/28105] Check for memory allocations bigger than size_t

[jb at gcc dot gnu.org]

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

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-p
                   |                            |atches/2010-11/msg02299.htm
                   |                            |l

--- Comment #5 from Janne Blomqvist <jb at gcc dot gnu.org> 2010-11-22 22:43:10 UTC ---
Patch http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02299.html

[Bug fortran/28105] Check for memory allocations bigger than size_t

[jb at gcc dot gnu.org]

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

--- Comment #6 from Janne Blomqvist <jb at gcc dot gnu.org> 2010-11-30 21:33:36 UTC ---
Author: jb
Date: Tue Nov 30 21:33:32 2010
New Revision: 167317

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167317
Log:
PR fortran/28105 Overflow check for ALLOCATE statement

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c

[Bug fortran/28105] Check for memory allocations bigger than size_t

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-01 11:04:06 UTC ---
I have played a bit around with the following (which has to be compiled on a
system with 32bit size_t):

   real(8), dimension(1024*1024*1024) :: m
   m(1)= 0
   print *, 1024*1024*1024 ! * 8 -> overflow
   print *, huge(3)
   print *, 2_8**32
   print *, 4_8*1024*1024*1024
   end

However, I fail to get any compile- or run-time error. Expected: As with the
following code, one gets a compile-time error:

$ gfortran -m32 hjff3.f90
.test.f90:1:0: error: size of variable ‘m’ is too large

   real(8), dimension(huge(3)) :: m
   m(1)= 0
   end

[Bug fortran/28105] Check for memory allocations bigger than size_t

[jb at gcc dot gnu.org]

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

--- Comment #8 from Janne Blomqvist <jb at gcc dot gnu.org> 2010-12-01 14:43:55 UTC ---
AFAICS the patch I committed in #6 as r167317 only changes how the ALLOCATE
statement is compiled. For automatic and static arrays, different codepaths are
chosen. 

In principle we should be able to catch the example in #7 at compile-time. But
intuitively that would require us to check overflow after constant propagation;
I don't know how easy that would be to do and what other effects such a change
might bring.

Or, perhaps a simpler approach would be to generate the array setup code with
runtime overflow checks, and rely on the optimizers to remove the test at
runtime for constant bounds; that is, essentially what the ALLOCATE code does?

[Bug fortran/28105] Check for memory allocations bigger than size_t

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-01 15:38:52 UTC ---
(In reply to comment #8)
> For automatic and static arrays, different code paths are chosen.

I think one should try to get some checking working for INTEGER_CST_P only,
i.e. independent whether one uses automatic or static arrays or in the ALLOCATE
statement, a compile-time error should be printed. I am not sure that one needs
a run-time error - and if so, only with -fcheck=mem.

I think one should do something like:

if (INTEGER_CST_P (size))
  {
     if (!host_integerp (DECL_SIZE_UNIT (size), 1))
       goto too_large = true;
     if (TREE_INT_CST_LOW (size)
         > TYPE_MAX_VALUE (sizetype)/TREE_INT_CST_LOW (element_size)
       goto too_large;
  }

if (!host_integerp (DECL_SIZE_UNIT (decl), 1))
  goto too_large;

too_large:
    gfc_error (...);

[Bug fortran/28105] Check for memory allocations bigger than size_t

[Joost.VandeVondele at pci dot uzh.ch]

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

--- Comment #10 from Joost VandeVondele <Joost.VandeVondele at pci dot uzh.ch> 2010-12-02 07:35:03 UTC ---
BTW, there is some similar thread for C++, maybe ideas can be copied:

http://gcc.gnu.org/ml/gcc/2010-12/msg00053.html

[Bug fortran/28105] Check for memory allocations bigger than size_t

[jb at gcc dot gnu.org]

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

--- Comment #11 from Janne Blomqvist <jb at gcc dot gnu.org> 2010-12-15 17:15:31 UTC ---
Author: jb
Date: Wed Dec 15 17:15:25 2010
New Revision: 167860

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167860
Log:
PR 28105 Remove size<0 checks before calling malloc/realloc

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans.c

[Bug fortran/28105] Check for memory allocations bigger than size_t

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

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

--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Since gfortran 4.8.1 up to trunk I get

pr28105.f90:1:0: error: size of variable 'm' is too large
    real(4), dimension(1025*1024*1024) :: m

when compiling 

   real(4), dimension(1025*1024*1024) :: m
   m = 0.
   print *, m(1025*1024*1024)
end

with -m32. Revision 187017 (2012-05-01) does not give any error, but revision
187060 (2012-05-02) does. Closing as FIXED. Please reopen if I am wrong.