------- Comment #12 from burnus at gcc dot gnu dot org 2010-03-28 12:57 ------- (In reply to comment #8) > atmp.5.dim[0].lbound = 0; > atmp.5.dim[0].ubound = D.1612; > D.1616 = D.1612 < 0; > D.1617 = D.1612 + 1; > D.1618 = D.1616 ? 0 : D.1617 * 8; > > but there's still the conditional on negative D.1612.
I think that check is needed: If one has: array(1:0) or array(1:-200) or array(1:100:-1) that means that one has a zero-sized array. If one had no such check one would allocate "negative memory" which matches - as the malloc argument is unsigned - a large positive number. Maybe there are cases where one knows before hand that the array cannot be zero-sized, but in the general case one cannot. (I am thinking of call f(array(...)) where one knows that "f" does not allow for a zero-sized array argument. In the other known cases, the upper bound should be already known at compile time and the check should be folded away. Maybe there are more such cases.) > Also deallocation is > D.1621 = (void *) atmp.5.data; > if (D.1621 != 0B) > __builtin_free (D.1621); > > where the check for NULL is not necessary (though the middle end might > be able to remove that condition). I think one can remove the check as __builtin_free also can deal with NULL arguments, but it is not known before hand whether the argument is NULL as - in the general case - one can manually deallocate arrays. Well, for generated temporary arrays (which the user cannot directly access), one can know whether the pointer is NULL and thus one could remove the check. Such a patch should be rather simple. > another missed middle-end optimization, > p = malloc(1); free (p); isn't optimized away I think it would be useful, if the middle end were able to do so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
