[PATCH] libgfortran: Fix -Wincompatible-pointer-types errors
Hi!
On Tue, Dec 05, 2023 at 10:46:02AM +0100, Florian Weimer wrote:
> Presumably the fixes will look like this?
>
> diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
> index db3330060ce..4fcc77dbf83 100644
> --- a/libgfortran/io/list_read.c
> +++ b/libgfortran/io/list_read.c
> @@ -2987,13 +2987,13 @@ nml_read_obj (st_parameter_dt *dtp, namelist_info
> *nl, index_type offset,
> /* If this object has a User Defined procedure, call it. */
> if (nl->dtio_sub != NULL)
> {
> - int unit = dtp->u.p.current_unit->unit_number;
> + GFC_INTEGER_4 unit = dtp->u.p.current_unit->unit_number;
> char iotype[] = "NAMELIST";
> gfc_charlen_type iotype_len = 8;
> char tmp_iomsg[IOMSG_LEN] = "";
> char *child_iomsg;
> gfc_charlen_type child_iomsg_len;
> - int noiostat;
> + GFC_INTEGER_4 noiostat;
> int *child_iostat = NULL;
> gfc_full_array_i4 vlist;
> formatted_dtio dtio_ptr = (formatted_dtio)nl->dtio_sub;
That seems insufficient.
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;
typedef GFC_INTEGER_4 GFC_LOGICAL_4;
#define HAVE_GFC_LOGICAL_4
#define HAVE_GFC_INTEGER_4
in the build dir to emulate what newlib aarch64 is doing:
2023-12-05 Florian Weimer
Jakub Jelinek
* io/list_read.c (list_formatted_read_scalar) :
Change types of unit and noiostat to GFC_INTEGER_4 from int, change
type of child_iostat from to GFC_INTEGER_4 * from int *, formatting
fixes.
(nml_read_obj): Likewise.
* io/write.c (list_formatted_write_scalar) : Likewise.
(nml_write_obj): Likewise.
* io/transfer.c (unformatted_read, unformatted_write): Likewise.
--- libgfortran/io/list_read.c.jj 2023-05-09 00:07:26.161168737 +0200
+++ libgfortran/io/list_read.c 2023-12-05 11:25:31.837426653 +0100
@@ -2189,14 +2189,14 @@ list_formatted_read_scalar (st_parameter
break;
case BT_CLASS:
{
- int unit = dtp->u.p.current_unit->unit_number;
+ GFC_INTEGER_4 unit = dtp->u.p.current_unit->unit_number;
char iotype[] = "LISTDIRECTED";
gfc_charlen_type iotype_len = 12;
char tmp_iomsg[IOMSG_LEN] = "";
char *child_iomsg;
gfc_charlen_type child_iomsg_len;
- int noiostat;
- int *child_iostat = NULL;
+ GFC_INTEGER_4 noiostat;
+ GFC_INTEGER_4 *child_iostat = NULL;
gfc_full_array_i4 vlist;
GFC_DESCRIPTOR_DATA(&vlist) = NULL;
@@ -2204,8 +2204,8 @@ list_formatted_read_scalar (st_parameter
/* Set iostat, intent(out). */
noiostat = 0;
- child_iostat = (dtp->common.flags & IOPARM_HAS_IOSTAT) ?
- dtp->common.iostat : &noiostat;
+ child_iostat = ((dtp->common.flags & IOPARM_HAS_IOSTAT)
+ ? dtp->common.iostat : &noiostat);
/* Set iomsge, intent(inout). */
if (dtp->common.flags & IOPARM_HAS_IOMSG)
@@ -2987,14 +2987,14 @@ nml_read_obj (st_parameter_dt *dtp, name
/* If this object has a User Defined procedure, call it. */
if (nl->dtio_sub != NULL)
{
- int unit = dtp->u.p.current_unit->unit_number;
+ GFC_INTEGER_4 unit = dtp->u.p.current_unit->unit_number;
char iotype[] = "NAMELIST";
gfc_charlen_type iotype_len = 8;
char tmp_iomsg[IOMSG_LEN] = "";
char *child_iomsg;
gfc_charlen_type child_iomsg_len;
- int noiostat;
- int *child_iostat = NULL;
+ GFC_INTEGER_4 noiostat;
+ GFC_INTEGER_4 *child_iostat = NULL;
gfc_full_array_i4 vlist;
formatted_dtio dtio_ptr = (formatted_dtio)nl->dtio_sub;
@@ -3006,8 +3006,8 @@ nml_read_obj (st_parameter_dt *dtp, name
/* Set iostat, intent(out). */
noiostat = 0;
- child_iostat = (dtp->common.flags & IOPARM_HAS_IOSTAT) ?
- dtp->common.iostat : &noiostat;
+ child_iostat = ((dtp->common.flags & IOPARM_HAS_IOSTAT)
+ ? dtp->common.iostat : &noiostat);
/* Set iomsg, intent(inout). */
if (dtp->common.flags & IOPARM_HAS_IOMSG)
--- libgfortran/io/write.c.jj 2023-09-28 21:49:38.632795791 +0200
+++ libgfortran/io/write.c 2023-12-05 11:26:27.763627070 +0100
@@ -1952,14 +
Re: [PATCH] libgfortran: Fix -Wincompatible-pointer-types errors
On 05/12/2023 10:33, Jakub Jelinek wrote:
Hi!
On Tue, Dec 05, 2023 at 10:46:02AM +0100, Florian Weimer wrote:
Presumably the fixes will look like this?
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index db3330060ce..4fcc77dbf83 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -2987,13 +2987,13 @@ nml_read_obj (st_parameter_dt *dtp, namelist_info *nl,
index_type offset,
/* If this object has a User Defined procedure, call it. */
if (nl->dtio_sub != NULL)
{
- int unit = dtp->u.p.current_unit->unit_number;
+ GFC_INTEGER_4 unit = dtp->u.p.current_unit->unit_number;
char iotype[] = "NAMELIST";
gfc_charlen_type iotype_len = 8;
char tmp_iomsg[IOMSG_LEN] = "";
char *child_iomsg;
gfc_charlen_type child_iomsg_len;
- int noiostat;
+ GFC_INTEGER_4 noiostat;
int *child_iostat = NULL;
gfc_full_array_i4 vlist;
formatted_dtio dtio_ptr = (formatted_dtio)nl->dtio_sub;
That seems insufficient.
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, but long will generally be 8 on such targets.
R.
typedef GFC_INTEGER_4 GFC_LOGICAL_4;
#define HAVE_GFC_LOGICAL_4
#define HAVE_GFC_INTEGER_4
in the build dir to emulate what newlib aarch64 is doing:
2023-12-05 Florian Weimer
Jakub Jelinek
* io/list_read.c (list_formatted_read_scalar) :
Change types of unit and noiostat to GFC_INTEGER_4 from int, change
type of child_iostat from to GFC_INTEGER_4 * from int *, formatting
fixes.
(nml_read_obj): Likewise.
* io/write.c (list_formatted_write_scalar) : Likewise.
(nml_write_obj): Likewise.
* io/transfer.c (unformatted_read, unformatted_write): Likewise.
--- libgfortran/io/list_read.c.jj 2023-05-09 00:07:26.161168737 +0200
+++ libgfortran/io/list_read.c 2023-12-05 11:25:31.837426653 +0100
@@ -2189,14 +2189,14 @@ list_formatted_read_scalar (st_parameter
break;
case BT_CLASS:
{
- int unit = dtp->u.p.current_unit->unit_number;
+ GFC_INTEGER_4 unit = dtp->u.p.current_unit->unit_number;
char iotype[] = "LISTDIRECTED";
gfc_charlen_type iotype_len = 12;
char tmp_iomsg[IOMSG_LEN] = "";
char *child_iomsg;
gfc_charlen_type child_iomsg_len;
- int noiostat;
- int *child_iostat = NULL;
+ GFC_INTEGER_4 noiostat;
+ GFC_INTEGER_4 *child_iostat = NULL;
gfc_full_array_i4 vlist;
GFC_DESCRIPTOR_DATA(&vlist) = NULL;
@@ -2204,8 +2204,8 @@ list_formatted_read_scalar (st_parameter
/* Set iostat, intent(out). */
noiostat = 0;
- child_iostat = (dtp->common.flags & IOPARM_HAS_IOSTAT) ?
- dtp->common.iostat : &noiostat;
+ child_iostat = ((dtp->common.flags & IOPARM_HAS_IOSTAT)
+ ? dtp->common.iostat : &noiostat);
/* Set iomsge, intent(inout). */
if (dtp->common.flags & IOPARM_HAS_IOMSG)
@@ -2987,14 +2987,14 @@ nml_read_obj (st_parameter_dt *dtp, name
/* If this object has a User Defined procedure, call it. */
if (nl->dtio_sub != NULL)
{
- int unit = dtp->u.p.current_unit->unit_number;
+ GFC_INTEGER_4 unit = dtp->u.p.current_unit->unit_number;
char iotype[] = "NAMELIST";
gfc_charlen_type iotype_len = 8;
char tmp_iomsg[IOMSG_LEN] = "";
char *child_iomsg;
gfc_charlen_type child_iomsg_len;
- int noiostat;
- int *child_iostat = NULL;
+ GFC_INTEGER_4 noiostat;
+ GFC_INTEGER_4 *child_iostat = NULL;
gfc_full_array_i4 vlist;
formatted_dtio dtio_ptr = (formatted_dtio)nl->dtio_sub;
@@ -3006,8 +3006,8 @@ nml_read_obj (st_parameter_dt *dtp, name
/* Set iostat, intent(out). */
noiostat = 0;
- child_iostat = (dtp->common.flags & IOPARM_HAS_IOSTAT) ?
- dtp->common.iostat : &noiostat;
+ child_iostat = ((dtp->common.flags & IOPARM_HAS_IOSTAT)
+ ? dtp->common.iostat : &noiostat);
/* Set iomsg, intent(inout). */
if (dtp->common.flags & IOPARM_HAS_IOMSG)
Re: [PATCH] libgfortran: Fix -Wincompatible-pointer-types errors
On Tue, Dec 05, 2023 at 10:47:34AM +, 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. Jakub
Re: [PATCH] libgfortran: Fix -Wincompatible-pointer-types errors
On 05/12/2023 10:51, Jakub Jelinek wrote: On Tue, Dec 05, 2023 at 10:47:34AM +, 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. R. Jakub
Re: [PATCH] libgfortran: Fix -Wincompatible-pointer-types errors
On Tue, Dec 05, 2023 at 10:57:50AM +, Richard Earnshaw wrote: > On 05/12/2023 10:51, Jakub Jelinek wrote: > > On Tue, Dec 05, 2023 at 10:47:34AM +, 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
Re: [PATCH] libgfortran: Fix -Wincompatible-pointer-types errors
* Richard Earnshaw: > On 05/12/2023 10:51, Jakub Jelinek wrote: >> On Tue, Dec 05, 2023 at 10:47:34AM +, 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.h2023-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. I think it's not part of the submission, it was for local testing only. It confused me as well. 8-) Thanks, Florian
Re: [PATCH] libgfortran: Fix -Wincompatible-pointer-types errors
Hi all,
the patch submission looks confusing as the context is a bit unclear
(aarch64 having two integer types?) and the slightly unmotivated 'long'
change (as explained in later emails: used as trick to find all
locations that should be changed and not being part of actually proposed
patch).
However, once this has been disentangled, the patch LGTM, assuming and
being positive that no aarch64 maintainer sees a problem.
Tobias
On 05.12.23 11:33, Jakub Jelinek wrote:
On Tue, Dec 05, 2023 at 10:46:02AM +0100, Florian Weimer wrote:
Presumably the fixes will look like this?
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index db3330060ce..4fcc77dbf83 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -2987,13 +2987,13 @@ nml_read_obj (st_parameter_dt *dtp, namelist_info *nl,
index_type offset,
/* If this object has a User Defined procedure, call it. */
if (nl->dtio_sub != NULL)
{
-int unit = dtp->u.p.current_unit->unit_number;
+GFC_INTEGER_4 unit = dtp->u.p.current_unit->unit_number;
char iotype[] = "NAMELIST";
gfc_charlen_type iotype_len = 8;
char tmp_iomsg[IOMSG_LEN] = "";
char *child_iomsg;
gfc_charlen_type child_iomsg_len;
-int noiostat;
+GFC_INTEGER_4 noiostat;
int *child_iostat = NULL;
gfc_full_array_i4 vlist;
formatted_dtio dtio_ptr = (formatted_dtio)nl->dtio_sub;
That seems insufficient.
The following patch makes libgfortran build on i686-linux after hacking up
--- kinds.h.xx2023-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;
typedef GFC_INTEGER_4 GFC_LOGICAL_4;
#define HAVE_GFC_LOGICAL_4
#define HAVE_GFC_INTEGER_4
in the build dir to emulate what newlib aarch64 is doing:
2023-12-05 Florian Weimer
Jakub Jelinek
* io/list_read.c (list_formatted_read_scalar) :
Change types of unit and noiostat to GFC_INTEGER_4 from int, change
type of child_iostat from to GFC_INTEGER_4 * from int *, formatting
fixes.
(nml_read_obj): Likewise.
* io/write.c (list_formatted_write_scalar) : Likewise.
(nml_write_obj): Likewise.
* io/transfer.c (unformatted_read, unformatted_write): Likewise.
--- libgfortran/io/list_read.c.jj 2023-05-09 00:07:26.161168737 +0200
+++ libgfortran/io/list_read.c2023-12-05 11:25:31.837426653 +0100
@@ -2189,14 +2189,14 @@ list_formatted_read_scalar (st_parameter
break;
case BT_CLASS:
{
- int unit = dtp->u.p.current_unit->unit_number;
+ GFC_INTEGER_4 unit = dtp->u.p.current_unit->unit_number;
char iotype[] = "LISTDIRECTED";
gfc_charlen_type iotype_len = 12;
char tmp_iomsg[IOMSG_LEN] = "";
char *child_iomsg;
gfc_charlen_type child_iomsg_len;
- int noiostat;
- int *child_iostat = NULL;
+ GFC_INTEGER_4 noiostat;
+ GFC_INTEGER_4 *child_iostat = NULL;
gfc_full_array_i4 vlist;
GFC_DESCRIPTOR_DATA(&vlist) = NULL;
@@ -2204,8 +2204,8 @@ list_formatted_read_scalar (st_parameter
/* Set iostat, intent(out). */
noiostat = 0;
- child_iostat = (dtp->common.flags & IOPARM_HAS_IOSTAT) ?
- dtp->common.iostat : &noiostat;
+ child_iostat = ((dtp->common.flags & IOPARM_HAS_IOSTAT)
+ ? dtp->common.iostat : &noiostat);
/* Set iomsge, intent(inout). */
if (dtp->common.flags & IOPARM_HAS_IOMSG)
@@ -2987,14 +2987,14 @@ nml_read_obj (st_parameter_dt *dtp, name
/* If this object has a User Defined procedure, call it. */
if (nl->dtio_sub != NULL)
{
- int unit = dtp->u.p.current_unit->unit_number;
+ GFC_INTEGER_4 unit = dtp->u.p.current_unit->unit_number;
char iotype[] = "NAMELIST";
gfc_charlen_type iotype_len = 8;
char tmp_iomsg[IOMSG_LEN] = "";
char *child_iomsg;
gfc_charlen_type child_iomsg_len;
- int noiostat;
- int *child_iostat = NULL;
+ GFC_INTEGER_4 noiostat;
+ GFC_INTEGER_4 *child_iostat = NULL;
gfc_full_array_i4 vlist;
formatted_dtio dtio_ptr = (formatted_dtio)nl->dtio_sub;
@@ -3006,8 +3006,8 @@ nml_read_obj (st_parameter_dt *dtp, name
/* Set iostat, intent(out). */
noiostat = 0;
- child_iostat = (dtp->common.flags & IOPARM_HAS_IOSTAT) ?
- dtp->common.iostat : &noiostat;
+ child_iostat = ((dtp->common.flags & IOPARM_HAS_IOSTAT)
+
Re: [PATCH] libgfortran: Fix -Wincompatible-pointer-types errors
On 05/12/2023 10:59, Jakub Jelinek wrote: On Tue, Dec 05, 2023 at 10:57:50AM +, Richard Earnshaw wrote: On 05/12/2023 10:51, Jakub Jelinek wrote: On Tue, Dec 05, 2023 at 10:47:34AM +, 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.
