This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [gfortran] Fix RETURN matcher was: Re: bug fc110
Walt Brainerd wrote:
> Just for the record +1 is not a constant (another oddity of Fortran),
> so return+1 is also valid.
>
> Since the restriction is not a constraint, I don't think anybody would
> be upset if you allowed return1 also, if it makes it easier.
It would slightly, I suppose. If the rule I quoted is not a constraint, and
therefore doesn't enforce the space there, which rule does enforce that there
be a blank between REAL and FUNCTION and the function's name, for instance?
I'm always surprised how much there's to be learned about standards.
Oh, and this patch has so far went unreviewed.
- Tobi
>
> Tobias Schlüter wrote:
>
>
>>The return statement is special in that it is the only case where a keyword is
>>immediately followed by an expression. This means that in most cases a blank
>>is required after the RETURN keyword, but not always, according to 3.3.1 "A
>>blank shall be used to separate names, constants, or labels from adjacent
>>keywords, names, constants, or labels."
>>
>>I.e. the following is valid:
>>return(1)
>>the following is invalid
>>return1
>>and the following is indeterminate:
>>return+1
>>because it is invalid if +1 is a constant, but valid if +1 is an expression.
>>The latter seems to be more consistent, but I think it's really ugly. ifc
>>accept it, though, so I chose to support this as well. (g77 also accepts
>>this, but that is due to the wonders of fixed-form).
>>
>>While I was touching gfc_match_return I moved the warning about a RETURN found
>>in the main program to a place where we're actually sure that we're dealing
>>with a return statement, and not something like "return1 = 5". I also fixed
>>the parse tree dumper from segfaulting when it encounters an alternate return
>>in an arglist (did noone notice this before??)
>>
>>Bubblestrapped and regtested, ok?