From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) by sourceware.org (Postfix) with ESMTPS id A5FA9385B835 for ; Sat, 18 Apr 2020 16:23:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A5FA9385B835 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([24.64.172.44]) by shaw.ca with ESMTP id PqFCjXVHHng7KPqFDjzhqg; Sat, 18 Apr 2020 10:23:03 -0600 X-Authority-Analysis: v=2.3 cv=ecemg4MH c=1 sm=1 tr=0 a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=mDV3o1hIAAAA:8 a=Hf-k9brDjol62_s--vkA:9 a=QEXdDO2ut3YA:10 a=U8TUPWEDoicA:10 a=_FVE-zBwftR9WsbkzFJk:22 Reply-To: cygwin@cygwin.com Subject: Re: gfortran 9.3 write format error (was: segfaulting on valid write statements) To: cygwin@cygwin.com References: From: Brian Inglis Autocrypt: addr=Brian.Inglis@SystematicSw.ab.ca; prefer-encrypt=mutual; keydata= mDMEXopx8xYJKwYBBAHaRw8BAQdAnCK0qv/xwUCCZQoA9BHRYpstERrspfT0NkUWQVuoePa0 LkJyaWFuIEluZ2xpcyA8QnJpYW4uSW5nbGlzQFN5c3RlbWF0aWNTdy5hYi5jYT6IlgQTFggA PhYhBMM5/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQW AgMBAh4BAheAAAoJEB62lxu92I8Y0ioBAI8xrggNxziAVmr+Xm6nnyjoujMqWcq3oEhlYGAO WacZAQDFtdDx2koSVSoOmfaOyRTbIWSf9/Cjai29060fsmdsDLg4BF6KcfMSCisGAQQBl1UB BQEBB0Awv8kHI2PaEgViDqzbnoe8B9KMHoBZLS92HdC7ZPh8HQMBCAeIfgQYFggAJhYhBMM5 /lbU970GBS2bZB62lxu92I8YBQJeinHzAhsMBQkJZgGAAAoJEB62lxu92I8YZwUBAJw/74rF IyaSsGI7ewCdCy88Lce/kdwX7zGwid+f8NZ3AQC/ezTFFi5obXnyMxZJN464nPXiggtT9gN5 RSyTY8X+AQ== Organization: Systematic Software Message-ID: Date: Sat, 18 Apr 2020 10:23:01 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfJd5areLVx83OgvMXYDZNtrrj0QmP8NSr6nmzRs0yCg/m4IMzXPz4v866o7e61iv4KPrXwGYEvDeemE1MsIR8urFM9sqfqowR/lZgufVS6rZlBUBz3aq ytoFV7HgAAvpxZ1oaUiNU8rMeGoOrazZvRbK8TDBcQd1iDzjZy29PlqWl6oF00GGL9MoWODOdr49eA== X-Spam-Status: No, score=-16.5 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 16:23:06 -0000 On 2020-04-17 23:16, Charles Russell wrote: > On 4/17/2020 8:01 PM, Brian Inglis wrote: >> On 2020-04-17 17:33, Charles Russell wrote: >>> At line 889 of file cgcrez.f (unit = 6, file = 'stdout') >>> Fortran runtime error: Missing initial left parenthesis in format >>> ^ >>> Here is the indicated line, using list mode in vim to show that there are no >>> unexpected nonprinting characters: >>> 887 write(6,'(i6,1p3e9.2,x,e9.2,x,0pf6.3,x,1p2e10.2,''@'')')$ >>> 888 & iter, reldf,reldb,$ >>> 889 & gnorms, x1min, -cosag, beta(1),beta(np)$ >>> 890 $ >>> This code compiled and ran on cygwin in the past, and checks out now in debian >>> stable. >>> In my other case, which I may or may not be able to find again, the program >>> failed with no explicit error message like the one above. Stepping through with >>> gdb showed that it was also crashing in a valid write statement. >> Do you perhaps need an extra pair of parentheses to repeat the formatted output, >> perhaps from the second specifier, as you have 5 variable format specifiers and >> 8 variables? > Looks OK to me, and works on debian. > > (i6,        iter > 1p3e9.2,    reldf, reldb, gnorms        > x,        > e9.2,        x1min > x, > 0pf6.3,        -cosag > x, > 1p2e10.2,       beta(1), beta(np) > '' @'') >> Showing a bit more context with all variable declarations would help, and you >> can use cat -A (== -vET) to show non-printing characters e.g. >> >> $ egrep -nw 'iter|reldf|reldb|gnorms|x1min|cosag|beta|write' cgcrez.f | cat -A > > This yields 200 lines of output and I don't see how it helps, but I'll send you > the output if you wish. Regarding declarations, this is fortran 77 code with g77 > extensions using implicit double precision (a-h,o-z), i.e. traditional fortran > type conventions but double precision. The code was originally written using g77 > and gfortran on cygwin, passes ftnchek, and runs fine on current debian stable. > Hard to see how this can be anything but a problem with the current cygwin > compiler or its installation. My program uses a half dozen static libraries > built within the past year (after switching from 32 bit cygwin on windows 7 to > 64 bit cygwin on windows 10). I suppose there might be some mismatch with these > libraries, though I did check to make sure that none of my 32 bit libraries > slipped in. If I have to downgrade the compiler version I'll presumably need to > rebuild all my libraries yet again. Unfortunately without a Simple Test Case it is hard to reproduce the errors and most of us are not (recent) ForTran programmers, and available ForTran docs seem less than rigorous in specifying formatted I/O format requirements, with gfortran providing not even hints. However, one thing we have become used to is more warnings about questionable practices in every release, more warning conditions disrupting compilation such that they are treated as errors, and stricter checking of all aspects of programs. What are your build command lines for the programs giving errors, and what compiler version are you using on Debian - 8.3? You can get more details about the configured and assumed defaults by running on Cygwin and Debian: $ touch null.f $ gfortran -v null.f |& tee gfortran-v.log $ gfortran -### null.f |& tee gfortran-###.log You may not have problems if you are building with default -std=gnu or explicit -std=legacy, but other options may give errors with obsolescent extensions, as your formats may be considered, although as far as I can see, there is no gfortran documentation which would support that. As I did not recognize 1p[23]e... as a repeated format, it is possible that gfortran now requires you to specify that in a more standards compliant manner, except perhaps if you compile with -std=legacy (and the runtime supports that in formatted I/O format strings), otherwise you may want to try restating your formats in a more standard manner e.g. '(i6,3(1pe9.2),x,e9.2,x,0pf6.3,x,2(1pe10.2),''@'')' which may or may not solve your problem. I am shocked that gfortran does not appear to me to support any options for checking string formats at compile time (contrasted with the dozen or so options for C format string checking), controlling formatting conventions used at runtime, or really any rigorous treatment of what format options, grammar, and specifiers are supported at compile time, or in strings at runtime. You may want to check out the (scant) available documentation at: https://gcc.gnu.org/fortran/ https://gcc.gnu.org/wiki/GFortran the mailing list archives at: https://gcc.gnu.org/pipermail/fortran/ https://gcc.gnu.org/legacy-ml/fortran/ especially why gfortran is incompatible with g77: https://gcc.gnu.org/legacy-ml/fortran/2007-01/msg00619.html If changing your formats eliminates the errors, I suggest you report a format compatibility bug against gfortran on the gcc bugzilla, and request they provide some user documentation for supported compiler and runtime formats, other than the doxygen internals docs for gfortran and libgfortran. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.