On Tue, Dec 05, 2023 at 10:57:50AM +0000, Richard Earnshaw wrote:
> On 05/12/2023 10:51, Jakub Jelinek wrote:
> > On Tue, Dec 05, 2023 at 10:47:34AM +0000, Richard Earnshaw wrote:
> > > > The following patch makes libgfortran build on i686-linux after hacking
> > > > up
> > > > --- kinds.h.xx 2023-12-05 00:23:00.133365064 +0100
> > > > +++ kinds.h 2023-12-05 11:19:24.409679808 +0100
> > > > @@ -10,8 +10,8 @@ typedef GFC_INTEGER_2 GFC_LOGICAL_2;
> > > > #define HAVE_GFC_LOGICAL_2
> > > > #define HAVE_GFC_INTEGER_2
> > > > -typedef int32_t GFC_INTEGER_4;
> > > > -typedef uint32_t GFC_UINTEGER_4;
> > > > +typedef long GFC_INTEGER_4;
> > > > +typedef unsigned long GFC_UINTEGER_4;
> > >
> > > That doesn't look right for a 64-bit processor. Presumably 4 means 4
> > > bytes,
> >
> > i686-linux is an ILP32 target, which I chose exactly because I regularly
> > build
> > it, had a tree with it around and because unlike 64-bit targets there are 2
> > standard 32-bit signed integer types. Though, normally int32_t there is
> > int rather than long int and so the errors only appeared after this hack.
> >
>
> My point is that on aarch64/x86_64 etc, this will make GFC_INTEGER_4 a
> 64-bit type, whereas previously it was 32-bit.
Sure. The above patch is a hack for a generated header. I'm not proposing
that as a change, just explaining how I've verified the actual patch on
i686-linux with such a hack.
Jakub
