This is the mail archive of the
mailing list for the GCC project.
Re: [gfortran] Support INTEGER<->LOGICAL conversion (take 3)
- From: Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Paul Brook <paul at codesourcery dot com>, fortran at gcc dot gnu dot org,gcc-patches at gcc dot gnu dot org
- Date: Mon, 30 May 2005 22:24:36 +0200
- Subject: Re: [gfortran] Support INTEGER<->LOGICAL conversion (take 3)
- References: <Pine.LNX.firstname.lastname@example.org>
Roger Sayle wrote:
>>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.
> Hi Tobi,
> 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.
g77's -fno-ugly-logint seems to make LOGICAL and INTEGER completely
interchangeable. I certainly won't ask you to implement that misfeature. If
ever somebody asks for something which goes beyond what you implemented we can
look at this again, but I do hope all those commercial compilers are mistaken
in their belief that there's a real need for this extension :-)