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
