https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #11 from Ian Lance Taylor ---
Sorry, I've gotten confused. Can you attach one single patch from trunk?
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88060
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88060
--- Comment #6 from Ian Lance Taylor ---
Which version of glibc are you running on your system? Which Linux kernel
version?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88060
--- Comment #1 from Ian Lance Taylor ---
Can you attach the contents of sparc-unknown-linux-gnu/libgo/gen-sysinfo.go
from your build directory?
Does the C header file on your system define AT_FDCWD? (It normally
comes from .) If not, why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88011
--- Comment #12 from Ian Lance Taylor ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88011
Ian Lance Taylor changed:
What|Removed |Added
Attachment #45013|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88011
--- Comment #7 from Ian Lance Taylor ---
Created attachment 45018
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45018=edit
Standalone test case
Here is somewhat smaller standalone test case. Looking at assembly
differences, it looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88011
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87470
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88002
--- Comment #1 from Ian Lance Taylor ---
I really have no intention of running the libbacktrace tests under DejaGNU.
But if someone wants to copy the .sum file generation out of libgo (which also
does not use DejaGNU), that would be fine with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82857
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87661
Ian Lance Taylor changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87722
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87661
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87653
--- Comment #1 from Ian Lance Taylor ---
Created attachment 44860
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44860=edit
Possible patch
I can't recreate the problem. Your test program runs fine on my system, once I
add a main function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87529
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87529
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87260
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87260
--- Comment #1 from Ian Lance Taylor ---
Created attachment 44673
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44673=edit
Possible patch
Does this patch fix the problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87182
--- Comment #6 from Ian Lance Taylor ---
In my testing I don't see any reference to -lz in libbacktrace.la.
It is not the case that using
AC_CHECK_LIB([z], [compress],
[AC_DEFINE(HAVE_ZLIB, 1, [Define if -lz is available.])])
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87182
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #11 from Ian Lance Taylor ---
Sorry, you're right, it's -fdump-go-spec.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #9 from Ian Lance Taylor ---
I haven't tried to recreate the problem on FreeBSD. I've just tried various
inputs to GCC 7 -fgo-dump-spec.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #7 from Ian Lance Taylor ---
Thanks. There seems to be something with -fgo-dump-spec on your system, such
that it fails if an incomplete typedef is seen before a complete typedef. I'm
not sure why that would be. I haven't been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #5 from Ian Lance Taylor ---
Thanks. Unfortunately I don't know why this is failing.
Does it help if you edit the file libgo/sysinfo.c to move
#include
ahead of
#include
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #3 from Ian Lance Taylor ---
Thanks for providing the gen-sysinfo.go file. I see that cmsghdr is defined in
that file. Several function declarations use it. It even has a size of 12
bytes. It's just missing a definition. So I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #1 from Ian Lance Taylor ---
Can you attach a copy of the generated file gen-sysinfo.go?
What does the definition of, say, cmsghdr look like in (or some
header file included by that one)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331
Ian Lance Taylor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331
--- Comment #10 from Ian Lance Taylor ---
Thanks. The documentation for the syscall function say that it only sets errno
on failure, but I forgot about signal handlers. That is definitely a problem.
Since there is no generic way to detect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331
--- Comment #7 from Ian Lance Taylor ---
To be clear, the problem is not that the go tool is failing to find its
subcommands. The problem is that the go tool thinks that the waitid system
call is returning an error. However, the strace shows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331
--- Comment #6 from Ian Lance Taylor ---
Thanks for the strace output.
The stat(NULL) is coming from libgo/runtime/go-caller.c in the function
__go_get_backtrace_state. It's a bug, but it's a different bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86343
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86289
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86289
--- Comment #2 from Ian Lance Taylor ---
I think there is a real problem here. Filed https://golang.org/issue/26066.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86213
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86198
--- Comment #3 from Ian Lance Taylor ---
I don't a reason to change the test to ==. I don't see what would be helped by
that. Note that Richi already approved the change to <=.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86198
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85629
--- Comment #4 from Ian Lance Taylor ---
Thanks. Which version of which linker are you running? For that matter, which
version of which assembler? I don't see the warnings and errors that you are
seeing, with GNU as 2.30 and GNU gold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85630
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85629
--- Comment #2 from Ian Lance Taylor ---
What are the contents of gotools/cmd_vet-testlog?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85429
--- Comment #9 from Ian Lance Taylor ---
I suppose if worst comes to worst we can try it both ways.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85429
--- Comment #7 from Ian Lance Taylor ---
Do you think you could work out a patch that handles the various different
cases?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85429
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85429
--- Comment #1 from Ian Lance Taylor ---
Does the SPARC Solaris assembler support a syntax like
.section ".go.buildid",#exclude
? That's what gas seems to support for compatibility.
Does that syntax work for x86?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84948
--- Comment #1 from Ian Lance Taylor ---
That is just the start of the problem. The garbage collector assumes that all
pointers are aligned to their natural boundary. That is, it expects that on a
system with four byte pointers, they are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85024
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84765
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84215
--- Comment #11 from Ian Lance Taylor ---
Please include all the output from each failure, if possible. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84439
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484
--- Comment #15 from Ian Lance Taylor ---
> The first hunk is useless since this is a compile test.
Understood, but I would prefer to test the exact options that the build is
going to use.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484
--- Comment #12 from Ian Lance Taylor ---
How about this patch?
diff --git a/libgo/configure b/libgo/configure
index aba4dc39..dcfc524b 100755
--- a/libgo/configure
+++ b/libgo/configure
@@ -14209,7 +14209,7 @@ if test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484
--- Comment #10 from Ian Lance Taylor ---
In what way does it fail? The final link of libgo is always done against
../libatomic/libatomic.la.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484
--- Comment #8 from Ian Lance Taylor ---
Odd. In any case, the patch is simple:
diff --git a/libgo/configure b/libgo/configure
index aba4dc39..1b61c9ba 100755
--- a/libgo/configure
+++ b/libgo/configure
@@ -14210,6 +14210,9 @@ if test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484
--- Comment #6 from Ian Lance Taylor ---
Give me a hint: what doesn't work?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484
--- Comment #4 from Ian Lance Taylor ---
To get the change from https://golang.org/cl/95436 in the form of a patch,
click on the download link (middle of the screen on the right) then click on
one of the "patch file" links at the bottom of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484
--- Comment #1 from Ian Lance Taylor ---
Does the patch in https://golang.org/cl/95436 fix the problem?
Note that there will be other problems building libgo for riscv: it will need
to be added to goarch.sh, match.sh, and testsuite/gotest, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84215
--- Comment #7 from Ian Lance Taylor ---
I just committed a patch that may affect some of these failures. Please let me
know if you notice any change. Thanks.
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
Target Milestone: ---
With a cross-compiler from x86_64-pc-linux-gnu to powerpc64le-unknown-linux-gnu
compiling this file with -g -O2 -fsplit-stack -fno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84215
--- Comment #1 from Ian Lance Taylor ---
What do you mean by "random results?" Can you post some output? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53679
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71635
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71396
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68420
Ian Lance Taylor changed:
What|Removed |Added
Status|SUSPENDED |RESOLVED
Resolution|---
||ian at airs dot com
Resolution|--- |FIXED
--- Comment #2 from Ian Lance Taylor ---
Should be fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83992
--- Comment #6 from Ian Lance Taylor ---
In this case the problem happens before the assembler. The bad location
information shows up in reemit_insn_block_notes in gcc/final.c. As the first
insn in the block has no location,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83992
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83992
--- Comment #1 from Ian Lance Taylor ---
In the 147t.cddce2 dump (as dumped with -fdump-tree-all-lineno) I see this:
[local count: 1063004407]:
# j_8 = PHI <[foo.go:6:7] 0(3), [foo.go:6:31] j_5(6)>
# DEBUG j => j_8
[foo.go:6:31] j_5 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83787
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83794
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Ian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
--- Comment #20 from Ian Lance Taylor ---
This will be in GCC 8.
Backports to GCC 7 are fine with me but I'm not going to do them myself.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
--- Comment #18 from Ian Lance Taylor ---
OK, the SH support patch is committed, and the exp directory has been removed.
Is there anything else to do here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
--- Comment #17 from Ian Lance Taylor ---
Actually we should just drop the libgo/go/exp directory. I don't know why it's
still there. It should have been dropped years ago.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
--- Comment #11 from Ian Lance Taylor ---
As far as I know libbacktrace and libgo use the same criteria for whether they
are built or not. Why is libbacktrace not being built for m4-fpu? What is
preventing that build from occurring?
What is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
--- Comment #7 from Ian Lance Taylor ---
Sorry, I did not mean to imply that I listed all the changes required. I'm
sure there will be many more, though likely mostly simple.
For the ones you mention, you'll need to add "sh" to the +build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83314
--- Comment #3 from Ian Lance Taylor ---
Ah, of course. Thanks. In that case mmap is being called with a descriptor
that is the executable itself, as opened by fileline_initialize in
libbacktrace/fileline.c. I wonder why mmap fails on that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83314
--- Comment #1 from Ian Lance Taylor ---
errno 9 is EBADF, which doesn't make much sense since libgo only ever calls
mmap with MAP_ANONYMOUS. And I'm not even sure where those messages are coming
from. I don't see any place where the GCC 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
--- Comment #4 from Ian Lance Taylor ---
gccgo does work on a number of targets that do not have split stack support.
The downsides are that each goroutine has a much larger stack, and if you have
too much recursion you can run out of stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
--- Comment #2 from Ian Lance Taylor ---
I suspect you'll need other changes as well, such as a new file
libgo/go/internal/syscall/unix/getrandom_linux_sh.go. For that matter you'll
need to add sh to libgo/go/go/build/syslist.go and to match.sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83222
Ian Lance Taylor changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
Severity: critical
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
Target Milestone: ---
The handling of this C program recently changed:
const char _expA = 0x42;
void __cgo_f_1_4(void) { static const double x = (dou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83102
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83071
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83071
--- Comment #1 from Ian Lance Taylor ---
This is of course a compiler bug, but it's a crash on invalid code. You can't
write `input++` when `input` is a string type. In Go the `++` operator only
applies to integer types. When I fix the
at airs dot com|unassigned at gcc dot
gnu.org
--- Comment #1 from Ian Lance Taylor ---
Yes, Go works on Solaris/SPARC. This is not a Go bug, as the file
gcc/go/parse.o is compiled from C++ code, not Go code. At the point in the
build where this error occurs, no Go code has been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82559
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82544
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82544
--- Comment #4 from Ian Lance Taylor ---
The call to abort makes this seem more like a problem in the unwind code in
libgcc than a problem with the Go compiler. Can you find out exactly what code
in uw_context_1 is calling abort? Try running
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914
--- Comment #10 from Ian Lance Taylor ---
I can't recreate the problem. I did the same commands in
github.com/twstrike/ed448 and they worked for me.
Using `go test -c -gccgoflags -Wl,--compress-debug-sections=zlib` to generate
an executable,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914
--- Comment #8 from Ian Lance Taylor ---
Which version of GCC are you using in comment #7?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82368
--- Comment #3 from Ian Lance Taylor ---
Andrey: do you have more details? I don't see how this change, which does not
affect the generated code in any way, could possibly cause a SPEC failure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82348
--- Comment #8 from Ian Lance Taylor ---
If the re-generated math.lo.dep file does not refer to internal/cpu.gox, then
something went wrong the first time the file was generated. Try simply
removing your TARGET/libgo directory and building from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82348
--- Comment #6 from Ian Lance Taylor ---
The bug is that something is requiring internal/cpu.gox. Nothing should
require it.
There is only one mention of internal/cpu in the math package, in the
floor_asm.go file, but that file has a build tag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82368
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82131
--- Comment #2 from Ian Lance Taylor ---
I have not been able to create this.
Are you using GNU ld or the gold linker? I've tried both and for me it works
either way, but it might help to know.
Can you find out why it is getting a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82348
--- Comment #4 from Ian Lance Taylor ---
My apologies for jumping to conclusions.
If you are building from trunk there should not be any references to
internal/cpu.gox. What does your TARGET/libgo/math.lo.dep file look like?
301 - 400 of 1593 matches
Mail list logo
