Le 29/07/2026 à 08:47, Richard Biener a écrit :
On Tue, 28 Jul 2026, Mikael Morin wrote:
Le 28/07/2026 à 17:22, Richard Biener a écrit :
On Tue, 28 Jul 2026, Richard Biener wrote:
On Tue, 28 Jul 2026, Richard Biener wrote:
On Tue, 28 Jul 2026, Richard Biener wrote:
On Tue, 28 Jul 2026, Thomas Schwinge wrote:
Hi Richard!
Thanks for looking into this! Regarding your review:
On 2026-07-28T08:11:46+0200, Richard Biener <[email protected]> wrote:
On Fri, 24 Jul 2026, Thomas Schwinge wrote:
--- a/gcc/fortran/trans-types.cc
+++ b/gcc/fortran/trans-types.cc
[...]
+tree gfc_array_dim_rank_type;
[...]
@@ -1226,6 +1227,12 @@ gfc_init_types (void)
gfc_charlen_int_kind = get_int_kind_from_node
(size_type_node);
gfc_charlen_type_node = gfc_get_int_type
(gfc_charlen_int_kind);
+ gfc_array_dim_rank_type
+ = build_range_type (signed_char_type_node,
And basing this on unsigned_char_type_node might be an easier fix?
But unsigned types have the same problem, don't they?
Say if the type is [20, 30] and we are trying to check that a value v is
within say [21, 24], a transformation to check that v - 21 is within [0, 3]
can't use the original type because the values are no longer in the range of
the original type.
Sure, but we're using an unsigned type of the original types precision
anyway. And in the gfortran case the low bound is zero, so we
have [0, MAX_DIMENSIONS], meaning an unsigned char base type sounds
appropriate?
Well, I very much prefer the undefined overflow semantics of signed
types over the modulus semantics of unsigned. But if you can confirm
that signedness doesn't matter ABI-wise, unsigned char can surely be
used here.
But I don't get how it is a fix. It probably avoids the regression, but
a latent problem remains. For the "fix" to be complete, the
[0,MAX_DIMENSION] (unsigned) type has to be extended to a full unsigned
char for the range check transformation, just like Thomas' original
patch did.
