This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[gfortran,patch] add ISO_FORTRAN_ENV intrinsic module


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
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?


Attachment: iso_fortran_env.ChangeLog
Description: Binary data

Attachment: iso_fortran_env.diff
Description: Binary data

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]