https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93468
Ian Lance Taylor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93468
--- Comment #4 from Ian Lance Taylor ---
You've given me less than 48 hours before asking why this takes such a long
time. I am extremely busy. Please be patient. I will get to this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90918
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463
Ian Lance Taylor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93020
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92861
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92861
--- Comment #5 from Ian Lance Taylor ---
You can also just send patches to gcc-patc...@gcc.gnu.org and/or
gofrontend-...@googlegroups.com.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92866
--- Comment #1 from Ian Lance Taylor ---
This doesn't look like a Go problem, it looks like a backend problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92861
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92842
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92820
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92810
--- Comment #2 from Ian Lance Taylor ---
The configure script should work now, but I don't know what other problems you
will encounter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92820
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92820
--- Comment #3 from Ian Lance Taylor ---
What architectures do you see it on? Do we just need to move the
.section.note.GNU-stack,"",@progbits
in runtime/go-context.S out of the #ifdef?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92605
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91992
--- Comment #6 from Ian Lance Taylor ---
I thought the DejaGNU framework provided a default timeout for program
execution. I'm not sure why that wouldn't kick in here. The code in
go-test.exp is running the program via go-torture-execute.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88745
--- Comment #9 from Ian Lance Taylor ---
filetype.awk will be run on a program compiled by the target compiler, so it
should get the correct result.
I agree that the endianness shouldn't matter with regard to the code, although
of course
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88745
--- Comment #7 from Ian Lance Taylor ---
We are using yet another object file reader because libbacktrace is designed to
run correctly when invoked by a signal handler, so it cannot use ordinary
memory allocation.
libbacktrace is only used when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88745
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91992
--- Comment #2 from Ian Lance Taylor ---
Created attachment 46996
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46996=edit
index0-out.go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91992
--- Comment #3 from Ian Lance Taylor ---
I don't know what is happening here.
The way this test works is that the file gcc/testsuite/go.test/test/index.go
and gcc/testsuite/go.test/test/index0.go are compiled together, producing a
file
||ian at airs dot com
Resolution|--- |FIXED
--- Comment #2 from Ian Lance Taylor ---
Should be fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91763
--- Comment #7 from Ian Lance Taylor ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91763
--- Comment #2 from Ian Lance Taylor ---
I see now the fact that we are using exceptions is already being passed. The
problem seems to be that flag_exceptions is set when we read an exception
region from an input function, by lto_init_eh. But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91763
--- Comment #1 from Ian Lance Taylor ---
I can recreate this on sparc-sun-solaris2.11 using gas.2.30. It works using
the native assembler. I'm using the native linker.
It works if I #ifdef out these lines in lto-opts.c:
#if 0
/* If debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91781
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91781
--- Comment #2 from Ian Lance Taylor ---
Oh, never mind, this is a new test in r275691, this code has probably never
worked on ppc64be.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91781
--- Comment #1 from Ian Lance Taylor ---
Does this work at SVN revision r275611?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91764
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91700
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91712
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91621
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91692
--- Comment #2 from Ian Lance Taylor ---
Thanks for the bug report. The normal case when configuring GCC is to create a
new empty directory and run SRCDIR/configure in that directory, as documented
at https://gcc.gnu.org/install/configure.html.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
Target Milestone: ---
Test case (this is C code converted from a Go program):
extern void exit (int) __attribute ((__noreturn__));
struct s
{
int f1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91617
--- Comment #3 from Ian Lance Taylor ---
To see how to run libgo tests, see the Debugging section in libgo/README.
The problem you are having with runtime.osinit looks related to a recent libgo
patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91617
--- Comment #1 from Ian Lance Taylor ---
The cited revision was not to libgo, so my assumption is that there was
something wrong with it and there is nothing to change in the Go frontend. Let
me know if I'm mistaken.
This was also filed as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035
--- Comment #5 from Ian Lance Taylor ---
It's hard to see how this could be a bug in the Go frontend. At first glance
this looks like a problem with the split-stack support on S/390.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #25 from Ian Lance Taylor ---
The code in os_freebsd.go is written for the gc toolchain. You'll need to look
at it and see whether it makes sense for gccgo.
That said, that call to sysctl does seem to make sense. You'll need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #23 from Ian Lance Taylor ---
Look for _kern in runtime.inc. See what struct it is part of. The struct is
likely defined in the generated file runtime_sysinfo.go. You may need to
modify libgo/mkrsysinfo.sh to not add that struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91172
--- Comment #2 from Ian Lance Taylor ---
That is the function (*Package).gccDebug, which on GCC 7 branch starts on line
1262 of libgo/go/cmd/cgo/gcc.go.
Like Richard I don't understand how you could get that warning. -Wreturn-type
is a C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035
--- Comment #1 from Ian Lance Taylor ---
As far as I know I don't have access to an S/390 system. Anything you can do
to narrow down the problem would be helpful. Like, for example, which function
has the undefined reference?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90685
--- Comment #1 from Ian Lance Taylor ---
What kind of system are you running on?
What is the output of
../gcc-9.1.0/config.guess
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90665
--- Comment #3 from Ian Lance Taylor ---
Building with GCC is fine, and your configure options look fine.
Please attach the output of
go build -x ./...
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90665
--- Comment #1 from Ian Lance Taylor ---
I built gccgo on a SPARC Solaris 12 machine, but was unable to recreate the
problem. For me your program built and ran fine.
Please attach the output of
go build -x ./...
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90645
--- Comment #7 from Ian Lance Taylor ---
Among the requirements for gccgo is support for Thread Local Storage. If your
system does not support that, gccgo cannot work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90669
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90645
--- Comment #3 from Ian Lance Taylor ---
Did libgo ever work on this system? I can't remember. I don't see how we can
work around a missing __tls_get_addr symbol. That suggests that the system
does not support Thread Local Storage.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90635
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90614
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
||2019-05-26
CC||ian at airs dot com
Ever confirmed|0 |1
--- Comment #3 from Ian Lance Taylor ---
I do see a failure when I run the program. For me the error is happening when
running the global constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #19 from Ian Lance Taylor ---
People build the gofrontend all the time on GNU/Linux systems. I don't know if
anyone has successful built it on a FreeBSD system.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90636
--- Comment #1 from Ian Lance Taylor ---
Try changing to the libbacktrace build directory, removing edtest.o, and
running "make edtest". Presumably then running "./edtest" will fail with the
"missing file name or function name" error. Paste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88406
--- Comment #4 from Ian Lance Taylor ---
Is this still worth investigating given that we've dropped support for Solaris
10?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482
--- Comment #4 from Ian Lance Taylor ---
What is different about 32-bit SPARC is not that it treats pointers and
integers differently, but that
struct { void *p; }
and
void *p;
are passed as arguments in two different ways. The former is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56113
--- Comment #38 from Ian Lance Taylor ---
Ah, sorry, misunderstood.
Yes, that work was all for the goal of implementing -Wjump-misses-init, which
is a small aspect of -Wc++-compat. That was part of the work of getting GCC to
use the common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56113
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90272
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90272
--- Comment #1 from Ian Lance Taylor ---
Thanks. To be clear, while of course the compiler should not crash, this is
not a valid Go program.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #9 from Ian Lance Taylor ---
> I think the *end != '\0' check is the problem here. The temporary object is
> gone at that point.
Ah ha. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #7 from Ian Lance Taylor ---
> What is the condition i > 0x7fff for? Shouldn't that test val instead?
Yes, it certainly should. Thanks. It's not the problem here, but should be
fixed.
> Just a wild guess - does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #4 from Ian Lance Taylor ---
Thanks for the file. Unfortunately it looks fine.
The error is coming from Import_function_body::read_type in
gcc/go/gofrontend/import.cc. At the point of the error this->body_ +
this->off_ points to a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90116
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #1 from Ian Lance Taylor ---
The pathnames suggest that this is the -m32 build.
Can you attach the file TARGET/32/libgo/math.gox?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89669
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89447
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89406
Ian Lance Taylor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89227
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88406
--- Comment #1 from Ian Lance Taylor ---
I don't seem to have access to a SPARC Solaris 10 box.
It seems like Solaris 10 is ignoring the address argument passed to mmap. Does
Solaris have an equivalent of strace that will show system calls?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89598
Ian Lance Taylor changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89598
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89406
--- Comment #13 from Ian Lance Taylor ---
I increased the timeouts and fixed another case. Let me know what it looks
like now. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89406
--- Comment #10 from Ian Lance Taylor ---
Thanks. In both cases the tests were killed because they ran too long (the
timeout was 11 minutes). Since the tests were killed, they didn't clean up
after themselves.
Can you cd to the gotools
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89406
--- Comment #7 from Ian Lance Taylor ---
Can you attach the file gotools/cmd_go-testlog from your build directory?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89172
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89406
Ian Lance Taylor changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #15 from Ian Lance Taylor ---
I committed a patch that should fix the nanotime problem.
Some of the other issues you describe will most likely require a fix in the
libgo/mkrsysinfo.sh script, which generates the file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89171
--- Comment #4 from Ian Lance Taylor ---
To run, say, just the go/build test, cd to the libgo build directory and run
"make go/build/check". To keep the test binary around, run "make
GOTESTFLAGS=--keep go/build/check". That will leave the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89406
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89170
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89407
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89170
--- Comment #1 from Ian Lance Taylor ---
I think this is due to an old bug in const_desc_htab. output_constant_def will
insert a value into const_desc_htab. If the hash table already has an entry
with the same hash value, this will cause the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89169
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123
Ian Lance Taylor changed:
What|Removed |Added
CC||doko at debian dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89277
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89171
--- Comment #1 from Ian Lance Taylor ---
I don't know what is happening here and I don't have access to a riscv64
machine to test on (there doesn't seem to be one in the compile farm). The
errors are incorrect in that these are not expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89368
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123
--- Comment #14 from Ian Lance Taylor ---
OK, patch committed. Should we leave this bug report open?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123
--- Comment #12 from Ian Lance Taylor ---
Sorry for the delay, will look at the patch now.
You can test a single target libgo target by using make to build the /check
target. For example, to test the bytes package, cd to the libgo build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89168
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89321
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89321
--- Comment #6 from Ian Lance Taylor ---
Thanks very much for reducing the test case.
I sent out the fix for review at https://golang.org/cl/162618. It should be
committed shortly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89193
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89321
--- Comment #3 from Ian Lance Taylor ---
I'm not sure exactly what assert it is, because there is no assert on that line
of go-gcc.cc. But it is most likely an assertion saying that when compiling a
struct composite literal, the number of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89321
--- Comment #1 from Ian Lance Taylor ---
In order to fix this problem I will most likely need some way to reproduce it.
Can you share a cut down version of the source code that triggers the problem?
Do you happen to know if the problem occurs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81983
--- Comment #5 from Ian Lance Taylor ---
I would be inclined to just skip the bsearch when the count is zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60240
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78063
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89199
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
201 - 300 of 1609 matches
Mail list logo
