On 05/12/2023 10:59, Jakub Jelinek wrote:
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


Ah, I understand now.

I've successfully built arm and aarch64 cross toolchains with this patch (newlib). So LGTM, thanks.

R.

Reply via email to