[Bug libbacktrace/114941] libbacktrace build is broken for FDPIC uclibc targets by r14-5173-g2b64e4a54042
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 from Ian Lance Taylor --- What is the correct way to get the address at which the shared library was loaded when using FDPIC?
[Bug go/114582] go.test/test/fixedbugs/issue34123.go FAILs
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 default memory allocation randomly profiles a small number of operations, and determining whether to do a random profile appears to involve floating-point operations (libgo/go/runtime/fastlog2.go).
[Bug go/114582] go.test/test/fixedbugs/issue34123.go FAILs
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. ***
[Bug go/114583] go.test/test/fixedbugs/issue4562.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114583 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Ian Lance Taylor --- Appears to be the same problem at PR 114582. *** This bug has been marked as a duplicate of bug 114582 ***
[Bug go/114582] go.test/test/fixedbugs/issue34123.go FAILs
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. ***
[Bug go/114584] go.test/test/nil.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114584 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Ian Lance Taylor --- Appears to be the same as PR 114582. *** This bug has been marked as a duplicate of bug 114582 ***
[Bug go/114582] go.test/test/fixedbugs/issue34123.go FAILs
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. ***
[Bug go/114581] go.test/test/fixedbugs/issue22881.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114581 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Ian Lance Taylor --- I wrote a long explanation of the problem in PR 114582, so closing this one in favor of that one. *** This bug has been marked as a duplicate of bug 114582 ***
[Bug go/114582] go.test/test/fixedbugs/issue34123.go FAILs
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 }
The *p = 0 in f will raise a SIGSEGV. The Go runtime will turn that into a
panic. The recover in main will prevent that panic from killing the program.
The unwind code works by walking up the stack until it finds a recover. When
it finds a recover, it records that stack frame as the end of the unwind. It
runs the recover, then walks up the stack again to unwind it. In the second
walk, it checks that it does not walk past the stack frame that calls recover.
Recording the stack frame is done based on what the signal handler calls the
CFA, which is, basically, the frame pointer. It is also based on whether a
signal occurred in that frame.
In this test case, the function f is so simple that it has no frame. That
turns out to mean that f's CFA is the same as main's CFA. In the first stack
walk, we find main, and record main's CFA as the point where the second unwind
should stop. In the second stack walk, when we get to f, we think we have
reached the end. But we haven't, because we haven't reached main yet. This
causes an assert, which shows up as a SIGABRT.
That is what happens today. But it would work fine if we knew that a signal
occurred in f, as in fact it did. However, we don't, because of this code in
libgcc/config/sol2-unwind.h:
/* SIGFPE for IEEE-754 exceptions is delivered after the faulting insn
rather than before it, so don't set fs->signal_frame in that case.
We test whether the cexc field of the FSR is zero. */
if ((mctx->fpregs.fpu_fsr & 0x1f) == 0)
fs->signal_frame = 1;
If we unconditionally set fs->signal_frame, as is done on Linux, this would
work. And it works on 64-bit SPARC, because those flags turn out to be zero.
But on 32-bit SPARC, they are not zero. Specifically, bit 0 is set, indicating
that an inexact operation occurred. I don't know why.
That code was added by
https://gcc.gnu.org/legacy-ml/gcc-patches/2013-05/msg01390.html. If I undo
that change, so that fs->signal_frame is set unconditionally as it was before,
then the Go test passes.
I don't know why it is reasonable to assume that if the floating-point inexact
flag is set then the signal is a floating-point signal. In this case that is
clearly incorrect.
Because the problem here appears to be a Solaris-specific problem with
Solaris-specific code, I don't plan to work any further on it.
[Bug go/106813] getSiginfo() libgo/runtime/go-signal.c missing Solaris specific code to get ret.sigpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106813 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Ian Lance Taylor --- Thanks. Patch committed. This should be fixed now.
[Bug go/114875] runtime/runtime.h should be updated to compile under C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114875 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Ian Lance Taylor --- Should be fixed on tip by 678dc5e85053f1a1ca76997eec95ba8823bb6830. Thanks.
[Bug go/114581] go.test/test/fixedbugs/issue22881.go FAILs
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.
[Bug go/52357] 64bit-out.go and go.test/test/cmplxdivide.go time out on Solaris/SPARC
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.
[Bug rtl-optimization/114881] New: Very slow compilation on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114881 Bug ID: 114881 Summary: Very slow compilation on SPARC Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization 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 case is a conversion to C of a machine generated test case in Go (the machine generated Go source is in gcc/testsuite/go.test/test/cmplxdivide1.go). When I compile this test case without optimization on an x86_64 GNU/Linux system, it takes 9.7 seconds. With -O2 it takes 4.9 seconds. When I compile this test case without optimization on a SPARC Solaris 2.11 system, it takes 3 minutes 30 seconds. With -O2 it takes 2 minutes 30 seconds. The SPARC machine is slower than the x86_64 machine. But it's not that much slower. The time difference is extreme. In -ftime-report on the SPARC system, most of the time is: integrated RA : 33.43 ( 16%) 0.05 ( 4%) 33.56 ( 16%) 12M ( 14%) LRA hard reg assignment: 144.62 ( 70%) 0.35 ( 30%) 145.52 ( 70%) 0 ( 0%)
[Bug go/114500] go.test/test/fixedbugs/issue23781.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114500 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Ian Lance Taylor --- Thanks. Fixed.
[Bug go/114454] go.test/test/fixedbugs/issue27836.go FAILs with LANG=C
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 testsuite runs the test: the GCC testsuite sets LANG=C before all tests. As best I can tell the problem must be arising somehow in the DejaGNU code. The filenames in the test use UTF-8 non-ASCII characters. But I haven't been able to figure out where the problem is.
[Bug go/114453] 32-bit go.test/test/fixedbugs/issue16016.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114453 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Ian Lance Taylor --- Thanks. Fixed.
[Bug go/114463] go.test/test/fixedbugs/issue4458.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114463 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ian Lance Taylor --- Thanks. Fixed.
[Bug libbacktrace/114201] [14 regression] r14-9247-gc6d4fb0062c605 breaks a bunch of tests on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114201 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Ian Lance Taylor --- Should be fixed now. Thanks for reporting it.
[Bug libbacktrace/114201] [14 regression] r14-9247-gc6d4fb0062c605 breaks a bunch of tests on powerpc64 BE
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 from Ian Lance Taylor --- Looks like this is happening because objcopy --only-keep-debug doesn't copy the .opd section. libbacktrace relies on the .opd section to convert from the function descriptor to the code address. Fortunately it looks like we can use the .opd section from the original file.
[Bug go/113668] [14 Regression] libgo soname bump needed for the GCC 14 release?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113668 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ian Lance Taylor --- I don't know that it was truly needed, but bumped anyhow. Thanks.
[Bug go/113530] libgo ftbfs on arc-linux-gnu
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?
[Bug c/110029] more precise documentation for cleanup attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110029 --- Comment #4 from Ian Lance Taylor --- Thanks!
[Bug go/113447] [14 regression] issue20185.go etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113447 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ian Lance Taylor --- Fixed, sorry about that.
[Bug go/113143] Remove usage of ucontext.h
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_setcontext(c) setcontext(c) #define __go_makecontext(c, fn, sp, size) \ ((c)->uc_stack.ss_sp = sp, (c)->uc_stack.ss_size = size, makecontext(c, fn, 0)) #endif libgo/runtime/proc.c: various calls to __go_getcontext, __go_setcontext, and __go_makecontext.
[Bug go/113143] Remove usage of ucontext.h
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 implementation does not require these functions because it provides assembler code. This of course limits the gc implementation to only support a limited number of targets: those for which the assembler code exists. libgo is intended to be more portable. To be clear I am fine with removing or guarding references to ucontext.h where that makes sense. I'm just pointing out that the code can't in general work if the *context functions are not available. It's unfortunate that POSIX removed them without providing adequate replacements. Saying that they "can be replaced using POSIX threads functions" is simply false. They provide a portable mechanism for a userspace threads mechanism on top of POSIX threads. Without them there is no way for libgo to implement goroutines efficiently.
[Bug go/113143] Remove usage of ucontext.h
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/Linux systems continue to provide them.
[Bug go/113143] Remove usage of ucontext.h
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 POSIX systems. (On x86_64 GNU/Linux libgo provides assembler versions of those functions (in libgo/runtime/go-context.S) that are more efficient for libgo's purposes.)
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
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 you don't configure with --enable-languages=go then you shouldn't get libgo.
[Bug middle-end/112710] [13/14 Regression] ICE: in write_type, at cp/mangle.cc:2226 with -fdump-go-spec=filename -flto -fno-use-linker-plugin
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 from Ian Lance Taylor --- Also -fdump-go-spec isn't useful for C++ code. Why does this come up? What are you trying to do?
[Bug libbacktrace/112263] [C++23] std::stacktrace does not identify symbols in shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Ian Lance Taylor --- Fix committed.
[Bug libbacktrace/112396] "make check" should not error out, even when some checks failed
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 from Ian Lance Taylor --- libbacktrace is just using automake and its testsuite support. Anybody know if there is a way to tell automake not to exit 1 on test failure?
[Bug libbacktrace/112263] [C++23] std::stacktrace does not identify symbols in shared library
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.
[Bug libbacktrace/112263] [C++23] std::stacktrace does not identify symbols in shared library
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
[Bug libbacktrace/112263] [C++23] std::stacktrace does not identify symbols in shared library
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 from Ian Lance Taylor --- What OS and processor? Is this x86 GNU/Linux?
[Bug go/111310] BITINT_TYPE unsupported in godump.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111310 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Ian Lance Taylor --- Thanks, fixed.
[Bug go/110297] [13/14 Regression] all libgo tests fail on arm-linux-gnueabi and arm-linxu-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110297 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #7 from Ian Lance Taylor --- Should be fixed now.
[Bug go/110297] [13/14 Regression] all libgo tests fail on arm-linux-gnueabi and arm-linxu-gnueabihf
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.
[Bug c/110029] New: more precise documentation for cleanup attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110029
Bug ID: 110029
Summary: more precise documentation for cleanup attribute
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: 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 in scope.
For example:
#include
static void adone (int *p __attribute__((unused))) {
puts("adone");
}
static void bdone (int *p __attribute__((unused))) {
puts("bdone");
}
void f () {
int a __attribute__((cleanup (adone)));
int b __attribute__((cleanup (bdone)));
puts("f");
}
int main() {
f ();
}
With the current implementation, this prints
f
bdone
adone
This follows from the implementation, which is that a cleanup attribute becomes
a try/finally construct at the point of the variable declaration. But it does
not obviously follow from the documentation.
The documentation should be clear about this. Thanks.
[Bug libffi/108682] libffi needs to merge upstream to get LoongArch support
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.
[Bug libffi/108682] libffi needs to merge upstream to get LoongArch support
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.
[Bug libffi/108682] libffi needs to merge upstream to get LoongArch support
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 at https://go.dev/doc/gccgo_contribute.
[Bug go/104290] [12/13 Regression] trunk 20220214 fails to build libgo on i686-gnu
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.
[Bug libbacktrace/108870] Gather file/line info for file/namespace/static variables
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 from Ian Lance Taylor --- Currently libbacktrace builds a mapping from compilation-unit PC ranges to line programs. This would be a completely different mapping, from variable addresses to variable information. As far as I know we would have to build it from a complete scan of the .debug_info section. Most programs don't need this information, so it would be a shame to always build it. Now I wish that there were some sort of options argument to backtrace_create_state. But actually backtrace_create_state does take a threaded argument that almost everybody passes as 0. The only non-zero cases I could find in a web search were passing 1. So we could redefine that as an option. Then programs that want variable information could pass 2 (or 3 for variables plus threading). With that option set, we can build a list of address mapping to variables. The next question would be whether we should unify the function and variable mapping or keep them separate. If we unify them we can use backtrace_pcinfo to get variable information. If we don't we should have another function that does variable lookup. It seems that the DWARF information does not include the size of the variable, so to really get this right we'll have to also use the size information from the symbol table, which is already available via backtrace_syminfo. Any thoughts on whether the function/variable mappings should be unified or distinct?
[Bug lto/108534] LTO streamer does not remap source directory
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 report problems in the right place. The compiler is being executed in a temporary directory created during the build, so the working directory is meaningless. Other references to files in that temporary directory are rewritten by a -fdebug-prefix-map option. Unfortunately, that option fails to rename the working directory that is pulled in for the relative #line option.
[Bug lto/108534] New: LTO streamer does not remap source directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108534 Bug ID: 108534 Summary: LTO streamer does not remap source directory Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: 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 information, which can make it hard to create reproducible results when using LTO. Specifically lto_output_location_1 writes the output of get_src_pwd into the stream without calling remap_debug_filename. This causes some complexity for Go tooling as discussed at the comment thread starting at https://go-review.googlesource.com/c/go/+/413974/15#message-4a4b317f08c2aee261b93c37c82a2bcab21830d8 . Basically, the Go tool is trying to get a reproducible build using LTO, and failing due to the inclusion of an unmapped directory.
[Bug go/108426] [13 regression] SEGV in contains_struct_check
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.
[Bug go/108426] [13 regression] SEGV in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Ian Lance Taylor --- I committed the patch.
[Bug go/108426] [13 regression] SEGV in contains_struct_check
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.
[Bug libbacktrace/108297] libtool link b2test fails: Unrecognized argument: --build-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Ian Lance Taylor --- The LTO problem seems like a different problem, and doesn't seem related to libbacktrace. If LTO doesn't work HP/UX, do you have a simple test that the configure script could run to see whether it works?
[Bug libbacktrace/108297] libtool link b2test fails: Unrecognized argument: --build-id
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.
[Bug libbacktrace/108297] libtool link b2test fails: Unrecognized argument: --build-id
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 from Ian Lance Taylor --- Does HP/UX 11.11 use ELF? If so, I guess we need a configure test to see whether the linker supports the --build-id option. If it doesn't, I guess we need to skip the debuginfo tests.
[Bug go/108057] [13 Regression] libgo21 not ABI compatible gcc12 vs gcc13?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108057 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Ian Lance Taylor --- Fixed by bumping the major version. Thanks.
[Bug sanitizer/108072] [13 Regression] gcc/libbacktrace/elf.c:5144: multiple definition of `backtrace_uncompress_zstd' with --with-build-config=bootstrap-asan since r13-4547-g9df1ba9a35b86e
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 from Ian Lance Taylor --- That patch looks right to me. Thanks.
[Bug go/107992] m68k-linux-gnu bootstap error in gofrontend
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 for 4-byte pointers, not 4-byte alignment. I don't know if there will be a simple fix. We could probably adjust the alignment for data structures defined in Go, which would fix this case, but that wouldn't help with C interoperability.
[Bug go/107491] Gccgo stack not resizing on Solaris
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.
[Bug target/107581] ICE on sparc-leon-uclibc during go build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Ian Lance Taylor --- Should be fixed on mainline. Thanks.
[Bug target/107581] ICE on sparc-leon-uclibc during go build
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 commit after testing.
[Bug target/107581] ICE on sparc-leon-uclibc during go build
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 from Ian Lance Taylor --- This crash appears to be fairly deep in the middle-end. Nothing has changed recently in the Go frontend. Has this crash just started appearing, or is this the first time you are trying this? If it is a relatively new crash then I think it must be related to some middle-end change. Thanks.
[Bug go/107491] Gccgo stack not resizing on Solaris
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 but maybe that is OK.
[Bug go/107491] Gccgo stack not resizing on Solaris
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.
[Bug go/107491] Gccgo stack not resizing on Solaris
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 based on an environment variable. (Or we could support -fsplit-stack on Solaris if there is an available slot accessible via the TLS segment register. On Linux x86_64 we use %fs:0x70.)
[Bug go/46986] Go is not supported on Darwin
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 modern Darwin system.
[Bug go/46986] Go is not supported on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #44 from Ian Lance Taylor --- gccgo still does not work on Darwin.
[Bug go/107203] Possible missing sanity check in gofrontend/ast-dump.cc ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107203 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #2 from Ian Lance Taylor --- Thanks, but the code is fine. It is only run when as_pairs is true, meaning that the list consists of pairs of values.
[Bug libgcc/106949] Memory leak using VLA with -fsplit-stack
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 your suggestion might work. If the function is going to call __morestack_allocate_stack_space, then at the start of the function call a new function __morestack_allocating_stack_space. That function can return a pointer. The __morestack_allocate_stack_space function can add its allocations to a list at that pointer. At the end of the function call another new function that releases the allocated space. Some work will be required to make sure that the space gets released if an exception is thrown.
[Bug go/106747] [12 Regression] Regression: go version does not print a number in 12.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106747 Ian Lance Taylor changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Ian Lance Taylor --- Fixed on GCC 12 branch.
[Bug go/106747] Regression: go version does not print a number in 12.x
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?
[Bug go/106266] Libgo fails with recent glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106266 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ian Lance Taylor --- Should be fixed. Thanks.
[Bug tree-optimization/106163] generic-match does not honor -fnon-call-exceptions -fno-delete-dead-exceptions
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.
[Bug tree-optimization/106163] New: generic-match does not honor -fnon-call-exceptions -fno-delete-dead-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106163
Bug ID: 106163
Summary: generic-match does not honor -fnon-call-exceptions
-fno-delete-dead-exceptions
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: 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 should not be removed from the execution
path. However, the generic_simplify function, at least, does not honor this.
This test case, when compiled with -fnon-call-exceptions
-fno-delete-dead-exceptions, should exit with a zero status. However, it
currently fails, because "i = *p ^ *p;" is simplified to "i = 0;".
// { dg-do run { target { i?86-*-linux* i?86-*-gnu* x86_64-*-linux* } } }
// { dg-additional-options "-fexceptions -fnon-call-exceptions
-fno-delete-dead-exceptions" }
#include
#include
#include
static void
sighandler (int signo, siginfo_t* si, void* uc)
{
throw (5);
}
struct S { void *p1, *p2; };
struct S v;
__attribute__ ((noinline))
int
dosegv ()
{
int *p = 0;
int i __attribute__((unused)) = 0;
i = *p ^ *p;
return 0;
}
int main ()
{
struct sigaction sa;
memset (, 0, sizeof sa);
sa.sa_sigaction = sighandler;
sigaction (SIGSEGV, , NULL);
sigaction (SIGBUS, , NULL);
try {
dosegv ();
}
catch (int x) {
return (x != 5);
}
return 1;
}
[Bug go/105225] build failure with musl libc 1.2.3 due to sysinfo.go error: redefinition of 'SYS_SECCOMP'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105225 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Ian Lance Taylor --- Fixed on mainline. Thanks for reporting it.
[Bug go/106033] [13 Regression] libgo fails with error: reference to undefined name ‘_libgo_loff_t_type’ since r13-1159-g7f195a2270910a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106033 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ian Lance Taylor --- Should be fixed now, sorry for the trouble.
[Bug go/106033] [13 Regression] libgo fails with error: reference to undefined name ‘_libgo_loff_t_type’ since r13-1159-g7f195a2270910a
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.
[Bug libbacktrace/105721] libbacktrace: update README
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105721 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||ian at airs dot com --- Comment #2 from Ian Lance Taylor --- Thanks, fixed.
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #22 from Ian Lance Taylor --- Yes, closing this issue.
[Bug go/105315] go build fail on ppc: has no member named 'gregs'; did you mean 'regs'?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105315 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Ian Lance Taylor --- Thanks, should be fixed now, I hope.
[Bug go/105302] gccgo for Windows using MinGW-w64
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 human inspection. The .gox files are not generated directly by the Go frontend. They are generated by writing out an object file in the usual way, and then using objcopy to create the .gox file. Ths form of .gox file is an object file that only contains a single section.
[Bug go/105302] gccgo for Windows using MinGW-w64
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 it returns.
[Bug go/105302] gccgo for Windows using MinGW-w64
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 MinGW(-w64) support? I don't know of anybody who is working on this.
[Bug go/105302] gccgo for Windows using MinGW-w64
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.
[Bug libbacktrace/105240] backtrace_pcinfo leaks memory
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 from Ian Lance Taylor --- mmap is definitely preferred. The malloc implementation is only there to support systems without mmap. That said I'm not sure I understand the valgrind report. Some of that memory is not lost as long as the program has a pointer to the backtrace_state. It's true that there is no way to release all memory allocated by the state. That is not a goal, as I expect that programs will allocate a backtrace_state and use it until the program is complete. What kinds of reports do you see if you put the backtrace_state in a global variable?
[Bug rtl-optimization/105091] RTL dse1 remove stack mem storing incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091 --- Comment #17 from Ian Lance Taylor --- Thanks.
[Bug rtl-optimization/105091] RTL dse1 remove stack mem storing incorrectly
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 from Ian Lance Taylor ---
This program should print
0
1
but when I run it on gcc112.fsffrance.org, compiling with -O2, it prints
1
824633846216
package main
func main() {
for _, test := range []struct {
x, y, want []int
}{
{[]int{}, []int{}, nil},
{[]int{0}, []int{0}, []int{0}},
} {
p := test.x
F(p)
}
}
func F(v interface{}) {
recover()
println(cap(v.([]int)))
}
This can be compiled (though not run) using a cross-compiler without building
libgo.
The code coming into 280r.dse1 seems to be indexing from the end of the array.
I see
code_label 96 126 55 4 118 (nil) [0 uses])
(note 55 96 56 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 56 55 57 4 (set (reg:DI 144)
(mult:DI (reg:DI 121 [ ivtmp_47 ])
(const_int -72 [0xffb8]))) "foo.go":4:2 154 {muldi3}
(nil))
(insn 57 56 59 4 (set (reg/f:DI 145)
(plus:DI (reg/f:DI 173)
(reg:DI 144))) "foo.go":4:2 66 {*adddi3}
(expr_list:REG_DEAD (reg/f:DI 173)
(expr_list:REG_DEAD (reg:DI 144)
(nil
where earlier I see
(insn 17 16 19 2 (set (mem/f/c:DI (plus:DI (reg/f:DI 110 sfp)
(const_int 32 [0x20])) [8 GOTMP.5[0].x.__values+0 S8 A128])
(reg/f:DI 117 [ _11 ])) "foo.go":4:23 670 {*movdi_internal64}
(expr_list:REG_DEAD (reg/f:DI 117 [ _11 ])
(nil)))
and
(insn 120 4 121 2 (set (reg/f:DI 173)
(plus:DI (reg/f:DI 110 sfp)
(const_int 32 [0x20]))) 66 {*adddi3}
(nil))
So register 173 is although insn 120 doesn't indicate that. Then the
280r.dse1 pass drops out all the assignments to GOTMP.5, presumably because it
doesn't understand that register 173 points to it.
[Bug go/104973] GCC 11.2.1 build failure with Go support (mv: cannot stat 'cpugen.o': No such file or directory)
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) file is an input for internal/cpu.o.
[Bug go/104973] GCC 11.2.1 build failure with Go support (mv: cannot stat 'cpugen.o': No such file or directory)
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/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/cpu /var/tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/gcc-11-20211127/libgo/go/internal/cpu/cpu.go /var/tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/gcc-11-20211127/libgo/go/internal/cpu/cpu_amd64.go /var/tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/gcc-11-20211127/libgo/go/internal/cpu/cpu_x86.go cpugen.go My build log shows a line like this: libtool: compile: /home/iant/gcc/gcc-11-objdir/./gcc/gccgo -B/home/iant/gcc/gcc-11-objdir/./gcc/ -B/home/iant/gcc/gcc-11-install/x86_64-pc-linux-gnu/bin/ -B/home/iant/gcc/gcc-11-install/x86_64-pc-linux-gnu/lib/ -isystem /home/iant/gcc/gcc-11-install/x86_64-pc-linux-gnu/include -isystem /home/iant/gcc/gcc-11-install/x86_64-pc-linux-gnu/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/cpu ../../../gcc-11-branch/libgo/go/internal/cpu/cpu.go ../../../gcc-11-branch/libgo/go/internal/cpu/cpu_amd64.go ../../../gcc-11-branch/libgo/go/internal/cpu/cpu_x86.go cpugen.go -fPIC -o internal/.libs/cpu.o Note that my line has a -o ption at the end but yours does not. I think that is the root of the problem. Earlier your log has this: /usr/sbin/mkdir -p internal; files=`echo /var/tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/gcc-11-20211127/libgo/go/internal/cpu/cpu.go /var/tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/gcc-11-20211127/libgo/go/internal/cpu/cpu_amd64.go /var/tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/gcc-11-20211127/libgo/go/internal/cpu/cpu_x86.go cpugen.go | sed -e 's/[^ ]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/bash ./libtool --tag GO --mode=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/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=`echo internal/cpu.lo | sed -e 's/.lo$//'` -o internal/cpu.lo $files My log has this: /bin/mkdir -p internal; files=`echo ../../../gcc-11-branch/libgo/go/internal/cpu/cpu.go ../../../gcc-11-branch/libgo/go/internal/cpu/cpu_amd64.go ../../../gcc-11-branch/libgo/go/internal/cpu/cpu_x86.go cpugen.go | sed -e 's/[^ ]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/sh ./libtool --tag GO --mode=compile /home/iant/gcc/gcc-11-objdir/./gcc/gccgo -B/home/iant/gcc/gcc-11-objdir/./gcc/ -B/home/iant/gcc/gcc-11-install/x86_64-pc-linux-gnu/bin/ -B/home/iant/gcc/gcc-11-install/x86_64-pc-linux-gnu/lib/ -isystem /home/iant/gcc/gcc-11-install/x86_64-pc-linux-gnu/include -isystem /home/iant/gcc/gcc-11-install/x86_64-pc-linux-gnu/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=`echo internal/cpu.lo | sed -e 's/.lo$//'` -o internal/cpu.lo $files Here the -o option is present in both cases. So why does the -o option disappear? Could this be somehow due to the patches being applied at the start of your build log?
[Bug go/104832] gccgo / libgo Reproducibility Problem
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 code should produce identical output regardless of whether using ASLR or not.
[Bug go/104832] gccgo / libgo Reproducibility Problem
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.
[Bug go/101246] gccgo cross-compiler targeting arm fails to build with gcc 11. Missing structs in runtime.inc. Using uclibc-ng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101246 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #10 from Ian Lance Taylor --- Should be fixed on tip. Thanks for the patch.
[Bug go/104290] [12 Regression] trunk 20220214 fails to build libgo on i686-gnu
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).
[Bug go/104290] [12 Regression] trunk 20220214 fails to build libgo on i686-gnu
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 explanation of the problem. This bug is mixed in with a lot of other things. > Another patch that is not applied: gcc_config_gnu.h.diff. Who will commit > that patch? It is not directly relating to libgo, but gotools fails to build > later on without it. I assume you mean this patch: https://gcc.gnu.org/bugzilla/attachment.cgi?id=52360=edit I don't understand why that patch makes any difference. Where is the code that checks OPTION_GLIBC?
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
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 Makefile.in to be generated the way that it is. I don't myself know what is going wrong there.
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
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. ***
[Bug go/103573] [12 Regression] trunk 20211203 fails to build libgo on i686-gnu (hurd)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103573 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Ian Lance Taylor --- Closing in favor of PR 104290. *** This bug has been marked as a duplicate of bug 104290 ***
[Bug go/100537] [12 Regression] Bootstrap-O3 and bootstrap-debug fail on 32-bit ARM after gcc-12-657-ga076632e274a
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.
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
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. They shouldn't depend on build/i686-gnu, which is built for the host. The gotools should depend on the target libatomic and the target libbacktrace, and they do. What problem are you trying to solve?
[Bug go/104149] [12 Regression] trunk 20220120 ftbfs in gotools on x86_64-linux-gnux32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104149 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Ian Lance Taylor --- Fixed on tip.
[Bug go/104149] [12 Regression] trunk 20220120 ftbfs in gotools on x86_64-linux-gnux32
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.
[Bug lto/98504] [11/12 Regression] bootstrap broken in libgo on ia64-linux-gnu
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 why you are seeing a problem there.
[Bug go/77780] Go front-end ignores NO_DOLLAR_IN_LABEL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77780 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Ian Lance Taylor --- This was fixed a while back for the GCC 8 release.
