https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118286
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118152
--- Comment #4 from Ian Lance Taylor ---
Oh, sorry, it's a test. It's not left behind in the tree. In the
armv8l-unknown-linux-gnueabihf/libgo directory you can run
make GOTESTFLAGS=--keep sync/atomic/check
That will leave behind a temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118152
--- Comment #2 from Ian Lance Taylor ---
Not sure what is happening here and not sure I have access to a 32-bit arm
machine to test on.
This test is supposed to crash. We are testing that the crash is correctly
recovered. I don't know why it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
--- Comment #87 from Ian Lance Taylor ---
Nice, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118008
--- Comment #10 from Ian Lance Taylor ---
I was not able to recreate the compiler crash using a cross-compiler to
arm-eabi, using either GCC tip or GCC 14 branch. Are you building on an
arm-linux system? Are there any such systems left in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117812
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117891
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
Bug 85741 depends on bug 117833, which changed state.
Bug 117833 Summary: [15 regression] Bootstrap failure in
gcc/go/gofrontend/go-encode-id.cc since r15-5735-g1046c32de4956c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117833
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117833
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117833
--- Comment #6 from Ian Lance Taylor ---
The code is safe but I can see that it would be difficult for the compiler to
see that. I'll increase the buffer size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117812
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
--- Comment #16 from Ian Lance Taylor ---
This may be a blocker for macOS support, but I don't think it's a major one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
--- Comment #14 from Ian Lance Taylor ---
Note that on x86_64 Linux libgo no longer uses ucontext.h. (Well, the #include
is still there, but it is not used.) So we have a clear path to removing
ucontext.h on any given system, but it does unfor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85629
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97082
--- Comment #6 from Ian Lance Taylor ---
I think that mtest should pass now on Darwin. I think the dwarf5 tests may
still be failing. This seems to be because dsymutil does not understand
dwarf5, at least on the compile farm macOS machine that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
--- Comment #12 from Ian Lance Taylor ---
Sure, we can do that patch for now. Thanks. unsupported is fine too.
Let's not close the bug, though. The real fix is to not put very large objects
on the stack--we don't want to do that for split-sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
--- Comment #9 from Ian Lance Taylor ---
It does work for me on x86_64 GNU/Linux. The big stack allocation is handled
by the split-stack support.
This of course leaves the question of why it is making such a large stack
allocation to begin with
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 de
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 = 0
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&action=edit
Test case
This is repeat of PR 53125, which was closed in 2012.
The attached te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114500
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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
Status|UNCONFIRMED
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 __go_setcon
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 implementa
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 GNU/Li
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
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110297
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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 are
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 repor
: 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&action=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 alignment
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 com
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 bu
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 b
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 a
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
Status|UNCONFIRM
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 like
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
Status|UNCONFIRMED
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&action=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
Status|UNCONFIRMED
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 huma
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 for
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.
1 - 100 of 1619 matches
Mail list logo
