This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Integer types used in libgfortran
- From: FX <fxcoudert at gmail dot com>
- To: fortran at gcc dot gnu dot org
- Date: Wed, 25 May 2005 13:38:41 +0200
- Subject: Integer types used in libgfortran
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=BLoM85rdKR0pg0bOOOvTaFqiKE5Y8u/LUkzdTwCbnzPMJGqeLbaiP8GHjh87Xy+SWjaUkD/l/XqIQuxSjT6KxyygY6/9mHpV6u3DAfYZ5qWuwVSheR1j/xuRaYLvk/Ag1fdPzwmkgEez3b+DCkkh/POhOabzYMsCEb3K9AbmrQk=
- Reply-to: FX <fxcoudert at gmail dot com>
I've recently been thinking again about PR 21647 and all the PR
related to -fdefault-integer-8. Lots of library function calls use
GFC_INTEGER_4 arguments (or GFC_INTEGER_4 fields in structures) and
the'yre not happy when being given GFC_INTEGER_8 arguments.
If I understand correctly, one way to solve this would be to switch
the entire library to using GFC_INTEGER_8, but then the same problem
could happen with codes using larger kinds of integer. So, my question
is the following: how could we define a new GFC_INTEGER_LARGER type as
the larger integer type available on a given architecture, and is
there any objection to use such a scheme in most of the library
functions calls?