This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
RFC: adding knowledge of the int_fastN_t types to the compiler
- From: FX Coudert <fxcoudert at gmail dot com>
- To: GCC Development <gcc at gcc dot gnu dot org>
- Cc: Fortran List <fortran at gcc dot gnu dot org>
- Date: Wed, 12 Mar 2008 15:55:00 +0000
- Subject: RFC: adding knowledge of the int_fastN_t types to the compiler
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:to:message-id:content-type:cc:subject:from:date:x-mailer; bh=7jIxlEPd9YeOWtG7FxdVLJbhK4xizR2FFRCreJV4K5o=; b=f2D1fzIOjbDBucS6936cRi9TG4MJM6KzImfD6Ow5oXrJz2+RjGkj9QJ5rRDwFYek7RqJqNpzpkVKswwzXJve4anxr5wzF4Chpc5q2RDUb6udLLyVB36Ar+HPiTInfTbgc9T0pZ/OaGP70AJwlC1BeQ+mCzVnV6ZwuAA4IPItoj8=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=mime-version:to:message-id:content-type:cc:subject:from:date:x-mailer; b=Gw3q+YZKd7hJcKJoP0fesLpkGaVTbfAPywe4aYU5WI0iowSnhG3I42c3UN863qpr6RtE8o0KEs6DL3WaE/pfLN8xh8sfqE3UcJoe6YxZKDcEmQcDmvIu5noYqShkh41OzL0RNIJijRt84GtsgFJKcavCXxA7t3aRItXqEZohCRY=
Hi all,
The Fortran 2003 standard requires that Fortran compilers be able to
know, at compile-time, what size the various int_fastN_t types have
on the target (for N = 8, 16, 32 and 64). I've discussed that issue
before on this list, and was told it's a known issue, tracked as PR
448. For 4.3, we ignored the issue; for 4.4, I'd like to move forward
and propose some way to go. Here's the idea I've been following: it's
not excellent, but I don't think there are many alternatives available!
I propose we implement target macros INT_FAST8_TYPE_SIZE (and so on
for 16, 32 and 64): they would be defined to -1 in defaults.h
(meaning that int_fastN_t types are not available), and independent
targets can redefine them. Front-ends and the middle-end can then use
it if they feel like it. Attached is a patch implementing this idea,
including target definitions for linux, darwin, mingw, AIX, IRIX,
OpenBSD, Solaris 2.10.
Comments on that first draft are welcome. I know it's a hard issue
and most possible fixes are more hacks than fixes, but the starting
point is that we really need it to work, and a system that covers 99%
of cases is better than nothing.
Thanks,
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
Attachment:
intfast-1.diff
Description: Binary data