Re: [gfortran,patch] add ISO_FORTRAN_ENV intrinsic module

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Mon, Oct 30, 2006 at 11:48:22PM +0100, FX Coudert wrote:
>
> Some of the constructs have to be recognized by the compiler, for  
> example for simplification as compile-time. It's not the case here,  
> but for some parts of  the IEEE_ modules or for the ISO_C_BINDING  
> module, some functions are required to be evaluated at compile-time  
> (SELECTED_IEEE_REAL_KIND) and some achiever huge code simplification  
> at compile-time (C_ASSOCIATED, C_FUNLOC, C_LOC, etc.).
> 
> Moreover, the value or behaviour of some symbols depends on compile- 
> time switches (C_LONG_DOUBLE will depend on -m128-long-double, and  
> other similar stuff), more that the multilib system allows us to.
> 
> So, all in all, having pre-compiled module files (that's how I call  
> the .mod files that are put with the library) for some things and  
> front-end handled symbols for others. I'm trying to keep things  
> relatively clean (a .def file, separate routines in module.c) so that  
> doesn't imply that the front-end will become a mess.

Thanks for the details.  I was wondering why your -fintrinsic-module
option required a user to specify a path.  I now see that the module
must match its library and the multilib feature means multiple modules.

> 
> The other way around is already implemented, if you can assure me  
> that, when non-intrinsic modules are read, the module_symbol- 
> >attr.intrinsic bit is garanteed to be set to 0. I haven't managed  
> to see where that is handled.
> 

Memory is normally grabbed via gfc_getmem().  This function
always zeroes out the memory.  I suspect you can assume that
the attr.intrinsic bit is always zero.



-- 
Steve