This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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]

Re: gfc_offset question (32 vs. 64 bits)


> #1.  a compiler option is the cleanest from the user perspective, but
> you don't want to make the determination when each module is
> compiled...it would be easy to have an executable with inconsistent
> object.
>
> thinking in this case that a compiler option would set a flag in the
> object that could then direct the i/o library to call the correct
> routine.
>
> not a very good idea.

Right. Commandline option good, flag in object files bad.

> #2.  environment variables look easiest to implement, but it is not
> explicit for the user, probably a source of confusion.
>
> not a great idea.

Agreed.

> #3.  user supplied routines are very flexible, but only the hardest
> of the hard core users will be able to make it work.
>
> most flexible for the "power users".

Right. We'd need to supply common option(s) in an easy to use manner.

> #4.  the library call works, but requires user code changes. (paul's
> recent idea).
>
> simpler but with some complexity.

The user code changes can be avoided using commandline-plus-driver-magic.

> What we need is a "compiler option" that really is only used during
> the link step.  It would select the correct object to link with to
> give the behavior desired.
<...>

Yes, these already exist. eg. -elf2flt in ucLinux ports.

>
> So, how about this option:
>
> #1.  Make several libraries with the couple of routines to implement
> each scheme (libgfortran_crayIO, libgfortan_hpIO, libgfortran_g77IO)
> each library implements the same entry points with an identical
> calling sequence.
>
> #2.  The gfortran or gcc driver get's an additional option to add
> the correct library to the link step.  If the option is specified
> during a normal compile (.F to .o), it is ignored.

#2 sounds good.

For #1 there are other alternatives.

It depends whether we want to be able to switch IO formats from user code at 
runtime, or tie an application to a particular format at link time. If we 
don't care about runtime selection then your idea is fine.

If we want runtime selection the we have a couple of options:-
1) Compile everything into libgfortran like I suggested in my previous mail. 
This implies an arbitrary fixed set of options.
2) Define a callback interface and have libraries register themselves.

We can also supply "magic" object files (linked via equally magic commandline 
options) which contain startup code to select a particular IO method. GCC 
provides [reliable] mechanisms for executing code at startup, so no user code 
changes are required.

Paul


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