https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114941
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582
--- Comment #6 from Ian Lance Taylor ---
There is no floating-point in the user code, but Go does have a runtime that
runs at the start of every program, and it is possible that that code uses some
floating-point operations. In particular by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582
--- Comment #3 from Ian Lance Taylor ---
*** Bug 114583 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114583
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582
--- Comment #4 from Ian Lance Taylor ---
*** Bug 114584 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114584
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582
--- Comment #2 from Ian Lance Taylor ---
*** Bug 114581 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114581
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582
--- Comment #1 from Ian Lance Taylor ---
The bug here, and also with PR 114581, is in unwinding from a signal call. A
simplified version of the code for this issue is:
func main() {
defer func() { recover() }()
f()
}
func f() { *p =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106813
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114875
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114581
--- Comment #1 from Ian Lance Taylor ---
The behavior is different under gdb because gdb resends the signal. The
program then sees it with an si_code field of SI_USER, which causes it to act
differently.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52357
--- Comment #8 from Ian Lance Taylor ---
This is a register allocator problem, not a Go problem. I've opened
https://gcc.gnu.org/PR114881. It's an updated version of
https://gcc.gnu.org/PR53125.
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
Target Milestone: ---
Created attachment 58059
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58059=edit
Test case
This is repeat of PR 53125, which was closed in 2012.
The attached test c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114500
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114454
--- Comment #1 from Ian Lance Taylor ---
I'm not sure what is going on here. The test as such does not require a UTF-8
LANG. That is, I can run the compiler and the test with LANG=C and everything
passes. In fact, that is exactly how the GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114453
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114463
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114201
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114201
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113668
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113530
--- Comment #5 from Ian Lance Taylor ---
Does the GCC 13 branch actually try to build libgo for arc-linux-gnu?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110029
--- Comment #4 from Ian Lance Taylor ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113447
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
--- Comment #12 from Ian Lance Taylor ---
libgo/runtime/runtime.h:
#if defined(__x86_64__) && defined(__linux__) && !defined(__CET__)
...
#else
#define __go_context_t ucontext_t
#define __go_getcontext(c) getcontext(c)
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
--- Comment #10 from Ian Lance Taylor ---
The makecontext/getcontext/setcontext functions are called by libgo on
GNU/Linux for all targets other than x86_64. It is not the case that they are
used only on *BSD systems.
The default gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
--- Comment #4 from Ian Lance Taylor ---
I understand that makecontext/getcontext/setcontext were removed from POSIX.
However, there is no adequate replacement. Their functionality is absolutely
required for what libgo does. Fortunately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
--- Comment #2 from Ian Lance Taylor ---
Note that except on x86_64 GNU/Linux, libgo requires the makecontext,
getcontext, and setcontext functions that are declared in ucontext.h. There is
no adequate replacement for those functions on strict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #37 from Ian Lance Taylor ---
Search for this comment in the top-level configure.ac file.
# Disable libgo for some systems where it is known to not work.
# For testing, you can easily override this with --enable-libgo.
That said if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112710
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112396
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
--- Comment #11 from Ian Lance Taylor ---
vincenzo: the patch in the linked e-mail is the complete diff. There are no
changes to generated Makefile.in files.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
--- Comment #7 from Ian Lance Taylor ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635073.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111310
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110297
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110297
--- Comment #4 from Ian Lance Taylor ---
Thanks. I suspect this was broken by
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604158.html.
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
Target Milestone: ---
The cleanup attribute is defined as running a function when a variable goes out
of scope. However, the documentation does not clearly say what happens when
multiple variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682
--- Comment #9 from Ian Lance Taylor ---
If you really want to you can port the LoongArch changes back to 1.18. I don't
think that would be too hard--it's mostly a matter of adding build tags in
various places. But it's up to you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682
--- Comment #7 from Ian Lance Taylor ---
To be clear, I will at some point update libgo to newer Go releases, yes. I'm
working on adding generics support to the frontend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682
--- Comment #6 from Ian Lance Taylor ---
libgo is running behind right now, but in any case I personally don't have
plans to add LoongARCH support. I would be happy to review any patches, which
would ideally be sent using the process described
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
--- Comment #33 from Ian Lance Taylor ---
As far as I know nothing is waiting on me. Please let me know if you think
otherwise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108870
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108534
--- Comment #2 from Ian Lance Taylor ---
Yes, it's a relative path, such as
#line 1 "cgo-gcc-prolog"
These are dummy but informative line markers used to separate generated code
from user-written code, so that compiler error messages
: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
The LTO streamer can pass the source directory through without calling
remap_debug_filename. This path can escape into the debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
--- Comment #9 from Ian Lance Taylor ---
I agree that if the middle-end is going to generate calls to builtin functions,
it would be nice if the middle-end provided a function to call to define those
functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
--- Comment #4 from Ian Lance Taylor ---
Thanks Andrew, I'm testing the patch myself, but go ahead and commit if you are
satisfied with it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297
--- Comment #3 from Ian Lance Taylor ---
Created attachment 54196
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54196=edit
Potential patch
Does this patch fix the problem for you? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108057
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108072
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107992
--- Comment #1 from Ian Lance Taylor ---
Thanks. This is happening because the data structures that Go's garbage
collector uses require that all pointers be aligned on their natural
boundaries. Unfortunately m68k only provides 2-byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491
--- Comment #9 from Ian Lance Taylor ---
I would suggest adding a new field to the GODEBUG parsing in
go/runtime/runtime1.go and then calling a new C function defined in
libgo/runtime/proc.c to store the value in a C static variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581
--- Comment #7 from Ian Lance Taylor ---
Interesting, thanks. The Go frontend will never emit a call to
__atomic_fetch_add_4. I didn't realize that the middle end could convert
__atomic_add_fetch_4 into that. Your patch looks right. I'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491
--- Comment #7 from Ian Lance Taylor ---
If we use an environment variable, we should probably use the existing GODEBUG
variable.
Making the stack headroom large enough all the time should be possible. It
will burn a lot of memory on stacks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491
--- Comment #5 from Ian Lance Taylor ---
Good point, I did forget about using gold or lld. Sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491
--- Comment #3 from Ian Lance Taylor ---
The stack size on a system that does not support -fsplit-stack is set by
StackMin in libgo/runtime/stack.c. There is currently no way to override the
default value of 4MB, but we could probably add one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #46 from Ian Lance Taylor ---
A small bit of work is needed on the codegen, to read and write the export
data. And some work is required on the runtime, to clean it up to support
Darwin. It has to be done by someone with access to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #44 from Ian Lance Taylor ---
gccgo still does not work on Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107203
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106949
--- Comment #3 from Ian Lance Taylor ---
I don't think your attached patch is going to work. The code assumes that it
is running within a stack segment. You can't just add a stack segment without
changing the stack pointer.
But something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106747
Ian Lance Taylor changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106747
--- Comment #4 from Ian Lance Taylor ---
This is fixed on tip. Want to backport the patch to the GCC 12 branch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106266
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106163
--- Comment #1 from Ian Lance Taylor ---
This was originally reported against gccgo at https://go.dev/issue/53019.
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
Target Milestone: ---
When using -fnon-call-exceptions -fno-delete-dead-exceptions memory operations
that are not marked TREE_THIS_NOTRAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105225
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106033
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106033
--- Comment #1 from Ian Lance Taylor ---
Created attachment 53173
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53173=edit
Potential patch
I haven't been able to recreate the problem, but does this patch fix it?
Thanks.
|UNCONFIRMED |RESOLVED
CC||ian at airs dot com
--- Comment #2 from Ian Lance Taylor ---
Thanks, fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105315
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302
--- Comment #8 from Ian Lance Taylor ---
Thanks. Those suggested changes aren't going to make any difference as those
are text files anyhow. One is a generated C header that #include'd by C files,
and the other is a dump file intended for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302
--- Comment #6 from Ian Lance Taylor ---
The magic string itself is fine: it's the "v3;\n". Perhaps there is some
problem locating it in the file. Some of the relevant code is
go_read_export_data in gcc/go/go-backend.cc. Try to find out what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302
--- Comment #4 from Ian Lance Taylor ---
> What exactly would be the file(s) being opened in this case?
The file that should be opened is the file internal/cpu.gox in the libgo build
directory.
> When can we expect the libgo cleanup needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302
--- Comment #2 from Ian Lance Taylor ---
I have no idea why you would get a "Permission denied" error opening an import
package.
That said I would not expect this to work. Somebody would have to clean up
libgo to support Windows.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105240
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #17 from Ian Lance Taylor ---
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104973
--- Comment #4 from Ian Lance Taylor ---
The golang.org/x/sys/cpu.o is a different object file. That one uses
gcpugen.go, not cpugen.go. The original reporter is not reporting any problems
involving gcpugen.go. The cpugen.go (not gcpugen.go)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104973
--- Comment #2 from Ian Lance Taylor ---
Your build log shows a line like this:
libtool: compile:
/var/tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/build/./gcc/gccgo
-B/var/tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/build/./gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104832
--- Comment #4 from Ian Lance Taylor ---
Can you show the differences in one or two of the files, as you did before?
Thanks.
ASLR could be a factor, but only in the sense that it would make it more likely
to reveal a bug in the code. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104832
--- Comment #2 from Ian Lance Taylor ---
I just committed 2858e2afcb0a6553a222e724d8426451364ee755 which should fix the
specific problem in fmt.gox.
Let me know if you still see problems here. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101246
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
--- Comment #27 from Ian Lance Taylor ---
Thanks for the explanation. Sounds like you should send the config/gnu.h patch
to the x86 maintainers (and CC gcc-patches).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
--- Comment #25 from Ian Lance Taylor ---
> Hopefully someone knows hot to modify Makefile.tpl/Makefile.def to generate
> the correct dependencies in Makefile.in.
I suggest that you open a separate bug for that, with a complete standalone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
--- Comment #22 from Ian Lance Taylor ---
Thanks. I'll commit your patches #1 through #8.
Your patch #9 is to a generated file. The fix there can't be to patch just the
top-level Makefile.in. It has to be to patch whatever is causing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
--- Comment #21 from Ian Lance Taylor ---
*** Bug 103573 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103573
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537
--- Comment #20 from Ian Lance Taylor ---
There's no perfect way to handle the MERGE file on the release branches. What
I usually do is to resolve the patch by replacing the existing revision number
with the new one. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
--- Comment #5 from Ian Lance Taylor ---
> The only issue to resolve is how to make sure libatomic and libbacktrace
> builds in build/i686-gnu before libgo/gotools.
That question doesn't sound right. The gotools are built for the target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104149
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104149
--- Comment #2 from Ian Lance Taylor ---
We probably just need to add amd64p32 to the go:build and +build lines in
libgo/go/runtime/panic32.go. But I don't have a way to test that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98504
--- Comment #12 from Ian Lance Taylor ---
You can pass the -I option to tell the compiler where to find the fmt.gox file.
But, of course, you shouldn't have to. A "make install" should put fmt.gox in
the right place by default. I don't know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77780
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
1 - 100 of 1607 matches
Mail list logo
