-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: doesn't seem to execute statement enclosed within a return statement #8698
Labels
Comments
Can you show a complete program that demonstrates this problem? My simple test cases work fine. Labels changed: added repo-gccgo. Owner changed to @ianlancetaylor. |
Comment 3 by ipoddar@us.ibm.com: I am attaching a piece of code which fails to produce the desired output when invoked with the following parameters: ./command-line-flags -A Indrajit -B Poddar Desired Output: OptionA: Indrajit OptionB: Poddar Received Output: OptionA: OptionB: If you uncomment lines 23 and 24 and comment line 25 and run go build command-line-flags.go then the Desired Output is Received. Attachments:
|
In preferred playground form: http://play.golang.org/p/qb9-vio7Ly But this is working as intended. options is a value type here, and the return statement, return opts, flagSet.Parse(args[1:]) is executed left to right. So first you assign opts to your first parameter. And then you populate your local variable "opts" and return the error from flagSet.Parse, but throw away its side effects. Status changed to WorkingAsIntended. |
Comment 5 by ipoddar@us.ibm.com: I am not satisfied with your answer. I see that this error does not happen on x86, only on ppc64le. I could not exercise my program in the play.golang.org link, because I don't see any way to provide input parameters. |
The statement in your function is return opts, flagSet.Parse(args[1:]) The function call flagSet.Parse(args[1:]) changes the value of opts. So the result of the return statement depends on the order in which Go evaluates "opts" and "flagSet.Parse(args[1:])". I assume we can agree on that. You now seem to be asserting that it is a bug that the program behaves differently on x86 and ppc64le. However, for better or for worse, the order of evaluation in Go is not fully defined: see http://golang.org/ref/spec#Order_of_evaluation . In particular, the order of evaluation of a variable reference is not defined with respect to a function call. So the compiler is free to make different choices on different targets. And it does. This is not a bug. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by ipoddar@us.ibm.com:
The text was updated successfully, but these errors were encountered: