DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:reply-to:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=iDJpOmqW+OvyiQO9
	NhV15Cd8AwNwLmqxI+vrgt5/FvCX8+M5mj4rUruRi2YRooMVx3aHwZtk98Tpfv8D
	mAAUBQyNWKLENqySL8B8AyLWd5t8ltvEA43DbNWzdS6gRc3XAqMaFycs1KThXwHX
	axDZQ9/Dp0B7HrtV1ambQMYLrFE=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Message-ID: <52FBDE56.8050304@aol.com>
Date: Wed, 12 Feb 2014 15:49:26 -0500
From: Tim Prince <n8tm@aol.com>
Reply-To: tprince@computer.org
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: g77 on cygwin64
References: <52FAF082.6020805@appstate.edu>	<52FB0686.8080403@gmail.com>	<52FB13E2.1070107@appstate.edu>	<724410821.20140212111451@mtu-net.ru>	<CAMCbSMoqb_TsY3BQSU-AwnCOuCYecwCw4YexBQuUhbAbpSNDQg@mail.gmail.com>	<52FB8E3C.3030704@appstate.edu>	<1436686110.20140212211626@mtu-net.ru> <CAEotdwn+dWCyiw2a6oN987XOP2Fs6BkAfkwChe5ZH3UWs3d=Cg@mail.gmail.com>
In-Reply-To: <CAEotdwn+dWCyiw2a6oN987XOP2Fs6BkAfkwChe5ZH3UWs3d=Cg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


On 2/12/2014 12:59 PM, David Conrad wrote:
> On Wed, Feb 12, 2014 at 12:16 PM, Andrey Repin wrote:
>>> The strange thing is that gfortran does compile the code, but
>>> once compiled, the executables have strange behavior mainly involving
>>> problems reading in data files. ...
>> And this is finally the information, that we can work with.
>> My wild guess is that your "colleagues" making certain assumptions about
>> files, that not always true on other systems.
>> I.e. opening a file in text mode, and then treating [its] data as binary ...
> Since the problem occurs going from 32-bit to 64-bit Cygwin, it sounds
> to me like all-the-world's-a-VAX syndrome. I bet there are places
> where it reads from files and assumes that if it reads N words into
> integers, that is N 32-bit quantities, or something like t:hat. I
> haven't written any Fortran since the 1980s, but I bet there are types
> that have changed size due to the switch to 64-bit and that results in
> reading incorrect values from files, including reading some of them
> from the wrong file offsets, and hitting end-of-file at a different
> point.
>
> Are there any switches to gfortran that control this?
ifort still has switches for selecting the VAX convention of measuring 
RECL in 32-bit words vs. the f2003 recommended convention of byte size.  
gfortran (and afaik g77) used byte lengths only.
Note that 32-bit g77 unformatted direct access files were never intended 
to work with any 64-bit mode compiler (not even the buggy 64-bit g77) 
and can't be expected to work with gfortran (you would need to make 
those data files from scratch):

http://gcc.gnu.org/onlinedocs/gcc-3.4.4/g77/Portable-Unformatted-Files.html

Also important is the point made above that g77 may have allowed 
indiscriminate switching between formatted and unformatted or direct and 
sequential access files, or read after write, but the run-time errors 
should shed light on that, and you would need to watch for unsuspected 
problems if g77 let it through.

--
Tim Prince


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple