I see
D.1631 = izz.dim[0].lbound;
D.1632 = izz.dim[0].ubound;
D.1643 = D.1632 - D.1631;
D.1647 = D.1643 < 0;
D.1648 = D.1643 + 1;
D.1649 = D.1647 ? 0 : D.1648 * 8;
if (D.1649 < 0)
{
_gfortran_runtime_error (&"Attempt to allocate
a negative amount of memory."[1]{lb: 1 sz: 1});
}
D.1650 = (void * restrict) __builtin_malloc
(MAX_EXPR <D.1649, 1>);
if (D.1650 == 0B)
{
_gfortran_os_error (&"Memory allocation
failed"[1]{lb: 1 sz: 1});
}
D.1651 = D.1650;
atmp.5.data = D.1651;
so, we check if the array-size is empty, ubound - lbound < 0. In that
case we set size to zero. Otherwise we compute it as (ubound - lbound + 1) *
8.
Then we check whether size is negative and error out.
Then we actually allocate max(1,size).
Why do we at all check for this "negative" amount allocation? Are you
trying to detect overflow here? (which won't work, you do the
computation with signed arithmetic so VRP will screw you anyway)
Why not simply do
size = (ubound - lbound + 1) * 8;
malloc (size);
which surely fails very quickly on you for negative size and the allocation
fails.
?
Surely for compiler-generated temporary allocations nothing more fancy
should be required (even the check of the allocation could be removed
when optimizing).
--
Summary: Weird temporary array allocation
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
