Hi Bernhard,
Am 12.11.21 um 22:58 schrieb Bernhard Reutner-Fischer via Fortran:
On Fri, 12 Nov 2021 21:35:42 +0100
Harald Anlauf <anl...@gmx.de> wrote:
Hi Bernhard,
Am 12.11.21 um 21:18 schrieb Bernhard Reutner-Fischer via Fortran:
On Fri, 12 Nov 2021 18:39:48 +0100
Harald Anlauf via Fortran <fortran@gcc.gnu.org> wrote:
Sounds plausible.
this is what I thought, too. And nvfortran and flang accept the
testcase, as well as crayftn (cce/12.0.2).
Don't know about the former 2, but cray is really the MIPS compiler
(open64 / pathscale etc), no?
I thought that most of Cray's compilers was their own development
targeting their vector hardware. My own experience is limited to
their compilers on x86-type systems (+ GPUs). They seemed to be
rather progressive in developing the Fortran standard as well as
implementing it in their own compilers, besides supporting open
standards. (That seemed to slow down w.r.t. OpenACC).
I always liked the SGI compiler (it was marvellous in mem addressing
really, at least in my cases in former times) but i'm not familiar with
the other two so cannot deduct anything from their opinion TBH.
Intel accepts the first case (a), but rejects the second (b).
I asked in the Intel forum. Steve Lionel doubts that the code is
valid.
On what grounds does Steve L. think it's invalid? Missing initializer
to rectify the len=8? If so, what's the reasoning to doubt that?
See:
https://community.intel.com/t5/Intel-Fortran-Compiler/Interoperability-of-character-variables/td-p/1329554
There might be some confusion on my side, but having Cray on my
side feels good. (Although the PR was entered into bugzilla by
a Cray employee).
Vendors. Well. It would certainly be the first time a vendor was not
entirely correct.
IME vendors tended to favour compatibility over correctness more often
than not. This certainly may have, erm, has changed.
Well, Cray not only sells hardware, but systems with support.
You get multiple programming environments on their systems,
one of which is likely cce (Cray Compilation Environment),
and very often the GNU compilers. Depending on the contract
you get in addition Intel, Nvidia, ...
Users may report issues with these components through their
support contract. With GNU, I guess they just add a PR to
bugzilla; with commercial software vendors their might be
different ways.
are caught elsewhere if assumes that len should be a positive int > 0 (didn't
look)
Also did not look if
character(kind=c_char, len=SELECTED_REAL_KIND(10)) :: j ! is that constant?
Should it be?
These things should already be handled in general and
elsewhere, as they are not about interoperability.
Excellent. I'd ACK your patch then but i cannot approve it.
Thanks for the patch and cheers,
There'll be a way to resolve this PR. Maybe Tobias or Thomas have
an opinion. There are strange ways in the standard anyway to pass
Fortran character strings to BIND(C) procedures. Look e.g. at
"5.5.2.11 Sequence association" which sort of hacks this situation
for some applications relevant to me.
Cheers,
Harald
