Re: [RFC PATCH] _gfortran_{ioparm,filename,line} vs. thread-safety

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Oct 07, 2005 at 12:07:20AM +0200, Thomas Koenig wrote:
> On Tue, Oct 04, 2005 at 06:52:34PM -0400, Jakub Jelinek wrote:
> > The patch below already has the corresponding Fortran backend changes
> > and even 100% passes make check-gfortran on x86_64-linux.
> > What I wrote on Monday below still holds, but the further changes
> > shouldn't hopefully impact library's ABI (except maybe for the size of
> > the libgfortran's private area in st_parameter_dt).
> 
> If we go about changing the ABI anyway, should we also put in a way to
> correctly read/write integer(kind=8) variables, so -fdefault-integer-8
> can work (PR 21647)?

I think there are 2 kinds of vars here.  At least the logical*8
output vars should be handled by writing into a temporary logical*4
and then copying into logical*8.  This is pretty trivial thing to do,
will change it tomorrow in my patch.
Then there is a whole bunch of integer variables, either input ones
(such as UNIT=) or output ones.
There are 3 options:
1) it is enough to support -2GB..2GB values for that var; in that
case it could be handled the same way as logical*8, via a integer*4
temporary (e.g. do we need unit numbers > 2GB?)
2) or the library can use always integer*8 and if source needs
integer*4, use a temporary
3) or, especially for non-INQUIRE variables, we could perhaps support
both, just by allocating another bit for it in the flags bitmask.

	Jakub