https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98818
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
Statu
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=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=97550
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #1 fr
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=98153
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97227
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
Statu
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=98402
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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
Statu
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 p
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=98510
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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=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)
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
CC||ian at airs dot com
--- Comment #5 fr
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: U
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=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 #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=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 #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=
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 n
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
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=99267
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNCONFI
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 an
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=100537
Ian Lance Taylor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=108426
--- Comment #4 from Ian Lance Taylor ---
Thanks Andrew, I'm testing the patch myself, but go ahead and commit if you are
satisfied with it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
--- Comment #9 from Ian Lance Taylor ---
I agree that if the middle-end is going to generate calls to builtin functions,
it would be nice if the middle-end provided a function to call to define those
functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108534
--- Comment #2 from Ian Lance Taylor ---
Yes, it's a relative path, such as
#line 1 "cgo-gcc-prolog"
These are dummy but informative line markers used to separate generated code
from user-written code, so that compiler error messages repor
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 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
--- Comment #33 from Ian Lance Taylor ---
As far as I know nothing is waiting on me. Please let me know if you think
otherwise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=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=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 Makefil
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
expl
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=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 code
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
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=105091
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #8 f
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=105240
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #3 f
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=105302
--- Comment #4 from Ian Lance Taylor ---
> What exactly would be the file(s) being opened in this case?
The file that should be opened is the file internal/cpu.gox in the libgo build
directory.
> When can we expect the libgo cleanup needed for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302
--- Comment #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 huma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105315
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=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=106747
Ian Lance Taylor changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106949
--- Comment #3 from Ian Lance Taylor ---
I don't think your attached patch is going to work. The code assumes that it
is running within a stack segment. You can't just add a stack segment without
changing the stack pointer.
But something like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107203
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRM
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 th
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=103847
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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=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 wh
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=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. The
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=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::stron
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=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
Comp
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102474
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNE
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=103011
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #4 f
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 #44 from Ian Lance Taylor ---
gccgo still does not work 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491
--- Comment #3 from Ian Lance Taylor ---
The stack size on a system that does not support -fsplit-stack is set by
StackMin in libgo/runtime/stack.c. There is currently no way to override the
default value of 4MB, but we could probably add one b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491
--- Comment #5 from Ian Lance Taylor ---
Good point, I did forget about using gold or lld. Sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491
--- Comment #7 from Ian Lance Taylor ---
If we use an environment variable, we should probably use the existing GODEBUG
variable.
Making the stack headroom large enough all the time should be possible. It
will burn a lot of memory on stacks bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581
--- Comment #7 from Ian Lance Taylor ---
Interesting, thanks. The Go frontend will never emit a call to
__atomic_fetch_add_4. I didn't realize that the middle end could convert
__atomic_add_fetch_4 into that. Your patch looks right. I'll com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491
--- Comment #9 from Ian Lance Taylor ---
I would suggest adding a new field to the GODEBUG parsing in
go/runtime/runtime1.go and then calling a new C function defined in
libgo/runtime/proc.c to store the value in a C static variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107992
--- Comment #1 from Ian Lance Taylor ---
Thanks. This is happening because the data structures that Go's garbage
collector uses require that all pointers be aligned on their natural
boundaries. Unfortunately m68k only provides 2-byte alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108072
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108057
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297
--- Comment #3 from Ian Lance Taylor ---
Created attachment 54196
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54196&action=edit
Potential patch
Does this patch fix the problem for you? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
1 - 100 of 178 matches
Mail list logo
