1. 27 Jul, 2018 1 commit
  2. 13 Jul, 2018 1 commit
  3. 02 Jul, 2018 1 commit
  4. 22 Jun, 2018 1 commit
  5. 21 Jun, 2018 1 commit
  6. 13 Jun, 2018 1 commit
  7. 11 Jun, 2018 1 commit
  8. 06 Jun, 2018 1 commit
  9. 05 Jun, 2018 1 commit
  10. 31 May, 2018 1 commit
  11. 30 May, 2018 2 commits
    • cmd/go, cmd/vet: make vet work with gccgo · bb3976df
          
          Backport https://golang.org/cl/113715 and https://golang.org/cl/113716:
          
          cmd/go: don't pass -compiler flag to vet
          
          Without this running go vet -compiler=gccgo causes vet to fail.
          The vet tool does need to know the compiler, but it is passed in
          vetConfig.Compiler.
          
          cmd/go, cmd/vet, go/internal/gccgoimport: make vet work with gccgo
          
          When using gccgo/GoLLVM, there is no package file for a standard
          library package. Since it is impossible for the go tool to rebuild the
          package, and since the package file exists only in the form of a .gox
          file, this seems like the best choice. Unfortunately it was confusing
          vet, which wanted to see a real file. This caused vet to report errors
          about missing package files for standard library packages. The
          gccgoimporter knows how to correctly handle this case. Fix this by
          
          1) telling vet which packages are standard;
          2) letting vet skip those packages;
          3) letting the gccgoimporter handle this case.
          
          As a separate required fix, gccgo/GoLLVM has no runtime/cgo package,
          so don't try to depend on it (as it happens, this fixes golang/go#25324).
          
          The result is that the cmd/go vet tests pass when using -compiler=gccgo.
          
          Reviewed-on: https://go-review.googlesource.com/114516
      
      From-SVN: r260913
      Ian Lance Taylor committed
  12. 09 May, 2018 1 commit
  13. 04 May, 2018 4 commits
  14. 03 May, 2018 1 commit
  15. 02 May, 2018 2 commits
  16. 01 May, 2018 1 commit
  17. 27 Apr, 2018 1 commit
  18. 17 Apr, 2018 2 commits
  19. 26 Mar, 2018 1 commit
  20. 15 Mar, 2018 1 commit
  21. 07 Mar, 2018 1 commit
  22. 28 Feb, 2018 2 commits
  23. 22 Feb, 2018 1 commit
  24. 20 Feb, 2018 1 commit
  25. 16 Feb, 2018 1 commit
  26. 12 Feb, 2018 2 commits
    • compiler: error on func declaration/definition · 52eb4ab4
          
          Long long long ago Go permitted writing
              func F()
          in one file and writing
              func F() {}
          in another file.  This was removed from the language, and that is now
          considered to be a multiple definition error.  Gccgo never caught up
          to that, and it has been permitting this invalid code for some time.
          
          Stop permitting it, so that we give correct errors.  Since we've
          supported it for a long time, the compiler uses it in a couple of
          cases: it predeclares the hash/equal methods if it decides to create
          them while compiling another function, and it predeclares main.main as
          a mechanism for getting the right warning if a program uses the wrong
          signature for main.  For simplicity, keep those existing uses.
          
          This required a few minor changes in libgo which were relying,
          unnecessarily, on the current behavior.
          
          Reviewed-on: https://go-review.googlesource.com/93083
      
      From-SVN: r257600
      Ian Lance Taylor committed
    • re PR go/84215 (Random results in go/libgo tests) · 86ff1853
      	PR go/84215
          runtime, sync/atomic: use write barrier for atomic pointer functions
          
          This copies atomic_pointer.go from 1.10rc2.  It was omitted during the
          transition of the runtime from C to Go, and I forgot about it.
          
          This may help with https://gcc.gnu.org/PR84215.
          
          Reviewed-on: https://go-review.googlesource.com/93197
      
      From-SVN: r257599
      Ian Lance Taylor committed
  27. 08 Feb, 2018 2 commits
  28. 07 Feb, 2018 1 commit
    • runtime: don't call funcPC from a function · f1a2d8b1
          
          The escape analysis support is not yet good enough to avoid escaping
          the argument to funcPC.  This causes unnecessary and often harmful
          memory allocation.  E.g., (*cpuProfile).addExtra can be called from a
          signal handler, and it must not allocate memory.
          
          Move the calls to funcPC to use variables instead.  This was done in
          the original migration to using funcPC, but was not done for newer code.
          
          In one case, in signal handling code, use getSigtramp.
          
          Reviewed-on: https://go-review.googlesource.com/92735
      
      From-SVN: r257463
      Ian Lance Taylor committed
  29. 06 Feb, 2018 1 commit
  30. 05 Feb, 2018 1 commit
  31. 02 Feb, 2018 1 commit