[Patch, Fortran, committed] Fix Fortran bug affecting MinGW-w64, only

[Tobias Burnus]

64bit Windows is special as "long" is only 32bit wide - while pointers 
are 64bit and, hence, wider.

Another special code is gfortran's array descriptor. Its "dtype" field 
is of type ptrdiff_t and it stores the array rank and type in the first 
6 bits and uses the remaining size to store the byte size for an array. 
In case of 32bit systems, one has 32bits - 6 bits = 24 bits (or


There seems to be a single piece of code in gfortran, which assumes that 
a pointer and long have the same width. Namely, the code which checks 
that one can squeeze the array-element size together with the data type 
and the rank into the "dtype" field of the array descriptor, which has 
the type ptrdiff_t.

For a system with 32bit pointer size (= type precision of size_type_node 
or for ptrdiff_t), one has 32 bits minus 6 bits = 26 bits space. Thus, a 
single array element might "only" be 64 mega bytes large. For 64bit 
pointers, 58 bits remain.

For some odd reason, the code does not use size_type_node or something 
equivalent but it uses an unsigned long. On 32bit Windows and on Linux, 
everything is fine. But on 64bit Windows (i.e. MinGW-w64), one tries to 
squeeze 58 bits into a 32bit pointer – which will cause that 
gfc_max_array_element_size has the wrong result.

This patch does the obvious: It masks out the required bits on a 
size_type_node instead.

Committed as obvious as Rev. 212485.

* * *

Unfortunately, that patch does not solve the original problem: On 32bit 
– and now also on 64 bit – Windows, the array and the trailing "done" is 
not printed. One has still to investigate why that fails.

Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: type.diff
Type: text/x-patch
Size: 1238 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20140712/d056df88/attachment.bin>