PR 49755 - Patch finished but I have questions.

[Daniel Carrera]

On 07/26/2011 09:15 AM, Tobias Burnus wrote:
>> stat.0 = 0;
>> a.data = ... __builtin_malloc (1600);
>> if ( ... (a.data == 0B), 0))
>
> First, for "if (stat.0 == 0)" I would make this if branch as likely -
> and the "if (stat.0 != 0)" as unlikely, cf. gfc_unlikely in trans.c.
>
> Secondly, I wonder what happens if malloc fails. In the current code,
> one directly modifies the variable such that afterwards the one has a
> pointer to NULL. I think from the wording of the standard, one would
> keep the current allocation status. I think one might need to
> reintroduce a temporary variable for the case that malloc fails.


Are you sure? If the variable *has* any sort of existing allocation, the 
code will never reach the malloc line. The malloc only happens if the 
variable is not already allocated, in which case, the malloc is not 
destroying anything.



> Example: The following program should print a nonzero stat value, a
> shape of "43 100 100" and then 43 times "42"; example with ifort:
>
> 151
> 43 100 100
> 42 42 42 42 42 42
> 42 42 42 42 42 42
> 42 42 42 42 42 42
> 42 42 42 42 42 42
> 42 42 42 42 42 42
> 42 42 42 42 42 42
> 42 42 42 42 42 42
> 42
>
> (I assume that 148 GB is too large for malloc but that it still does not
> overflow; this assumption should hold for most 64bit systems.)
>
> integer,allocatable :: A(:,:,:)
> allocate(A(43,100,100))
> A(:,1,1) = 42
> allocate(A(30*1024,1024,1024), stat=i)
> print *, i
> print *, shape(a)
> print *, A(:,1,1)
> end

I haven't tested (and I don't have a 64-bit system) but AFAICT this 
should work correctly with my patch. The program figures out that "A" is 
already allocated so it never goes to the malloc line.

Daniel.
-- 
I'm not overweight, I'm undertall.