This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Adding knowledge of the int_fastN_t types to the compiler, take 2
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: FX <fxcoudert at gmail dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>, Fortran List <fortran at gcc dot gnu dot org>
- Date: Fri, 18 Apr 2008 18:30:25 +0000 (UTC)
- Subject: Re: Adding knowledge of the int_fastN_t types to the compiler, take 2
- References: <509B8F17-6F94-4523-8001-DFD7DD92FC15@gmail.com> <Pine.LNX.4.64.0803121814030.29332@digraph.polyomino.org.uk> <F6994478-04DA-4B79-A27C-7BEF56A12CDE@gmail.com>
On Fri, 18 Apr 2008, FX wrote:
> I've tried to take into account the remarks from Joseph and Ian, here's an
> updated patch. I welcome comments, ideas on how to best add testcases in the
> testsuite (for example, comparing Fortran information and C headers). After
> that, I will submit the complete patch + testcases + doc + ChangeLog entries
> for formal review.
Defining these types with preprocessor conditionals such as
+#elif LONG_TYPE_SIZE >= 8
is simply wrong. LONG_TYPE_SIZE is not a preprocessor constant. You need
to use conditional expressions with ? : instead to produce an expression
that evaluates when the compiler is run to different strings based on
compiler options. (If for a particular target LONG_TYPE_SIZE etc. are in
fact constants, of course this conditional expression will get
constant-folded.)
Also, I think the conclusion was that the compiler should not claim any
knowledge of these types unless specifically configured for a particular
target - that is, defaults.h should not contain any default definitions.
--
Joseph S. Myers
joseph@codesourcery.com