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: -frecord-marker


> > Why can't the -frecord-marker option be made into a proper compile-time
> > option as Adrian was suggesting?
> 
> We could put the various record-marker flags into the build_dt so that every 
> unit will have its own settings depending on options at compile time.  Then this 
> would not depend on the settings for the main program.  To mix methods within a 
> program, you would have to have separate object files for each, compiled with 
> different compile time options.
> 
> We have 17 unused bits left in the dt structure without increasing the size any. 
>   We could set endian-ness, record-marker size, and I suppose record marker scheme
> at compile time and test bits at run time. That would take 3 bits, 0 for 
> default, 1 for special.
> 
> We could do this without touching OPEN syntax.  It would be left to the user to 
> sort out the options when compiling.  And then I suppose some non-standard 
> intrinsics could show up later to set bits on the fly, but thats another story, 
> and would be very gnuish. (It  could also be troublesome if not thought through 
> carefully.  You wouldn't want a file half 32 bit markers, half 64, and part intel)
> 
> I think there may be a middle ground approach on this. (or am I being to easy?)

As I've said before, my main intention in adding the tag to OPEN was not that it would necessarily
be used as such, but so that each unit could be given its own setting, which could then be
manipulated by whatever means the programmer wanted - an extra in-code tag in OPEN, if desired,
but also using -frecord-marker=something when compiling (so that code could be the same, which is
useful if it's released and likely to be compiled with various compilers).

Again, to make it clear, I've not only added the tag to OPEN, but also made -frecord-marker act
per object to manipulate the internal per-unit data, simulating the addition of the tag - so
there's no need for the programmer to even be aware of this extra OPEN tag if not wanted  :)

The only things that really need doing are to sort out the behaviour of the previous
-frecord-marker (i.e. remove all the compile_options.record_marker related code) and to decide
whether we want to change the -frecord-marker option so it effectively takes a string (such as
'4byte', '8byte', 'intel', etc. - we could keep backward-compatibility, I guess, allowing '4' and
'8').

Of course, there's also tha possibility of implementing the Intel record-marker format within
gfortran - having looked through the code some more, I think I could probably do it now.

Bye!

Adrian



		
___________________________________________________________ 
Try the all-new Yahoo! Mail. "The New Version is radically easier to use" ? The Wall Street Journal 
http://uk.docs.yahoo.com/nowyoucan.html


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