I'm pretty sure that the existing conservative GC in cgo doesn't even scan the C part of the heap, so if you try to use unanchored pointers to Go objects, you will crash. More details here, in the comments: https://code.google.com/p/go/source/browse/misc/cgo/gmp/gmp....
I'm not sure how gccgo does it. There may be some limitations there based on the gcc internals, but I don't see why that would prevent cgo from developing a precise collector.
It wasn't obvious to me looking at the source of te actual GC implementatiob whether it avoids the C stack frames between Go frames. If it does then they don't have much to worry about.
I'm not sure about stack frames, but I do remember a lot of discussion about golang using a single contiguous area of virtual memory for its heap. Since C wouldn't be using that same address range, there would be no potential issues where someone would put a Go object on the C heap for a long time and have that result in implicit GC pinning. C stack frames may be an issue (I haven't checked either) but only for upcalls from C, which seem rare.
I'm not sure how gccgo does it. There may be some limitations there based on the gcc internals, but I don't see why that would prevent cgo from developing a precise collector.