This is the mail archive of the
mailing list for the GCC project.
Re: Fix libgomp Fortran tests
On Sep 8, 2006, at 7:00 AM, Steve Kargl wrote:
On Thu, Sep 07, 2006 at 11:38:26PM -0700, Brooks Moses wrote:
Roger Sayle wrote:
Whilst I agree completely that prohibiting the constant -2147483648
adheres to the letter of the standards...
I'm curious how many other F90/F95 compilers (dis)allow -2147483648?
I couldn't give you a count, but I bet there are some that disallow
it. I avoid it in my personal coding style.
However, in a DATA statement, the values are not "constants", they
INTEGER J = -2147493648
is not permitted,
DATA J / -2147493648 /
is permitted. (Note that 126.96.36.199, line 25, explicitly states that
integer value may be represented as a signed-int-literal-constant.")
Can you open a PR? I did not realize that there was
this hair splitting. Oh, and this isn't going to be
easy to fix.
I think you are splitting the hair finer than the standard actually
does. Yes, signed-int-literal-constant is used in a data statement
(one of the very few places it is used), note that the definition of
signed-int-literal-constant is that it is an int-literal-constant
with an optional sign. Thus, if there is no such int-literal-
constant, then there can't be a signed version of it. So I think a
processor is allowed to disallow both of the above statements (and I
think some processors do).
I also think that the cited line 25 of 188.8.131.52 is not "strong" enough
to lean on here. In particular, note that the model in the Fortran
standard is pretty much a sign-magnitude one. That certainly doesn't
have to be the actual implementation (and seldom, if ever, is), but
that's the way Fortran models it. One has to match the implementation
model to Fortran's model. One way to match this particular case would
be to say that the model values are symmetric, but that there are
representable values that are not model values (namely the negative
value mentioned above). Or some such weasel words. Another way to
weasel it would be to claim that the number in question is outside
the allowed range for integers and therefore makes the program non-
conforming. It happens that the compiler allows some cases of this
nonconformance, but that's ok (and the allowed cases are not things
that require diagnosis).
Anyway, I think it nice for compilers to allow this, but I don't
think that the standard strictly requires it. I've sure used
compilers where it wouldn't work. Make your own decision on whether
or not it is worth the effort. And if you do decide to allow it, I
don't think you are required to distinguish between the data
statement case and the expression one. In fact, I personally think
that it would be "nice" to allow it in both spots and I think the
standard allows (but does not require) you to so allow it.
I also happen to dislike the way that the standard puts this all
together. I think someone long ago got overly pedantic about making
parsing unambiguous in a way that I don't think it really has to be.
The result causes more problems than if the ambiguity were just
allowed and rules for resolving it were added. Namely, I'd have liked
to see -123 be parsable as either an integer constant or as a unary
operator and an integer constant, depending on context. I don't think
it would have been hard to write the rules to disambiguate so that it
is a constant in x=-123, but not in x=456-123. But that's not the way
the standard did it, so it's a bit off topic here.
Richard Maine | Good judgment comes from experience;
Richard.Maine@nasa.gov | experience comes from bad judgment.
| -- Mark Twain