[gfortran,patch] add ISO_FORTRAN_ENV intrinsic module

[FX Coudert]

Hi,

> I am having some difficulty with this proposal; perhaps because I  
> am ignorant on the format of the F2003 intrinsic modules.  Why is  
> it necessary to have custom code for each new intrinsic module?   
> Would it not be better, as I wrote elsewhere, to have .mod files  
> and a library in a special directory for intrinsic modules?  That  
> way, the existing module code could be used, with the addition of  
> your bits to sort out intrinsic and non-intrinsic.

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.

> What structure has Christopher adopted?

Front-end handled with external helper lib functions.

>>    b) the code USEing non-intrinsic modules (in module.c) to issue an
>> error if an intrinsic module of the same name was already USEd; ie,
>> I'd like the following to error out (while, with my patch, it does
>> not):
> You'll have to find the module symbol, check if it's intrinsic and  
> throw on the new module being non-intrinsic.

OK, thanks. Updated patch attached.

>> module iso_fortran_env
>> end module iso_fortran_env
>>
>> program foo
>>  use, intrinsic :: iso_fortran_env
>>  use, non_intrinsic :: iso_fortran_env ! This should issue an error
>> end program foo
> ...and the other way round, I suppose!

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.

> convince me that what you are doing is OK!

I'll try as hard as I can. What do I need to do to convince you? :)


Updated patch, including testsuite coverage, attached. Regtested on  
i686-linux. Any new comments anyone? OK for mainline?

FX



-------------- next part --------------
A non-text attachment was scrubbed...
Name: iso_fortran_env.ChangeLog
Type: application/octet-stream
Size: 538 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20061030/a1ebe5bc/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iso_fortran_env.diff
Type: application/octet-stream
Size: 17908 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20061030/a1ebe5bc/attachment-0001.obj>