[fortran,patch] Forbid assignment of different character kinds

[FX]

Hi all,

When I added support for nondefault initial character kinds, I thought they could be assigned freely to each other. It turns out it’s not the case: this is PR 37173.
The attached patch simplifies the front-end by dropping support for conversion: then, the generic conversion code generates a sensible error message.
I also fixed some testcases (including some co-array testing), and removed two of them that only exercised this specific aspect.

Tobias: I think the CAF library could also be simplified by dropping this nonfeature, but I don’t know it well (have never built it, used it or tested it) to do so.

Bootstrapped and regtested on x86_64-apple-darwin14. OK to commit?

FX


PS: given the little feedback we get on that feature, I suppose nobody actually uses nondefault character kinds. Just like it seems nobody uses the IEEE modules (no feedback received, at all, since implementation). I suppose that makes me the kind of implementing useless standard features. What’s next?

[Tobias Burnus]

Hi FX,
Am am vaguely remembering that some interpretation request/change now
allows this.

And if I look at the current Fortran 2015 draft, I find

"For an intrinsic assignment statement where the variable is of type
character, if expr has a different kind type parameter, each character c
in expr is converted to the kind type parameterof the variable by
ACHAR(IACHAR(c), KIND(variable))"

See http://j3-fortran.org/doc/year/14/14-007r2.pdf, "7.2.1.3
Interpretation of intrinsic assignments", paragraph 11.

I have rechecked Fortran 2008 (10-007) - and it has the same wording. It
could be either already F2003 - added in some corrigendum or Fortran
2008 – feel free to check the corrigenda:
https://gcc.gnu.org/wiki/GFortranStandards

Tobias

[FX]

It looks like the committee has reversed his opinion on this since the 2008 interp. There is wording in both F2003 and F2008 standards that supports this view, so I’ve closed the PR.

Now, here’s a tiny patch to silence the related warning in PR36534. I also remove the condition on gfc_current_form != FORM_FIXED, as diagnostics should be emitted based on language/pedantic options, not source form.

Regtested on x86_64-apple-darwin14, comes with a testcase. OK to commit?

FX

[Tobias Burnus]

Now, here's a tiny patch to silence the related warning in PR36534.
I also remove the condition on gfc_current_form != FORM_FIXED, as diagnostics
should be emitted based on language/pedantic options, not source form.

Looks good to me. However:

In the test case, could you also add a "PR fortran/36534" to the
as comment?


Additionally, I wonder whether instead of the name-based checking
+ && (sym->name[0] != '_' || sym->name[1] != '_'))
it wouldn't be cleaner to check
&& sym->attr.intrinsic
(If you change it to attr.intrinsic, you need to set
the attribute also in intrinsic.c's gfc_convert_type_warn.)

I know that using __... names it not really possible in Fortran (except as C
binding name), but - still - I think it is cleaner. But I am fine with
either version.

Tobias

[FX]

Post by Tobias Burnus
In the test case, could you also add a "PR fortran/36534" to the
as comment?

Sure.

Post by Tobias Burnus
Additionally, I wonder whether instead of the name-based checking
+ && (sym->name[0] != '_' || sym->name[1] != '_'))
it wouldn't be cleaner to check
&& sym->attr.intrinsic
(If you change it to attr.intrinsic, you need to set
the attribute also in intrinsic.c's gfc_convert_type_warn.)
I know that using __... names it not really possible in Fortran (except as C
binding name), but - still - I think it is cleaner. But I am fine with
either version.

OK, it sounds logical, so I tried that… it gets caught later in resolve.c, saying “… declared INTRINSIC at %L does not exist”, because it’s not actually a proper intrinsic, it’s just a function call manually constructed.

In the interest of minimal modification of this code, I have committed the original approach as rev. 215887.

Thanks for the review.
FX