Re: [PATCH] fortran: Create a dedicated type for ranks and array dimensions

Thomas Schwinge <[email protected]> Fri, 24 Jul 2026 17:25:52 +0200
Newsgroups gmane.comp.gcc.patches,gmane.comp.gcc.fortran
Message-ID <[email protected]>
Hi Mikael!

On 2026-07-21T17:04:28+0200, Mikael Morin <[email protected]> wrote:
> Le 20/07/2026 =C3=A0 20:23, Thomas Schwinge a =C3=A9crit=C2=A0:
>> On 2026-07-08T11:14:38+0200, Mikael Morin <[email protected]> wrote:
>>> Le 06/07/2026 =C3=A0 22:02, Harald Anlauf a =C3=A9crit=C2=A0:
>>>> On 7/6/26 11:35, Mikael Morin wrote:
>>>>> This started as [...], but I eventually
>>>>> convinced myself that the snippet above showed a lack of a type readi=
ly
>>>>> available to represent ranks and array dimensions.=C2=A0 This patchs =
adds
>>>>> such a type.
>>=20
>> Nice work!
>>=20
>> I had reason to look into what this patch is doing (details to be sent
>> later; just quickly: your patch appears to have uncovered a latent issue
>> in generic GCC middle end, resulting in ICEs for certain targets)=20
> Is there a PR for it?

Now there is: <https://gcc.gnu.org/PR126392>
"'GIMPLE_SWITCH' lowering for 'INTEGER_TYPE' subrange wrappers vs. targets =
without 'casesi'/'tablejump'",
and patch:
<https://inbox.sourceware.org/[email protected]=
om>
"In 'range_check_type', peel off 'INTEGER_TYPE' subrange wrappers [PR126392=
]".


Gr=C3=BC=C3=9Fe
 Thomas


>> -- so I
>> therefore attempted to have a quick look there, whether that's the same
>> issue:
>>=20
>>> I received an aarch64 regression notification from the linaro CI bot,
>>> but could not reproduce it, so I will push the patch as submitted [...]
>>=20
>> I assume you mean the one linked from
>> <https://patchwork.sourceware.org/project/gcc/patch/65a3d4ec-5476-44bf-8=
[email protected]/>:
>> "linaro-tcwg-bot/tcwg_simplebootstrap_build--master-aarch64-bootstrap",
>> "Check": "fail", "Description": "Build failed"?=20
> Yes.
>
>> I traced that one down
>> per the artifacts/log files they link to, and the failure was good ol'
>> "[...] fatal error: error writing to [...]: No space left on device", so
>> indeed nothing for you to worry about.  ;-)
> Thanks.  That's the tip I was missing.  The error is easy to find if one=
=20
> searches for "No space left".