This is the mail archive of the
mailing list for the GCC project.
Re: [gfortran] Support INTEGER<->LOGICAL conversion (take 3)
- From: Roger Sayle <roger at eyesopen dot com>
- To: Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>
- Cc: Paul Brook <paul at codesourcery dot com>, <fortran at gcc dot gnu dot org>, <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 29 May 2005 08:22:28 -0600 (MDT)
- Subject: Re: [gfortran] Support INTEGER<->LOGICAL conversion (take 3)
On Sun, 29 May 2005, [ISO-8859-1] Tobias Schlüter wrote:
> Roger Sayle wrote:
> > To address Tobias' concerns about possible adverse interactions with
> > fortran's arithmetic if I've double checked that there's run-time
> > testing of this construct in gfortran.fortran-torture/arithmeticif.f90
> > and gfortran.dg/pr17229.f, and that both of these tests continue to
> > pass with this patch.
> I'm sorry that I didn't think of this yesterday and only focused on arithmetic
> if, but there are more possible interactions with the IF statement. Is this
> extension intended to support something like
> integer i
> if (i) then
> end if
> logical l
> if (l) 100, 200, 300 ! label 100 is never jumped to
> This won't work with the patch, as the matcher for IF expects a logical /
> integer expression and rejects the code otherwise, whereas the implicit
> conversions are inserted during resolution, i.e. much later in the process.
Not by design. My selfish and far less ambitious goal was purely
to support assignment of .TRUE. and .FALSE. to integer types for
the time being. Yesterday on IRC, StevenB mentioned an impressively
long list of commerical compilers that supported logical <-> integer
conversions, but I've no idea if any (or how many) of them support
the two cases, you list above. However, doing the experiment with
"g77 -fugly-logint" I see that g77 does support both of the above
In that case, I should probably change the wording to indicate that
gfortran has "some support for" or "partial support for" implicit
conversion between logical and integer types to handle legacy codes?
If another of the gfortran contributors is motivated enough to add
the missing support (a regression from g77), I'd say go for it. My
modest patch simply hooked into the existing gfortran implicit conversion
machinery and therefore avoided many potential difficult semantic
interactions associated with tweaking the grammar/parser.
I hope this answer is satisfactory. I'm happy to come back to this
issue at some point in the future, if nobody beats me to it.