[Bug fortran/51842] New: fortran fails if ssize_t is 32-bit on 64-bit host

[Bug fortran/51842] New: fortran fails if ssize_t is 32-bit on 64-bit host

[mrs at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842

             Bug #: 51842
           Summary: fortran fails if ssize_t is 32-bit on 64-bit host
    Classification: Unclassified
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: mrs@gcc.gnu.org


fortran fails if ssize_t is 32-bits on a 64-bit (LP64) host.  The runtime and
codegen disagree over the size of fields.  Either, the codegen should match the
runtime, or the runtime should match the codegen.

>From libgfortran.h:

/* The following two definitions must be consistent with the types used         
   by the compiler.  */
/* The type used of array indices, amongst other things.  */
typedef ssize_t index_type;

typedef struct descriptor_dimension
{
  index_type _stride;
  index_type _lbound;
  index_type _ubound;
}

descriptor_dimension;

#define GFC_ARRAY_DESCRIPTOR(r, type) \
struct {\
  type *data;\
  size_t offset;\
  index_type dtype;\
  descriptor_dimension dim[r];\
}

is but one example of a mismatch.  Better to use size_t, or ptrdiff_t
uniformly, if you want a 64-bit type on a 64-bit pointer host.

Tracking this problem down, was, very annoying.  I fixed my port to use a
64-bit type for ssize_t (bad port), so, I'm fine now.  For the next person, you
might want to assert that sizeof (size_t) == sizeof (ssize_t), so they can at
least find the problem faster if you don't `fix it'.

Thanks.

[Bug fortran/51842] fortran fails if ssize_t is 32-bit on 64-bit host

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-01-13 08:59:31 UTC ---
This was fixed for the 4.7 branch on 2011-04-12; on 4.7 index_type is a typedef
for ptrdiff_t.

[Bug fortran/51842] fortran fails if ssize_t is 32-bit on 64-bit host

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|FIXED                       |

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-13 09:27:51 UTC ---
(In reply to comment #0)
> /* The type used of array indices, amongst other things.  */
> typedef ssize_t index_type;

I just saw that GCC 4.7 uses now:

   typedef ptrdiff_t index_type;

Still, I wonder whether "intptr_t" would be even more correct.


Jerry and Mike: What do you think?


The change above was committed with the summary "Cleanup memsize types" by
Janne on 2011-04-12 as Rev. 172340.

http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c75dca4902ad96d90237f6ab49c368ecb1ff3e52

http://gcc.gnu.org/viewcvs?view=revision&revision=172340

 * * *

The following has been written before I saw the ptrdiff_t change. It still kind
of applies.

(In reply to comment #0)
> typedef ssize_t index_type;
>
> might want to assert that sizeof (size_t) == sizeof (ssize_t)

If I may nit pick myself: I have no idea why you talk about size_t; neither the
front end nor libgfortran uses "size_t" for array indices. In particular, I
think that the C99 standard allows size_of(void *) > sizeof(size_t), even if on
most systems those should be the same.


The front end currently uses an signed integer type of size POINTER_SIZE. That
usually matches sizeof(size_t), sizeof(ssize_t), sizeof(intptr_t), and
sizeof(ptrdiff_t). However, I think none of those *have to* match sizeof(void
*).


The question is how to solve this best. The front end uses:

  #include "tm.h" /* For POINTER_SIZE; cf. gcc/config/.  */

  /* Choose the integer kind the same size as "void*" for our index kind.  */
  gfc_index_integer_kind = POINTER_SIZE / 8;
  gfc_array_index_type = gfc_get_int_type (gfc_index_integer_kind);

(Side note: The FE assumes 8 == BITS_PER_UNIT, though in this case the same is
assumed in gfc_init_kinds - thus there should not be a real issue.)


Searching for suitable signed integer types, one finds:
- ssize_t    # sys/types.h, POSIX
- intprt_t   # stdint.h, optional type, C99
- ptrdiff_t  # stddef.h, C99


My impression is that "intptr_t" is the best: It is signed, it can store a
pointer without information loss, and it is C99. It's not perfect as it is
optional (though GCC should provide it) and as the standard allows it to be
larger than POINTER_SIZE.


Quotes from the standards:

intptr_t (from C99):
"The following type designates a signed integer type with the property that
 any valid pointer to void can be converted to this type, then converted back
 to pointer to void, and the result will compare equal to the original pointer:
 intptr_t
 [...] These types are optional."

I think most of the time, it has the right size - but the standard also allows
it to be larger ...


Again C99:
"ptrdiff_t
 which is the signed integer type of the result of subtracting two pointers;
 size_t
 which is the unsigned integer type of the result of the sizeof operator"

And again: While ptrdiff_t should on the most systems have the same size as
POINTER_SIZE, one may not always take the difference and thus it could be
(together with size_t) be smaller than POINTER_SIZE. On the other hand, there
is also no restriction on the maximal size - thus it could also be larger.


POSIX (IEEE Std 1003.1-2001):
"ssize_t  Used for a count of bytes or an error indication."
"* size_t shall be an unsigned integer type."
"* blksize_t, pid_t, and ssize_t shall be signed integer types."
"The type ssize_t shall be capable of storing values at least in the  range 
[-1, {SSIZE_MAX}]. [...] The  implementation shall support one or more
programming environments in which the widths of blksize_t, pid_t, size_t,
ssize_t, suseconds_t, and useconds_t are no greater than the width of type
long."

[Bug fortran/51842] fortran fails if ssize_t is 32-bit on 64-bit host

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-13 09:28:51 UTC ---
Sorry for the double commit - but I somehow midair collision didn't work as
expected.

[Bug fortran/51842] fortran fails if ssize_t is 32-bit on 64-bit host

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-13 09:27:16 UTC ---
(In reply to comment #0)
> /* The type used of array indices, amongst other things.  */
> typedef ssize_t index_type;

I just saw that GCC 4.7 uses now:

   typedef ptrdiff_t index_type;

Still, I wonder whether "intptr_t" would be even more correct.


Jerry and Mike: What do you think?


The change above was committed with the summary "Cleanup memsize types" by
Janne on 2011-04-12 as Rev. 172340.

http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c75dca4902ad96d90237f6ab49c368ecb1ff3e52

http://gcc.gnu.org/viewcvs?view=revision&revision=172340

 * * *

The following has been written before I saw the ptrdiff_t change. It still kind
of applies.

(In reply to comment #0)
> typedef ssize_t index_type;
>
> might want to assert that sizeof (size_t) == sizeof (ssize_t)

If I may nit pick myself: I have no idea why you talk about size_t; neither the
front end nor libgfortran uses "size_t" for array indices. In particular, I
think that the C99 standard allows size_of(void *) > sizeof(size_t), even if on
most systems those should be the same.


The front end currently uses an signed integer type of size POINTER_SIZE. That
usually matches sizeof(size_t), sizeof(ssize_t), sizeof(intptr_t), and
sizeof(ptrdiff_t). However, I think none of those *have to* match sizeof(void
*).


The question is how to solve this best. The front end uses:

  #include "tm.h" /* For POINTER_SIZE; cf. gcc/config/.  */

  /* Choose the integer kind the same size as "void*" for our index kind.  */
  gfc_index_integer_kind = POINTER_SIZE / 8;
  gfc_array_index_type = gfc_get_int_type (gfc_index_integer_kind);

(Side note: The FE assumes 8 == BITS_PER_UNIT, though in this case the same is
assumed in gfc_init_kinds - thus there should not be a real issue.)


Searching for suitable signed integer types, one finds:
- ssize_t    # sys/types.h, POSIX
- intprt_t   # stdint.h, optional type, C99
- ptrdiff_t  # stddef.h, C99


My impression is that "intptr_t" is the best: It is signed, it can store a
pointer without information loss, and it is C99. It's not perfect as it is
optional (though GCC should provide it) and as the standard allows it to be
larger than POINTER_SIZE.


Quotes from the standards:

intptr_t (from C99):
"The following type designates a signed integer type with the property that
 any valid pointer to void can be converted to this type, then converted back
 to pointer to void, and the result will compare equal to the original pointer:
 intptr_t
 [...] These types are optional."

I think most of the time, it has the right size - but the standard also allows
it to be larger ...


Again C99:
"ptrdiff_t
 which is the signed integer type of the result of subtracting two pointers;
 size_t
 which is the unsigned integer type of the result of the sizeof operator"

And again: While ptrdiff_t should on the most systems have the same size as
POINTER_SIZE, one may not always take the difference and thus it could be
(together with size_t) be smaller than POINTER_SIZE. On the other hand, there
is also no restriction on the maximal size - thus it could also be larger.


POSIX (IEEE Std 1003.1-2001):
"ssize_t  Used for a count of bytes or an error indication."
"* size_t shall be an unsigned integer type."
"* blksize_t, pid_t, and ssize_t shall be signed integer types."
"The type ssize_t shall be capable of storing values at least in the  range 
[-1, {SSIZE_MAX}]. [...] The  implementation shall support one or more
programming environments in which the widths of blksize_t, pid_t, size_t,
ssize_t, suseconds_t, and useconds_t are no greater than the width of type
long."

[Bug fortran/51842] fortran fails if ssize_t is 32-bit on 64-bit host

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842

--- Comment #5 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-01-13 10:19:02 UTC ---
(In reply to comment #3)
> (In reply to comment #0)
> > /* The type used of array indices, amongst other things.  */
> > typedef ssize_t index_type;
> 
> I just saw that GCC 4.7 uses now:
> 
>    typedef ptrdiff_t index_type;
> 
> Still, I wonder whether "intptr_t" would be even more correct.

Yes, and no. It is perhaps a better match for the current frontend logic of
choosing a type equal to the pointer size, but semantically ptrdiff_t is the
better choice for array indexing. 

So IMHO we should keep ptrdiff_t, and if GCC ever starts to support some kind
of architecture with segmented addressing or somesuch where !(sizeof(ptrdiff_t)
== sizeof(intptr_t) == sizeof(void*)), the frontend should be fixed to define
the indexing type in some other way. Perhaps basing it on the size_t type
(size_type_node) instead.

See also CFI_index_t in TS 29113, where the spec says something like "a type
capable of storing the result of subtracting two pointers", which is more or
less the same wording the C standard uses for ptrdiff_t.

> Searching for suitable signed integer types, one finds:
> - ssize_t    # sys/types.h, POSIX
> - intprt_t   # stdint.h, optional type, C99
> - ptrdiff_t  # stddef.h, C99

As a minor nit, ptrdiff_t is already a required type in C89.

> Quotes from the standards:

> Again C99:
> "ptrdiff_t
>  which is the signed integer type of the result of subtracting two pointers;
>  size_t
>  which is the unsigned integer type of the result of the sizeof operator"
> 
> And again: While ptrdiff_t should on the most systems have the same size as
> POINTER_SIZE, one may not always take the difference and thus it could be
> (together with size_t) be smaller than POINTER_SIZE. On the other hand, there
> is also no restriction on the maximal size - thus it could also be larger.

The logic AFAICT is that pointer differences are only valid if both pointers
point to the same memory object. But that is sufficient for us, since the array
data is in gfortran always a single memory object (though the Fortran standard
doesn't require this for POINTER arrays). Or does co-arrays change this?

(An additional quirk is that as ptrdiff_t is signed, it may not be able to
represent all valid pointer differences. The C standard seems to sweep this
issue under the rug. But using intptr_t doesn't solve this issue either, FWIW.)

[Bug fortran/51842] fortran fails if ssize_t is 32-bit on 64-bit host

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-13 10:34:01 UTC ---
(In reply to comment #5)
> Yes, and no. It is perhaps a better match for the current frontend logic of
> choosing a type equal to the pointer size, but semantically ptrdiff_t is the
> better choice for array indexing. 

OK. But then the logical step is to change the FE - how about something like
the following?

--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -576,10 +576,7 @@ gfc_init_kinds (void)
   gfc_default_character_kind = gfc_character_kinds[0].kind;
   gfc_character_storage_size = gfc_default_character_kind * 8;

-  /* Choose the integer kind the same size as "void*" for our index kind.  */
-  gfc_index_integer_kind = POINTER_SIZE / 8;
-  /* Pick a kind the same size as the C "int" type.  */
-  gfc_c_int_kind = INT_TYPE_SIZE / 8;
+  gfc_index_integer_kind = get_int_kind_from_name (PTRDIFF_TYPE);

   /* Choose atomic kinds to match C's int.  */
   gfc_atomic_int_kind = gfc_c_int_kind;

[Bug fortran/51842] fortran fails if ssize_t is 32-bit on 64-bit host

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842

--- Comment #7 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-01-13 11:44:05 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > Yes, and no. It is perhaps a better match for the current frontend logic of
> > choosing a type equal to the pointer size, but semantically ptrdiff_t is the
> > better choice for array indexing. 
> 
> OK. But then the logical step is to change the FE

Yes. I didn't do it as part of my patch back in April last year, because I
wasn't sure how to properly do it, and I didn't worry about supporting targets
where sizeof(void*) != sizeof(ptrdiff_t).

> - how about something like
> the following?
> 
> --- a/gcc/fortran/trans-types.c
> +++ b/gcc/fortran/trans-types.c
> @@ -576,10 +576,7 @@ gfc_init_kinds (void)
>    gfc_default_character_kind = gfc_character_kinds[0].kind;
>    gfc_character_storage_size = gfc_default_character_kind * 8;
> 
> -  /* Choose the integer kind the same size as "void*" for our index kind.  */
> -  gfc_index_integer_kind = POINTER_SIZE / 8;
> -  /* Pick a kind the same size as the C "int" type.  */
> -  gfc_c_int_kind = INT_TYPE_SIZE / 8;
> +  gfc_index_integer_kind = get_int_kind_from_name (PTRDIFF_TYPE);

(Well, you probably don't want to remove the assignment to gfc_c_int_kind.)

But otherwise, if this works, it looks ok. FWIW in c-family/c-common.c there is

ptrdiff_type_node
    = TREE_TYPE (identifier_global_value (get_identifier (PTRDIFF_TYPE)));

So if the above patch + our definition for the array index type node

gfc_array_index_type = gfc_get_int_type (gfc_index_integer_kind);

accomplishes the same thing, it looks Ok.

[Bug fortran/51842] fortran fails if ssize_t is 32-bit on 64-bit host

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-13 15:41:19 UTC ---
Author: burnus
Date: Fri Jan 13 15:41:13 2012
New Revision: 183154

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183154
Log:
2012-01-13  Tobias Burnus  <burnus@net-b.de>

        PR fortran/51842
        * fortran/trans-types.c (gfc_init_kinds): Use PTRDIFF_TYPE
        instead of a signed int of size POINTER_SIZE for
        gfc_index_integer_kind.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-types.c

[Bug fortran/51842] fortran fails if ssize_t is 32-bit on 64-bit host

[mrs at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842

--- Comment #9 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2012-01-13 17:23:37 UTC ---
The last fix looks perfect, thanks.

[Bug fortran/51842] fortran fails if ssize_t is 32-bit on 64-bit host

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #10 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-01-13 19:47:24 UTC ---
Closing again.