------- Comment #7 from jb at gcc dot gnu dot org 2007-05-22 06:52 -------
(In reply to comment #6)
> The following simplistic patch solves this problem. Sometimes I think we get
> overzealous with definitions and fancy configury. We all know the size is 10
> bytes and 12 works.
No. The non-padded size is always 10, yes, but the amount of padding varies. On
x86 the total size is 12 bytes and on x86-64 it's 16 bytes. That's just how the
ABI defines the types, there's nothing we can do about it.
> Index: size_from_kind.c
> ===================================================================
> --- size_from_kind.c (revision 124927)
> +++ size_from_kind.c (working copy)
> @@ -50,7 +50,7 @@ size_from_real_kind (int kind)
> #endif
> #ifdef HAVE_GFC_REAL_10
> case 10:
> - return sizeof (GFC_REAL_10);
> + return (sizeof (GFC_REAL_4) + sizeof (GFC_REAL_8));
> #endif
It's identical on x86, but on x86-64 it returns the wrong size.
> #ifdef HAVE_GFC_REAL_16
> case 16:
>
> In the file mk-kinds-h.sh we have the following snippet:
>
> 4) ctype="float" ;;
> 8) ctype="double" ;;
> 10) ctype="long double" ;;
> 16) ctype="long double" ;;
> *) echo "$0: Unknown type" >&2 ; exit 1 ;;
>
> All fine and dandy, except in the library we don't want a ctype, we want the
> size of a real kind=10 (which I think really ought to be 10, not 12)
No. It's 12 or 16, depending on the platform. Again, the ABI specifies this, we
can't change it.
> I don't think there is an equivalent ctype. At least not for writing bytes to
> a file.
That's right, when writing to files we can in principle do whatever we want.
The size deals with the in-memory representation. In practice, it's easier and
faster to have the on-disk representation be identical to the in-memory
representation.
> I am not sure why we don't just do this:
>
> size_from_real_kind (int kind)
> {
> return kind;
> }
>
> It would probably work. Which implies maybe we could do without this function
> altogether. Isn't the implementation of kind up to the compiler and it could
> equal kind if we so choose? (with respect to unformatted I/O, why write more
> bytes than needed?)
It's needed for array I/O. If the on-disk representation agrees with the
in-memory representation, we can just do a single read/write for an entire
array (provided it's contiguous etc.), whereas if the on-disk representation
doesn't include the padding we would need to do array I/O element-by-element
which is much slower.
In general, the reason we need both the kind and the size (which are different
if the type includes padding like real(10)) is that formatted I/O works with
kind and unformatted with size. Also, for formatted array I/O we need the size
as well to know how much to step forward for each element in the array.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31933
