Skip to content

R
riscv-gcc-1
Switch branch/tag
  1. 14 Jul, 2017 2 commits
  3. 13 Jul, 2017 1 commit
  5. 29 Jun, 2017 2 commits
  7. 27 Jun, 2017 3 commits
  9. 26 Jun, 2017 2 commits
  11. 23 Jun, 2017 6 commits
    • runtime: complete defer handling in CgocallBackDone · f1857c63 
          
    When C code calls a Go function, it actually calls a function
    generated by cgo. That function is written in Go, and, among other
    things, it calls the real Go function like this:
            CgocallBack()
            defer CgocallBackDone()
            RealGoFunction()
    The deferred CgocallBackDone function enters syscall mode as we return
    to C. Typically the C function will then eventually return to Go.
    
    However, in the case where the C function is running on a thread
    created in C, it will not return to Go. For that case we will have
    allocated an m struct, with an associated g struct, for the duration
    of the Go code, and when the Go is complete we will return the m and g
    to a free list.
    
    That all works, but we are running in a deferred function, which means
    that we have been invoked by deferreturn, and deferreturn expects to
    do a bit of cleanup to record that the defer has been completed. Doing
    that cleanup while using an m and g that have already been returned to
    the free list is clearly a bad idea. It was kind of working because
    deferreturn was holding the g pointer in a local variable, but there
    were races with some other thread picking up and using the newly freed g.
    It was also kind of working because of a special check in freedefer;
    that check is no longer necessary.
    
    This patch changes the special case of releasing the m and g to do the
    defer cleanup in CgocallBackDone itself.
    
    This patch also checks for the special case of a panic through
    CgocallBackDone. In that special case, we don't want to release the m
    and g. Since we are returning to C code that was not called by Go
    code, we know that the panic is not going to be caught and we are
    going to exit the program. So for that special case we keep the m and
    g structs so that the rest of the panic code can use them.
    
    Reviewed-on: https://go-review.googlesource.com/46530

From-SVN: r249611
      Ian Lance Taylor committed
    • cmd/go: don't require GOROOT to exist for gccgo · 0f0d0eaa 
          
    Reviewed-on: https://go-review.googlesource.com/46590

From-SVN: r249609
      Ian Lance Taylor committed
    • os: align siginfo argument to waitid · 3c76bd92 
          
    Backport https://golang.org/cl/46511 from gc trunk, as it may fix a
    bug reported for gccgo running on MIPS
    (https://groups.google.com/d/msg/golang-dev/sDg-t1_DPw0/-AJmLxgPBQAJ).
    
    Reviewed-on: https://go-review.googlesource.com/46571

From-SVN: r249599
      Ian Lance Taylor committed
    • runtime: don't crash if no p in kickoff · bb96aa67 
          
    The kickoff function for g0 can be invoked without a p, for example
    from mcall(exitsyscall0) in exitsyscall after exitsyscall has cleared
    the p field. The assignment gp.param = nil will invoke a write barrier.
    If gp.param is not already nil, this will require a p. Avoid the problem
    for a specific case that is known to be OK: when the value in gp.param
    is a *g.
    
    Reviewed-on: https://go-review.googlesource.com/46512

From-SVN: r249595
      Ian Lance Taylor committed
    • compiler: add go:notinheap magic comment · 5f0b897b 
          
    Implement go:notinheap as the gc compiler does. A type marked as
    go:notinheap may not live in the heap, and does not require a write
    barrier. Struct and array types that incorporate notinheap types are
    themselves notinheap. Allocating a value of a notinheap type on the
    heap is an error.
    
    This is not just an optimization. There is code where a write barrier
    may not occur that was getting a write barrier with gccgo but not gc,
    because the types in question were notinheap. The case I found was
    setting the mcache field in exitsyscallfast.
    
    Reviewed-on: https://go-review.googlesource.com/46490

From-SVN: r249594
      Ian Lance Taylor committed
    • runtime: improve handling of panic during deferred function · 54357b3b 
          
    When a panic occurs while processing a deferred function that
    recovered an earlier panic, we shouldn't report the recovered panic
    in the panic stack trace. Stop doing so by keeping track of the panic
    that triggered a defer, marking it as aborted if we see the defer again,
    and discarding aborted panics when a panic is recovered. This is what
    the gc runtime does.
    
    The test for this is TestRecursivePanic in runtime/crash_test.go.
    We don't run that test yet, but we will soon.
    
    Reviewed-on: https://go-review.googlesource.com/46461

From-SVN: r249590
      Ian Lance Taylor committed
  13. 22 Jun, 2017 15 commits
  15. 21 Jun, 2017 7 commits
  17. 14 Jun, 2017 2 commits
    • compiler: avoid crash on erroneous type · b901cf9d 
          
    If there is an error constructing the backend type, the GCC backend
    will report that the size is 1.  That will then cause construction of
    the ptrmask to crash.  Avoid that case by just generating an empty
    ptrmask.
    
    Noticed while compiling a broken package.  The policy I've been
    following is to not commit a test case for a compiler crash on invalid
    code, so no test case.
    
    Reviewed-on: https://go-review.googlesource.com/45775

From-SVN: r249208
      Ian Lance Taylor committed
    • cmd/cgo: make _cgo_flags consistent across runs · ea9a08f5 
          
    The go tool will pass -I objdir as one of the flags, where objdir is
    the temporary build directory. Remove that from _cgo_flags: we don't
    need it, and it will be different each time.
    
    Sort the flags to avoid the unpredictable map iteration order.
    
    This matters for gccgo because for a package that uses cgo, the go
    tool when building for gccgo will store the _cgo_flags file in the
    archive. That means that we want to generate identical _cgo_flags for
    every run.
    
    The test for this is the cmd/go testsuite, to follow in a future CL.
    
    Reviewed-on: https://go-review.googlesource.com/45692

From-SVN: r249199
      Ian Lance Taylor committed