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.