This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: -frecord-marker
- From: Adrian Umpleby <apumpleby at yahoo dot co dot uk>
- To: fortran at gcc dot gnu dot org
- Date: Tue, 18 Jul 2006 13:53:26 +0100 (BST)
- Subject: Re: -frecord-marker
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ejuSFcDZLBZ6ag0Je41spAX/Q1+Pv6JTxUL8ini6jKjDFP07BvP2OVXbPnlrFXqbN1QuKkW76L3V2IDwF5i9qF+ypfOLvQwtFZhK/NQ3pAbeh+8Kpgnrd9yGdZXZlIw47jzgxtWei/mCGrEOzNiBoq7jJkNipdxIAj3tA+LT3gQ= ;
>>> According to the gfortran man page, -frecord-marker seems to be a command-line
>>> option - i.e. you add it when you run the compiled executable:
>>> ./myprog -frecord-marker=4
>>
>> -frecord-marker=4 is a compile-time option. You need to specify this
>> on the command line, as with "gfortran -frecord-marker=4".
Well, after creating a short test, it's clear it's not a runtime option (which is what the online
manual and man page claims).
Also, for a subroutine, it's not actually a compile-time option either, since:
gfortran -frecord-marker=4 -c mysub.f
gives exactly the same object as:
gfortran -frecord-marker=8 -c mysub.f
Which is why I assumed it must be strictly a linker option - i.e. the following, linking in the
object created in the lines above:
gfortran -frecord-marker=4 mymain.f mysub.o -o myprog.exe
However, it looks like I was wrong in both senses, since, as Keith says below, it *only* applies
to compiling the main program itself, and it's not applied at link time.
So:
gfortran -frecord-marker=4 -c mymain.f
does produce a different object to:
gfortran -frecord-marker=8 -c mymain.f
Dead annoying!
> It only works if the main routine is written in Fortran. I've been meaning
> to bring this up for a while because it makes it impossible to write
> libraries using gfortran which are then called by C. (something I do all
> the time at work).
It also makes it impossible to write a program that could test for and read either format.
If gfortran is going to behave in a way which is unusable with (the default for) all previous
Fortran compilers, I'd suggest it needs an extension to make it compatible on a case-by-case basis
- preferably in OPEN itself.
Looks like I'll have to join gcc bugzilla and start making a noise...
> I always preferred the intel method, but no-one seems to want to implement
> that. Maybe I'll get around to it myself one of these days.
Yes, it would be nice to have that option - there was talk, in the early days of getting this
compatibility added to gfortran (as a runtime option!), of including support for hp format, but I
don't see mention of intel's way of dealing with this as a possibility for gfortran, which is a
pity.
Maybe I'll start digging around in the gfortran source to see what I can do about it myself...
Thanks!
Adrian
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html