-
Notifications
You must be signed in to change notification settings - Fork 17.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gccgo: does not see stupidness of shift count #11524
Comments
Not sure why gccgo must reject this. |
I agree with rsc: the language spec does not require us to reject this program. I think gccgo is fine. |
First, such differences will make porting of large code based between compilers hard (this will actually have to be explicit porting process like in C++). Second, if it is a worthwhile diagnostic then both compilers should do it, otherwise no compiler should bother user. |
If gccgo does reject this program, it isn't clear to me how many shifts would be allowed before it becomes a stupid shift. gc and go/types already disagree on this point, with go1.5 putting the limit on stupidness at 512 bits and go/types limiting it around 1024 bits. It's weird that if the expression was |
No real program is going to write this kind of code. So I reject the argument that this will complicate porting of large code bases between compilers. This is not, in my opinion, a worthwhile diagnostic. The gc compiler implements it to simplify its own internal handling of untyped constants. The only possible principled approach is for all compilers to implement the complete language described in the spec. The spec permits large shift counts. Therefore the compilers should too. But, again, no actual code is going to use this, so it doesn't matter that gc rejects it. I don't think there is anything to do here. |
I'd like to disagree with the opinion that, "No real program is going to write this kind of code." While writing tests on denormals for an fma function, I had to write: |
@cldorian I tend to agree. It would be nice to set the shift max to a value that permits the direct expression of the extremes of float64. It doesn't cost in the compiler. A tad over 1000 as limit should be ok. |
Both gc and go/types reject the following program, but gccgo accepts:
gccgo should reject it as well.
gcc version 6.0.0 2015070 (experimental) (GCC)
The text was updated successfully, but these errors were encountered: