cmd/go: when compiling with gccgo uses go tool's ReleaseTags, not gccgo's

[mwhudson]

What steps reproduce the problem?

1. Install a version of go (such as 1.3) and a version of gccgo that implements a
different version of the language (such as gccgo 4.9, which implements go 1.2)
2. Try to build a package that uses the go1.3 build tag to conditionally support go 1.3
features (for example, https://github.com/docker/docker/tree/master/pkg/pools )

What happened?

The go tool attempts to compile the file with the go1.3 built tag with gccgo, and this
fails.

What should have happened instead?

It should have compiled the file with the !go1.3 build tag instead.

Please provide any additional information below.

The cause for this is pretty clear: the go tool uses the ReleaseTags from the go/build
package of the standard library that the go tool was built against, which is not
necessarily the same as the one the compiler being invoked.  This could be fixed by
compiling a little program that prints out go/build.Default.ReleaseTags and using those
in the go tool

There are other places where go tool and gccgo compiler have different views of things,
but this is the one that is biting me today.

[ianlancetaylor]

Comment 1:

Labels changed: added repo-main, release-go1.5.

[mwhudson]

Comment 2:

Here is a fairly terrible patch (which is why it's in a pastebin and not a CL):
http://paste.ubuntu.com/8475820/ 
It seems to work.  Does this approach have any merit?  It would make using -compiler
gccgo to cross compile basically impossible, not sure what to do there (I mean, a
correct fix might be for gccgo to grow a "-dumpbuildcontextinfo" flag?)

[ianlancetaylor]

Comment 3:

Perhaps when the -compiler option is used the go tool should not use the default release
tags at all.  They can still be specified using the -tags option.

[mwhudson]

Comment 4:

That would be a lot cleaner, certainly.

[pcc]

Comment 5:

That would certainly be simpler for the implementation, but it puts a significant burden
on the user to keep track of which versions of Go the compiler supports, and supply the
correct set of tags at every invocation. I would also consider it to be a regression in
functionality; at least, at the moment, the set of release tags is roughly correct.
I would much prefer if the "go" tool obtained this information automatically from the
compiler. I propose that "go" request a set of compiler tags from "gccgo" toolchains by
executing "$GCCGO -dumpgotags" and reading the tags from stdout. For backwards
compatibility with existing versions of gccgo/llgo, the "go" tool's built-in set of
compiler tags would continue to be used if the exit status is non-zero.
https://golang.org/cl/167080043 implements this, and I will mail it after the
go1.4 release.

[pcc]

Comment 6:

https://golang.org/cl/148770043/ is another issue that came up as a result of
this version skew.

[rsc]

Why do gccgo and llgo insist on trying to use a gc-toolchain-compiled go command in the first place? If you are using those compilers you should be using a go command built by them, and then the release tags will be right. All the complexity here seems misguided.

[mwhudson]

Well indeed, that's become both clearer and easier over the last few months, so I think this issue can be closed.

[mdempsky]

If users should always use a "go" tool built by the corresponding compiler, does the -compiler flag have any use still?

[rsc]

I talked to @ianlancetaylor about this, and he pointed out that it is convenient for users to have one go command in their binary and be able to use the -compiler flag to flip between them for building their own code (the go command doesn't know anything about the gccgo standard library; this is only about $GOPATH).

Given that, I do believe that as long as we have the -compiler we might as well get the release tags right. Ian and I talked about having a $GCCGOTAGS, but on reflection I don't think that's quite right either. Can we give gccgo and llgo the same option that means "print the Go release tags to use" and then just ask them, at roughly the same time we consult $GCCGO?

This is actually close to what comment 2 suggested, but a built-in option seems much better than compiling and running a whole Go program.

[rsc]

Too late for Go 1.5.

[laboger]

There are other issues or missing function related to the use of the -compiler option on the go tool.

• information from 'go version' refers to the compiler used to build the go tool, not the compiler being used to build with, which is what you really care about
• trying to do cross compiles with the compiler option won't work
• allowing any go tool to be able to compile using any other existing go compiler, no matter how old would be difficult
• ..... I'm sure there are others

Seems like it would be better just to drop support for the -compiler option.

If that was done then copies of the go tools for alternate compilers could be provided with distinct names, something like go.gccgo and go.llgo so it was clear which ones were being used.

[bcmills]

Does #28221 help with this issue?
(Does/will the gccgo compiler support the -lang flag, and does the -lang flag affect release tags?)

[ianlancetaylor]

Release tags are handled by cmd/go. The -lang flag is passed by cmd/go to the compiler. So the -lang flag does not affect release tags.

The go directive in the go.mod file, which is what sets the -lang flag that is passed to cmd/compile, also does not affect release tags. The idea is that the developer of the module is choosing, generally implicitly, which language version to use to build the module's code. It would be weird to write the module to use newer release tags than the language version. So while we could have the go directive affect the release tags used to build the module, that doesn't seem clearly useful.

So, no, the -lang flag is not going to help with this issue. As the issue says, we need a way for the go tool to interrogate the compiler. And that has not been implemented.

Currently gccgo does not implement anything like the -lang flag, but it will need to do so. That is a separate issue.