Age | Commit message (Collapse) | Author | Files | Lines |
|
LLVM's code generator does not currently support split stacks for vararg
functions, so we disable split stacks for the only function that uses this
feature under Clang. This appears to be OK as long as:
- this function only calls non-inlined, internal-linkage (hence no dynamic
loader) functions compiled with split stacks (i.e. go_vprintf), which can
allocate more stack space as required;
- this function itself does not occupy more than BACKOFF bytes of stack space
(see libgcc/config/i386/morestack.S).
These conditions are currently known to be satisfied by Clang on x86-32 and
x86-64. Note that signal handlers receive slightly less stack space than they
would normally do if they happen to be called while this function is being
run. If this turns out to be a problem we could consider increasing BACKOFF.
From-SVN: r211037
|
|
This includes the use of __complex and __builtin_ functions where
unprefixed entities would suffice, and the use of a union for
bit-casting between types.
From-SVN: r211036
|
|
Result of runtime_write is ignored, causing
an unused-result result warning (error in my
case, with -Werror=unused-result).
From-SVN: r210987
|
|
From-SVN: r210192
|
|
From-SVN: r210189
|
|
The Go compiler may have different values for these than the C compiler.
From-SVN: r209967
|
|
PR go/60931
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.
From-SVN: r209777
|
|
A gccgo language extension allows a function to be declared multiple
times. Avoid the use of this extension by dedeplicating declarations
in mksyscall.awk.
From-SVN: r209508
|
|
The use of this syntax was eliminated upstream in Go 992248b2adc2,
but this particular use slipped through somehow.
From-SVN: r209506
|
|
Avoid the use of a gccgo language extension which allows unsafe.Sizeof
to accept a type by passing an expression of the relevant type.
From-SVN: r209503
|
|
From Rainer Orth.
From-SVN: r209448
|
|
user: Ian Lance Taylor <iant@golang.org>
date: Thu Apr 10 09:25:24 2014 -0700
files: go/expressions.cc
description:
compiler: add checks for constant overflow
Prevent extremely large constants from eating all of memory.
user: Chris Manghane <cmang@golang.org>
date: Mon Apr 07 16:57:09 2014 -0700
files: go/gogo-tree.cc go/gogo.cc go/gogo.h go/statements.cc
description:
compiler: Use backend interface for variable initialization.
user: Chris Manghane <cmang@golang.org>
date: Thu Apr 03 19:56:05 2014 -0700
files: go/backend.h go/gogo-tree.cc go/gogo.cc go/gogo.h
description:
compiler: Use backend interface to build function code.
changeset: 1269:6e30875d539e
user: Chris Manghane <cmang@golang.org>
date: Wed Apr 02 13:16:00 2014 -0700
files: go/backend.h go/gogo-tree.cc go/gogo.cc go/gogo.h
description:
compiler: Use backend interface for building function defer wrappers.
user: Chris Manghane <cmang@golang.org>
date: Mon Mar 31 12:42:49 2014 -0700
files: go/expressions.cc go/gogo-tree.cc go/gogo.cc go/gogo.h
description:
compiler: Use backend interface for memory allocation.
user: Chris Manghane <cmang@golang.org>
date: Thu Mar 27 14:22:49 2014 -0700
files: go/backend.h go/expressions.cc go/expressions.h
description:
compiler: Use backend interface for fixed array construction.
user: Chris Manghane <cmang@golang.org>
date: Mon Mar 17 21:25:04 2014 -0700
files: go/expressions.cc
description:
compiler: Check for loops in self-referential array types. Fixes issue 7525.
user: Chris Manghane <cmang@golang.org>
date: Mon Mar 17 14:31:59 2014 -0700
files: go/gogo.cc go/parse.cc
description:
compiler: Don't declare blank labels. Fixes issue 7539.
user: Chris Manghane <cmang@golang.org>
date: Mon Mar 17 13:12:32 2014 -0700
files: go/backend.h go/expressions.cc go/expressions.h go/runtime.def
description:
compiler: Use backend interface for call expressions.
user: Chris Manghane <cmang@golang.org>
date: Wed Mar 12 13:34:27 2014 -0700
files: go/expressions.cc go/expressions.h go/gogo-tree.cc go/statements.cc
description:
compiler: Use backend interface map construction.
user: Chris Manghane <cmang@golang.org>
date: Tue Mar 11 12:53:06 2014 -0700
files: go/backend.h go/expressions.cc go/gogo-tree.cc go/gogo.h
description:
compiler: Use backend interface for string expressions.
user: Chris Manghane <cmang@golang.org>
date: Sat Mar 08 15:56:59 2014 -0800
files: go/backend.h go/expressions.cc go/expressions.h
description:
compiler: Use backend interface for array and string indexing.
user: Chris Manghane <cmang@golang.org>
date: Fri Mar 07 16:02:18 2014 -0800
files: go/expressions.cc
description:
compiler: Use backend interface for constant expressions.
user: Chris Manghane <cmang@golang.org>
date: Thu Mar 06 16:00:18 2014 -0800
files: go/expressions.cc
description:
compiler: Use backend interface for struct construction.
user: Chris Manghane <cmang@golang.org>
date: Wed Mar 05 13:09:37 2014 -0800
files: go/expressions.cc
description:
compiler: Use backend interface for type conversions.
user: Chris Manghane <cmang@golang.org>
date: Tue Mar 04 07:03:47 2014 -0800
files: go/expressions.cc go/expressions.h go/gogo-tree.cc go/gogo.h go/runtime.def libgo/runtime/chan.c
description:
compiler: Use backend interface for channel receive.
user: Chris Manghane <cmang@golang.org>
date: Mon Mar 03 15:18:57 2014 -0800
files: go/backend.h go/expressions.cc go/runtime.def
description:
compiler: Use backend interface for builtin calls.
user: Chris Manghane <cmang@golang.org>
date: Mon Mar 03 07:44:35 2014 -0800
files: go/expressions.cc go/expressions.h go/types.cc go/types.h
description:
compiler: Use backend interface for string info.
user: Chris Manghane <cmang@golang.org>
date: Fri Feb 28 10:45:55 2014 -0800
files: go/expressions.cc go/expressions.h go/gogo-tree.cc go/statements.cc
description:
compiler: Use backend interface for map indexing.
user: Chris Manghane <cmang@golang.org>
date: Wed Feb 26 14:13:10 2014 -0800
files: go/expressions.cc go/expressions.h
description:
compiler: Use backend interface for slice value expressions.
user: Chris Manghane <cmang@golang.org>
date: Wed Feb 26 13:12:19 2014 -0800
files: go/backend.h go/expressions.cc go/expressions.h go/gogo-tree.cc go/runtime.def go/statements.cc
description:
compiler: Use backend interface for interface values.
user: Chris Manghane <cmang@golang.org>
date: Mon Feb 24 12:30:13 2014 -0800
files: go/expressions.cc go/expressions.h go/parse.cc go/statements.cc
description:
compiler: Change Heap_composite_expression to Heap_expression.
user: Chris Manghane <cmang@golang.org>
date: Thu Feb 20 19:47:06 2014 -0800
files: go/expressions.cc go/expressions.h go/gogo-tree.cc go/gogo.cc go/gogo.h go/types.cc go/types.h
description:
compiler: Use backend interface for interface method table expressions.
user: Chris Manghane <cmang@golang.org>
date: Mon Feb 03 14:36:20 2014 -0800
files: go/expressions.cc go/expressions.h
description:
compiler: Add compound expressions to the frontend.
* go-gcc.cc: Include "convert.h".
(Gcc_backend::string_constant_expression): New function.
(Gcc_backend::real_part_expression): Likewise.
(Gcc_backend::imag_part_expression): Likewise.
(Gcc_backend::complex_expression): Likewise.
(Gcc_backend::constructor_expression): Likewise.
(Gcc_backend::array_constructor_expression): Likewise.
(Gcc_backend::pointer_offset_expression): Likewise.
(Gcc_backend::array_index_expression): Likewise.
(Gcc_backend::call_expression): Likewise.
(Gcc_backend::exception_handler_statement): Likewise.
(Gcc_backend::function_defer_statement): Likewise.
(Gcc_backend::function_set_parameters): Likewise.
(Gcc_backend::function_set_body): Likewise.
(Gcc_backend::convert_expression): Handle various type
conversions.
From-SVN: r209393
|
|
http://golang.org/issue/7074 shows that not using
-ffp-contract=off produces the wrong result for math.Log2(1)
on arm64.
From-SVN: r208505
|
|
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.
From-SVN: r208390
|
|
From-SVN: r208286
|
|
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.
From-SVN: r207977
|
|
From Rainer Orth.
From-SVN: r207432
|
|
From-SVN: r206937
|
|
PR go/59866
runtime: Force work variable in mgc0 to be aligned on 8-byte boundary.
From-SVN: r206738
|
|
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.
From-SVN: r206501
|
|
PR go/59430
os/user: Use POSIX functions on Solaris.
From-SVN: r206412
|
|
PR go/59433
net: Don't use stack space for fd_sets when using select.
From-SVN: r206411
|
|
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/
From-SVN: r206374
|
|
From-SVN: r206353
|
|
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.
From-SVN: r206232
|
|
PR go/59506
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.
From-SVN: r206224
|
|
From-SVN: r206201
|
|
gcc/
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.
From-SVN: r206200
|
|
Don't free stack allocated defer block. Also ensure we have a
Go context in a few more places before freeing the block.
From-SVN: r205940
|
|
From-SVN: r205932
|
|
From-SVN: r205913
|
|
From-SVN: r205908
|
|
PR go/59408
runtime: Don't require g != m->g0 in sema notesleep.
From-SVN: r205756
|
|
From-SVN: r205652
|
|
From Richard Biener.
From-SVN: r205634
|
|
Avoids hanging inside older versions of glibc that do not
support recurive calls to dl_iterate_phdr.
From-SVN: r205561
|
|
From-SVN: r205555
|
|
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.
From-SVN: r205551
|
|
From-SVN: r205426
|
|
From-SVN: r205422
|
|
In particular this means that the names Getsockname returns are not
truncated to 26 characters.
Fixes issue 6829
https://codereview.appspot.com/31840043/
From-SVN: r205368
|
|
From-SVN: r205321
|
|
From Ulrich Weigand.
From-SVN: r205287
|
|
From-SVN: r205031
|
|
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
From-SVN: r205001
|
|
From-SVN: r205000
|
|
From-SVN: r204999
|
|
From-SVN: r204853
|
|
Fixes http://golang.org/issue/6715.
From-SVN: r204828
|
|
From-SVN: r204819
|