This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 are
"data-stmt-constants",...
Thus, while
INTEGER J = -2147493648
is not permitted,
INTEGER J
DATA J / -2147493648 /
is permitted. (Note that 4.3.1.1, line 25, explicitly states that "Any
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 4.3.1.1 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]