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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97227
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98153
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98041
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98402
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98510
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98493
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
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
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
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
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
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.
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98716
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98493
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98610
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537
Ian Lance Taylor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537
--- Comment #16 from Ian Lance Taylor ---
I have a patch for this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101064
--- Comment #4 from Ian Lance Taylor ---
Created attachment 51086
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51086=edit
C test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101064
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101064
--- Comment #5 from Ian Lance Taylor ---
I have attached a C test case that demonstrates the problem. The C case may be
somewhat worse because I had to use ordinary variables, whereas the Go test
case is used compiler-generated temporary
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.
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.
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:
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99553
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99267
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |WORKSFORME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98818
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99458
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99164
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95389
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101994
Ian Lance Taylor changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102102
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101994
Ian Lance Taylor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101753
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101851
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102474
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
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
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
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 > >,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
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
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.
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #42 from Ian Lance Taylor ---
No, the go-macho package is irrelevant here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101246
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104832
--- Comment #2 from Ian Lance Taylor ---
I just committed 2858e2afcb0a6553a222e724d8426451364ee755 which should fix the
specific problem in fmt.gox.
Let me know if you still see problems here. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104832
--- Comment #4 from Ian Lance Taylor ---
Can you show the differences in one or two of the files, as you did before?
Thanks.
ASLR could be a factor, but only in the sense that it would make it more likely
to reveal a bug in the code. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104973
--- Comment #2 from Ian Lance Taylor ---
Your build log shows a line like this:
libtool: compile:
/var/tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/build/./gcc/gccgo
-B/var/tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/build/./gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537
--- Comment #20 from Ian Lance Taylor ---
There's no perfect way to handle the MERGE file on the release branches. What
I usually do is to resolve the patch by replacing the existing revision number
with the new one. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
--- Comment #27 from Ian Lance Taylor ---
Thanks for the explanation. Sounds like you should send the config/gnu.h patch
to the x86 maintainers (and CC gcc-patches).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
--- Comment #22 from Ian Lance Taylor ---
Thanks. I'll commit your patches #1 through #8.
Your patch #9 is to a generated file. The fix there can't be to patch just the
top-level Makefile.in. It has to be to patch whatever is causing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
--- Comment #25 from Ian Lance Taylor ---
> Hopefully someone knows hot to modify Makefile.tpl/Makefile.def to generate
> the correct dependencies in Makefile.in.
I suggest that you open a separate bug for that, with a complete standalone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103573
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
--- Comment #21 from Ian Lance Taylor ---
*** Bug 103573 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #17 from Ian Lance Taylor ---
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
--- Comment #5 from Ian Lance Taylor ---
> The only issue to resolve is how to make sure libatomic and libbacktrace
> builds in build/i686-gnu before libgo/gotools.
That question doesn't sound right. The gotools are built for the target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98504
--- Comment #12 from Ian Lance Taylor ---
You can pass the -I option to tell the compiler where to find the fmt.gox file.
But, of course, you shouldn't have to. A "make install" should put fmt.gox in
the right place by default. I don't know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104149
--- Comment #2 from Ian Lance Taylor ---
We probably just need to add amd64p32 to the go:build and +build lines in
libgo/go/runtime/panic32.go. But I don't have a way to test that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104149
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77780
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105240
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111310
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
--- Comment #7 from Ian Lance Taylor ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635073.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
--- Comment #11 from Ian Lance Taylor ---
vincenzo: the patch in the linked e-mail is the complete diff. There are no
changes to generated Makefile.in files.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112396
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105315
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302
--- Comment #6 from Ian Lance Taylor ---
The magic string itself is fine: it's the "v3;\n". Perhaps there is some
problem locating it in the file. Some of the relevant code is
go_read_export_data in gcc/go/go-backend.cc. Try to find out what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302
--- Comment #8 from Ian Lance Taylor ---
Thanks. Those suggested changes aren't going to make any difference as those
are text files anyhow. One is a generated C header that #include'd by C files,
and the other is a dump file intended for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104973
--- Comment #4 from Ian Lance Taylor ---
The golang.org/x/sys/cpu.o is a different object file. That one uses
gcpugen.go, not cpugen.go. The original reporter is not reporting any problems
involving gcpugen.go. The cpugen.go (not gcpugen.go)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105721
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105225
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106033
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106033
--- Comment #1 from Ian Lance Taylor ---
Created attachment 53173
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53173=edit
Potential patch
I haven't been able to recreate the problem, but does this patch fix it?
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106266
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302
--- Comment #4 from Ian Lance Taylor ---
> What exactly would be the file(s) being opened in this case?
The file that should be opened is the file internal/cpu.gox in the libgo build
directory.
> When can we expect the libgo cleanup needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302
--- Comment #2 from Ian Lance Taylor ---
I have no idea why you would get a "Permission denied" error opening an import
package.
That said I would not expect this to work. Somebody would have to clean up
libgo to support Windows.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106747
--- Comment #4 from Ian Lance Taylor ---
This is fixed on tip. Want to backport the patch to the GCC 12 branch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #46 from Ian Lance Taylor ---
A small bit of work is needed on the codegen, to read and write the export
data. And some work is required on the runtime, to clean it up to support
Darwin. It has to be done by someone with access to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #44 from Ian Lance Taylor ---
gccgo still does not work on Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106747
Ian Lance Taylor changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107203
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |WONTFIX
1 - 100 of 157 matches
Mail list logo
