| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Fixes issue 38.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch@215831 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport https://codereview.appspot.com/132000043 to GCC 4.9 branch.
user: Michael Hudson-Doyle <michael.hudson@linaro.org>
This adds the minimal support for AArch64/arm64 relocations
needed to get cgo to work (when an isomorphic patch is applied
to gccgo) and a test.
This change uses the "AAarch64" name for the architecture rather
than the more widely accepted "arm64" because that's the name that
the relevant docs from ARM such as
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf
all use.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch@215492 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
| |
Without this we weren't supporting the standard Cloneflags
field of SysProcAttr.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch@214971 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch@214047 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Go frontend passes closures through to functions using the
functions __go_set_closure and __go_get_closure. The
expectation is that there are no function calls between
set_closure and get_closure. However, it turns out that there
can be function calls if some of the function arguments
require type conversion to an interface type. Converting to
an interface type can allocate memory, and that can in turn
trigger a garbage collection, and that can in turn call pool
cleanup functions that may call __go_set_closure. So the
called function can see the wrong closure value, which is bad.
This patch fixes the memory allocation function to preserve the
closure value across any possible garbage collection.
A test case is the libgo database/sql check run with the
environment variable GOGC set to 1.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch@213933 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
runtime: Ignore small argv[0] file for backtrace.
Reportedly in some cases Docker starts processes with argv[0]
pointing to an empty file. That would cause libgo to pass
that empty file to libbacktrace, which would then fail to do
any backtraces. Everything should work fine if libbacktrace
falls back to /proc/self/exe.
This patch to libgo works around the problem by ignoring
argv[0] if it is a small file, or if stat fails. This is not
a perfect fix but it's an unusual problem.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch@213512 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
|
| |
Result of runtime_write is ignored, causing
an unused-result result warning (error in my
case, with -Werror=unused-result).
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch@210986 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch@210191 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch@210188 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
runtime: Fix garbage collector issue with non 4kB system page size
The go garbage collector tracks memory in terms of 4kB pages.
Most of the code checks getpagesize() at runtime and does the
right thing.
On a 64kB ppc64 box I see SEGVs in long running processes
which has been diagnosed as a bug in scavengelist.
scavengelist does a madvise(MADV_DONTNEED) without rounding
the arguments to the system page size. A strace of one of the
failures shows the problem:
madvise(0xc211030000, 4096, MADV_DONTNEED) = 0
The kernel rounds the length up to 64kB and we mark 60kB of
valid data as no longer needed.
Round start up to a system page and end down before calling
madvise.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch@209776 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
|
| |
http://golang.org/issue/7074 shows that not using
-ffp-contract=off produces the wrong result for math.Log2(1)
on arm64.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@208505 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes a rare but serious bug. The Go garbage
collector only examines Go stacks. When Go code calls a
function that is not written in Go, it first calls
syscall.Entersyscall. Entersyscall records the position of
the Go stack pointer and saves a copy of all the registers.
If the garbage collector runs while the thread is executing
the non-Go code, the garbage collector fetches the stack
pointer and registers from the saved location.
Entersyscall saves the registers using the getcontext
function. Unfortunately I didn't consider the possibility
that Entersyscall might itself change a register before
calling getcontext. This only matters for callee-saved
registers, as caller-saved registers would be visible on the
saved stack. And it only matters if Entersyscall is compiled
to save and modify a callee-saved register before it calls
getcontext. And it only matters if a garbage collection
occurs while the non-Go code is executing. And it only
matters if the only copy of a valid Go pointer happens to be
in the callee-saved register when Entersyscall is called.
When all those conditions are true, the Go pointer might get
collected incorrectly, leading to memory corruption.
This patch tries to avoid the problem by splitting
Entersyscall into two functions. The first is a simple
function that just calls getcontext and then calls the rest of
Entersyscall. This should fix the problem, provided the
simple Entersyscall function does not itself modify any
callee-saved registers before calling getcontext. That seems
to be true on the systems I checked. But since the argument
to getcontext is an offset from a TLS variable, it won't be
true on a system which needs to save callee-saved registers in
order to get the address of a TLS variable. I don't know why
any system would work that way, but I don't know how to rule
it out. I think that on any such system this will have to be
implemented in assembler. I can't put the ucontext_t
structure on the stack, because this function can not split
stacks, and the ucontext_t structure is large enough that it
could cause a stack overflow.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@208390 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@208286 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
|
|
| |
Before this, the heap location used on a 64-bit system was not
available to user-space on arm64, so the "32-bit" strategy ended up
being used. So use somewhere that is available, and for bonus points
is far away from where the kernel allocates address space by default.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@207977 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
| |
From Rainer Orth.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@207432 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@206937 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
| |
runtime: Force work variable in mgc0 to be aligned on 8-byte boundary.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@206738 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The spans array is allocated in runtime_mallocinit. On a
32-bit system the number of entries in the spans array is
MaxArena32 / PageSize, which (2U << 30) / (1 << 12) == (1 << 19).
So we are allocating an array that can hold 19 bits for an
index that can hold 20 bits. According to the comment in the
function, this is intentional: we only allocate enough spans
(and bitmaps) for a 2G arena, because allocating more would
probably be wasteful.
But since the span index is simply the upper 20 bits of the
memory address, this scheme only works if memory addresses are
limited to the low 2G of memory. That would be OK if we were
careful to enforce it, but we're not. What we are careful to
enforce, in functions like runtime_MHeap_SysAlloc, is that we
always return addresses between the heap's arena_start and
arena_start + MaxArena32.
We generally get away with it because we start allocating just
after the program end, so we only run into trouble with
programs that allocate a lot of memory, enough to get past
address 0x80000000.
This changes the code that computes a span index to subtract
arena_start on 32-bit systems just as we currently do on
64-bit systems.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@206501 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
| |
os/user: Use POSIX functions on Solaris.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@206412 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
| |
net: Don't use stack space for fd_sets when using select.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@206411 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
|
|
|
|
| |
I am reliably informed that the architecture name and letter for the
plan9/inferno compilers for 64-bit ARM systems will be "arm64" and "7"
respectively, so let's get that bit in nice and early.
From Michael Hudson-Doyle.
https://codereview.appspot.com/34830045/
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@206374 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@206353 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Solaris, if you do a in-progress connect, and then the
server accepts and closes the socket, the client's later
attempt to complete the connect will fail with EINVAL. Handle
this case by assuming that the connect succeeded. This code
is weird enough that it is implemented as Solaris-only so that
it doesn't hide a real error on a different OS.
See http://golang.org/issue/6828.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@206232 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
net: use DialTimeout in TestSelfConnect
Backported from master repository.
This avoids problems with systems that take a long time to
find out nothing is listening, while still testing for the
self-connect misfeature since a self-connect should be fast.
With this we may be able to remove the test for non-Linux
systems.
Tested (on GNU/Linux) by editing selfConnect in
tcpsock_posix.go to always return false and verifying that
TestSelfConnect then fails with and without this change.
Idea from Uros Bizjak.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@206224 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@206201 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
2013-12-25 Allan Sandfeld Jensen <sandfeld@kde.org>
H.J. Lu <hongjiu.lu@intel.com>
PR target/59422
* config/i386/i386.c (get_builtin_code_for_version): Handle
PROCESSOR_HASWELL, PROCESSOR_SILVERMONT, PROCESSOR_BTVER1,
PROCESSOR_BTVER2, PROCESSOR_BDVER3 and PROCESSOR_BDVER4.
Change priority of PROCESSOR_BDVER1 to P_PROC_XOP.
(fold_builtin_cpu): Add "ivybridge", "haswell", "bonnell",
"silvermont", "bobcat" and "jaguar" CPU names. Add "sse4a",
"fma4", "xop" and "fma" ISA names.
libgcc/
2013-12-25 Allan Sandfeld Jensen <sandfeld@kde.org>
H.J. Lu <hongjiu.lu@intel.com>
PR target/59422
* config/i386/cpuinfo.c (enum processor_types): Add AMD_BOBCAT
and AMD_JAGUAR.
(enum processor_subtypes): Add AMDFAM15H_BDVER3, AMDFAM15H_BDVER4,
INTEL_COREI7_IVYBRIDGE and INTEL_COREI7_HASWELL.
(enum processor_features): Add FEATURE_SSE4_A, FEATURE_FMA4,
FEATURE_XOP and FEATURE_FMA.
(get_amd_cpu): Handle AMD_BOBCAT, AMD_JAGUAR, AMDFAM15H_BDVER2 and
AMDFAM15H_BDVER3.
(get_intel_cpu): Handle INTEL_COREI7 and INTEL_COREI7_HASWELL.
(get_available_features): Handle FEATURE_FMA, FEATURE_SSE4_A,
FEATURE_FMA4 and FEATURE_XOP.
testsuite/
2013-12-25 Allan Sandfeld Jensen <sandfeld@kde.org>
PR target/59422
* gcc.target/i386/funcspec-5.c (test_fma, test_xop, test_no_fma,
test_no_xop, test_arch_corei7, test_arch_corei7_avx,
test_arch_core_avx2, test_arch_bdver1, test_arch_bdver2,
test_arch_bdver3, test_tune_corei7, test_tune_corei7_avx,
test_tune_core_avx2, test_tune_bdver1, test_tune_bdver2 and
test_tune_bdver3): New function prototypes.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@206200 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
| |
Don't free stack allocated defer block. Also ensure we have a
Go context in a few more places before freeing the block.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205940 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205932 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205913 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205908 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
| |
runtime: Don't require g != m->g0 in sema notesleep.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205756 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205652 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
| |
From Richard Biener.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205634 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
| |
Avoids hanging inside older versions of glibc that do not
support recurive calls to dl_iterate_phdr.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205561 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205555 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
|
| |
When a 386 function returns a struct, it needs to return using
an rtd instruction that pops the hidden struct parameter off
the stack. That wasn't happening.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205551 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205426 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205422 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
|
|
|
|
| |
In particular this means that the names Getsockname returns are not
truncated to 26 characters.
Fixes issue 6829
https://codereview.appspot.com/31840043/
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205368 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205321 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
| |
From Ulrich Weigand.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205287 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205031 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes issue 6761
This simple change seems to work fine, slightly to my surprise.
This includes the tests I submitted to the main Go repository at
https://codereview.appspot.com/26570046
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205001 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205000 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@204999 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@204853 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
| |
Fixes http://golang.org/issue/6715.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@204828 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@204819 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
|
|
|
| |
Required for Solaris support.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@204817 138bc75d-0d04-0410-961f-82ee72b054a4
|
|
|
|
| |
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@204815 138bc75d-0d04-0410-961f-82ee72b054a4
|