[Bug libbacktrace/98818] [libbacktrace] Don't throw fatal error for unsupported dwarf version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98818 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ian Lance Taylor --- I've implemented the suggestion of passing -1 to the error callback when the DWARF version is unknown.
[Bug go/99458] libgo doesn't build against latest glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99458 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ian Lance Taylor --- Fixed, I hope.
[Bug go/99553] libgo/misc/cgo/testcarchive/testdata/main_unix.c:39: suspicious compare ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99553 Ian Lance Taylor changed: What|Removed |Added Last reconfirmed||2021-03-11 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Ian Lance Taylor --- Thanks. Sent https://golang.org/cl/300993 to fix this in the upstream sources.
[Bug go/99553] libgo/misc/cgo/testcarchive/testdata/main_unix.c:39: suspicious compare ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99553 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Ian Lance Taylor --- Thanks, fixed.
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 99553, which changed state. Bug 99553 Summary: libgo/misc/cgo/testcarchive/testdata/main_unix.c:39: suspicious compare ? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99553 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug bootstrap/97550] libgcc ICE on x86_64-linux-gnu compiler hosted on msys2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97550 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #1 from Ian Lance Taylor --- To be pedantically clear, there are two independent problems here. The first is the segmentation fault. The second is that libbacktrace couldn't find an executable to open. I'll look at the libbacktrace problem but someone else will have to look at the segmentation fault.
[Bug go/98041] [11 Regression] libgo doesn't build on mipsel-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98041 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ian Lance Taylor --- Fixed on trunk.
[Bug go/98153] [11 Regression] libgo ftbfs on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98153 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ian Lance Taylor --- Thanks. Patch committed.
[Bug libbacktrace/97082] new test 'mtest' fails for Mach-O/Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97082 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #2 from Ian Lance Taylor --- Does btest pass? It's hard to see why mtest would fail if btest passes.
[Bug libbacktrace/97227] dsymutil runs on ELF execs during libbacktrace testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97227 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ian Lance Taylor --- Thanks, should be fixed.
[Bug go/98402] [11 Regression] libgo build broken on arm-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98402 --- Comment #1 from Ian Lance Taylor --- Odd. What version of mpfr do you have installed?
[Bug go/98402] [11 Regression] libgo build broken on arm-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98402 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Ian Lance Taylor --- This should be fixed now.
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Ian Lance Taylor --- This should be fixed now.
[Bug bootstrap/98493] [11 regression] bootstrap build fails in go part of build after r11-6371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98493 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Ian Lance Taylor --- This should be fixed now.
[Bug go/98504] [11 Regression] bootstrap broken in libgo on ia64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98504 --- Comment #3 from Ian Lance Taylor --- Maybe I'm missing something obvious, but I don't see how this is possible. The code in the Go frontend is if (suffix.compare(2, 5, "thunk") == 0 && Gogo::is_digits(suffix.substr(7))) return pos; The crash is apparently occurring on the call to suffix.substr(7). Given that suffix.compare already worked, there should be no way that that code could crash. So to me this looks like a miscompilation of the Go frontend code, rather than a bug in the Go frontend.
[Bug bootstrap/98493] [11 regression] bootstrap build fails in go part of build after r11-6371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98493 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #4 from Ian Lance Taylor --- Should be fixed (this time for sure).
[Bug go/98510] [11 Regression] bootstrap broken in libgo on sparc64-linux-gnu, building the 32bit multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98510 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Ian Lance Taylor --- Should be fixed.
[Bug go/98610] syscall.TestUnshareUidGidMapping sporadically fails on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98610 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Ian Lance Taylor --- Fixed.
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #13 from Ian Lance Taylor --- In this case I've already sent the change out for review at https://golang.org/cl/283692 and they should go in today (as before, this process would go faster if you were able to send changes using Gerrit).
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #15 from Ian Lance Taylor --- Should be fixed.
[Bug debug/98716] [11 Regression] sanitizer regressions by r11-6755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98716 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #5 from Ian Lance Taylor --- I'm not seeing any failures in the Go testsuite with GNU binutils 2.35.1. Anybody know what changed in newer version of the binutils?
[Bug debug/98716] [11 Regression] sanitizer regressions by r11-6755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98716 --- Comment #6 from Ian Lance Taylor --- On the other hand the libbacktrace testsuite now fails when using dwz 0.13+20201015-2. But I guess that is not a GCC problem. dwz -m b3test_dwz_common.debug b3test_dwz_1 b3test_dwz_2 dwz: b3test_dwz_1: Unknown DWARF DW_FORM_implicit_const dwz: b3test_dwz_1: Couldn't read abbrev at offset 0x0 dwz: b3test_dwz_2: Unknown DWARF DW_FORM_implicit_const dwz: b3test_dwz_2: Couldn't read abbrev at offset 0x0 dwz: Too few files for multifile optimization make[3]: *** [Makefile:2436: b3test_dwz] Error 1
[Bug debug/98716] [11 Regression] sanitizer regressions by r11-6755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98716 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Ian Lance Taylor --- This is probably fixed. I couldn't fully test it because of PR 98708. Let me know if it's still broken.
[Bug go/98823] go testsuite and timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823 --- Comment #1 from Ian Lance Taylor --- The Go testsuite is intended to have timeouts for all tests. The test gcc/testsuite/go.test/test/fixedbugs/issue19182.go is just passed off to the TCL function go-torture-execute. Running the executable gcc/testsuite/go/issue19182.x is the "execute" part of the test. go-torture-execute calls the TCL function go_load to run the test. My assumption, which may well be wrong, is that a TCL function like go_load applies a timeout by default. I'm not even sure where go_load is defined, but it clearly does exist. I'm still baffled by how all the DejaGNU code works. It's odd that issue19182.x keeps running. The test itself is intended to be self-limiting. I'm not sure what is going on there.
[Bug go/98823] go testsuite and timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #3 from Ian Lance Taylor ---
I'm sure I'm missing something, but what I see in lib/gcc-dg.exp is code that
says "if ${tool}_load already exists, then wrap it." I don't see the original
implementation of ${tool}_load.
[Bug go/98823] go testsuite and timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823 --- Comment #6 from Ian Lance Taylor --- Thanks. So, unix_load does seem to have a timeout by default, and as far as I can see the Go testsuite code isn't doing anything to change that. Why isn't the timeout working?
[Bug go/98823] go testsuite and timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823 --- Comment #8 from Ian Lance Taylor --- The test is pretty simple. https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/go.test/test/fixedbugs/issue19182.go;h=e1f3ffb4749f4dbb4c2204c4a0f484aea91b4771;hb=HEAD The interesting thing it does is start a goroutine that runs an infinite loop. But the main goroutine should always terminate. The test doesn't do any signal handling at all so a SIGTERM should always just terminate the program.
[Bug go/98823] go testsuite and timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823 --- Comment #11 from Ian Lance Taylor --- I'm just noting that DejaGNU appears to have a bug in the standard_wait procedure: http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=blob;f=lib/remote.exp;h=1c9971a076415adc2fcdc04ab8f78cc832ce1098;hb=HEAD#l1162 The code seems to assume that the parameter timeout will set the timeout for the remote_expect. But as far as I can tell, when running under expect, "timeout" is always a global variable. So the $timeout that appears in the function refers to the global variable named "timeout", not the parameter named "timeout". This means that although the DejaGNU procedure unix_load appears to set the timeout to the value of the global variable "test_timeout", and logs various messages to that effect, in fact that variable has no effect. Only the variable "timeout" matters. However, this DejaGNU bug is not important in the larger scheme of things and does not seem to affect this issue.
[Bug go/98823] go testsuite and timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823 --- Comment #12 from Ian Lance Taylor --- Other than the timeout issue, DejaGNU appears to work as expected on my system. After 300 seconds, it will run the shell command "kill -2 $spid" which kills the program. The program issue19182.go does nothing special with SIGINT, and in my testing it simply exits. In any case, if the program does not exist after the "kill -2", DejaGNU waits 5 seconds and does a "kill -15", then waits another 5 seconds and does a "kill -9". In short, I can't recreate the problem and I don't see where the bug is. What version of DejaGNU is in use on the system where the problem occurs? I'm testing with DejaGNU 1.6.2.
[Bug go/98823] go testsuite and timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823 --- Comment #14 from Ian Lance Taylor --- The code that kills the test process (close_wait_program in lib/remote.exp) has indeed changed between DejaGNU 1.6.1 and 1.6.2. That said, I don't see any reason why the 1.6.1 code wouldn't kill the test process.
[Bug go/99164] gccgo internal compiler error: alias receiver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99164 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Ian Lance Taylor --- Thanks. This is already fixed by https://golang.org/cl/291991.
[Bug go/99267] Build fails for AIX 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99267 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #1 from Ian Lance Taylor --- You must have the GNU binutils installed.
[Bug go/100537] 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 #12 from Ian Lance Taylor --- A change to go-gcc.cc should not change any of the error messages emitted by the Go frontend. It should not change the way that issue4458.go is handled. Those errors messages are emitted long before any of the code in go-gcc.cc is called. I'm not sure what is happening.
[Bug go/100537] 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 #16 from Ian Lance Taylor --- I have a patch for this.
[Bug go/100537] 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 Ian Lance Taylor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Ian Lance Taylor --- Should be fixed.
[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 --- Comment #1 from Ian Lance Taylor --- Yes, runtime.inc is a generated file. Can you post the lines around the errors? These look like fields in a struct type, and I'd like to know which type it is. 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 --- Comment #3 from Ian Lance Taylor --- Thanks, but I am hoping to see not the build log, but rather the contents of the generated file TARGET/libgo/runtime.inc, around lines 1357 and 1360. Thanks.
[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 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 #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 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 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 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 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 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/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/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 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&action=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 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/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/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/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/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/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 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 &GOTMP.5 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 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 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 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 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 #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 #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/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/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/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 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/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 go/103847] gccgo SIGSEGV in libgo standard library on sparc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847 --- Comment #4 from Ian Lance Taylor --- There don't seem to be any sparc64-linux machines in the GCC compile farm, so I can't recreate this myself. Are you able to recreate the problem while running under gdb? A backtrace from the point of the signal might help. The stack backtraces you included unfortunately don't tell me anything useful. Thanks.
[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847 --- Comment #6 from Ian Lance Taylor --- I can try debugging it with ssh access. I'll want to build my own copy of gccgo. Let me know where I should send the public key. Thanks.
[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #9 from Ian Lance Taylor --- This should be fixed on tip. Thanks for reporting it.
[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.
[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/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 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/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/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 c++/77950] GCC produces un-demanglable symbols with [] (auto&) { ... } lambdas in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77950
--- Comment #2 from Ian Lance Taylor ---
Just a note that my Go demangler does demangle this symbol now, producing
ossia::vec_merger_impl<2>::operator() > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >
>(eggs::variants::variant > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >
const&)::{lambda(auto:1&)#1}&&
eggs::variants::detail::forward::operator() > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >
>(eggs::variants::variant > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >
const&)::{lambda(auto:1&)#1}&&>(std::remove_reference::operator() > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >
>(eggs::variants::variant > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >
const&)::{lambda(auto:1&)#1}&&>::type&)
[Bug go/102102] [12 Regression] trunk 20210827 ftbfs libgo on x86_64-linux-gnux32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102102 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Ian Lance Taylor --- Should be fixed now, I hope. I don't know how to test this, as my desktop does not support x32 mode.
[Bug go/101994] go1: internal compiler error: in return_statement, at go/go-gcc.cc:2318
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101994 Ian Lance Taylor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Ian Lance Taylor --- Fixed on tip.
[Bug tree-optimization/102474] New: [12 regression] Crash in ipa-modref compiling Go code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102474
Bug ID: 102474
Summary: [12 regression] Crash in ipa-modref compiling Go code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
Target Milestone: ---
Compiling this Go program with -O1 -fno-strict-aliasing crashes the compiler in
ipa-modref.
package p
type S struct {
f1 string
f2 interface{}
f3 string
f4 struct {
f41 uint32
f42 struct {
f421 int32
f422 uint32
}
}
f5 struct {
f51 *byte
f52 *byte
f53 *byte
}
f6 struct {
f61 int32
}
f7 struct {
f71 uint64
f72 int64
f73 *byte
}
f8 *byte
}
The crash I see is:
during IPA pass: modref
go1: internal compiler error: in forced_merge, at ipa-modref-tree.h:351
0xcbaff1 modref_access_node::forced_merge(modref_access_node const&, bool)
../../trunk/gcc/ipa-modref-tree.h:351
0xcbe389 modref_ref_node::insert_access(modref_access_node, unsigned long,
bool)
../../trunk/gcc/ipa-modref-tree.h:575
0xcbe8e3 modref_tree::insert(int, int, modref_access_node, bool)
../../trunk/gcc/ipa-modref-tree.h:844
0xcb65de propagate_unknown_call
../../trunk/gcc/ipa-modref.c:3418
0xcb6a69 modref_propagate_in_scc
../../trunk/gcc/ipa-modref.c:3598
0xcb740e execute
../../trunk/gcc/ipa-modref.c:3968
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug ipa/102474] [12 regression] Crash in ipa-modref compiling Go code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102474 --- Comment #2 from Ian Lance Taylor --- I did a git bisect, and it reported that the problem was introduced by commit f5ff3a8ed4ca91737c16757ce4938cf2e0187fc0 Author: Jan Hubicka Date: Sat Aug 28 20:57:08 2021 +0200 Improve handling of table overflows in modref_ref_node gcc/ChangeLog: * ipa-modref-tree.h (modref_access_node::merge): Break out logic combining offsets and logic merging ranges to ... (modref_access_node::combined_offsets): ... here (modref_access_node::update2): ... here (modref_access_node::closer_pair_p): New member function. (modref_access_node::forced_merge): New member function. (modre_ref_node::insert): Do merging when table is full. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/modref-9.c: New test.
[Bug ipa/102474] [12 regression] Crash in ipa-modref compiling Go code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102474 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #4 from Ian Lance Taylor --- This was fixed by the fix for PR 102581. *** This bug has been marked as a duplicate of bug 102581 ***
[Bug ipa/102581] [12 Regression] ice in forced_merge, at ipa-modref-tree.h:352 with -fno-strict-aliasing and -O2 since r12-3202-gf5ff3a8ed4ca9173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102581 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #11 from Ian Lance Taylor --- *** Bug 102474 has been marked as a duplicate of this bug. ***
[Bug libbacktrace/103011] fatal error: process.h: No such file or directory when canadian compile x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103011 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #4 from Ian Lance Taylor --- I think you are misreading the make output slightly due to the use of the -j option. pex-unix.c is not built as part of libbacktrace. The build is failing while building build-libiberty. Changing the component.
[Bug other/103011] fatal error: process.h: No such file or directory when canadian compile x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103011 --- Comment #5 from Ian Lance Taylor --- Can you add some output from make without the -j option? I don't understand how this error is possible.
[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/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/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/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 #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 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 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 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Ian Lance Taylor --- Should be fixed on mainline. Thanks.
[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 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 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/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 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 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&action=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 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 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.
