[Bug go/88406] [9/10 regression] Many 64-bit Solaris 10/SPARC execution tests FAIL

2019-05-17 Thread ian at airs dot com
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?

[Bug go/90482] [10 regression] Many 32-bit Solaris/SPARC tests FAIL with SIGBUS

2019-05-17 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Ian Lance Taylor  ---
I verified that tests now passed on 32-bit SPARC.

[Bug go/90482] [10 regression] Many 32-bit Solaris/SPARC tests FAIL with SIGBUS

2019-05-17 Thread ian at airs dot com
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 passed by
invisible reference and the latter is passed directly.  On many platforms they
are passed as arguments in exactly the same way.

[Bug c/56113] out of memory when compiling a function with many goto labels (50k > )

2019-05-10 Thread ian at airs dot com
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 subset of C and C++ before we switched to C++.

(It's also used for the error of jumping into the scope of a variably modified
type.)

[Bug c/56113] out of memory when compiling a function with many goto labels (50k > )

2019-05-09 Thread ian at airs dot com
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 from Ian Lance Taylor  ---
Different Ian, but I'm not sure which one -- ILT

[Bug go/90272] internal compile error with full backtrace

2019-04-29 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90272

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Fixed on trunk by revision 270658.

[Bug go/90272] internal compile error with full backtrace

2019-04-29 Thread ian at airs dot com
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.

[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19

2019-04-17 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Ian Lance Taylor  ---
Fixed, I hope.

[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19

2019-04-17 Thread ian at airs dot com
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.

[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19

2019-04-17 Thread ian at airs dot com
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 this->body_.substr(start, i - start).c_str() 
really live until after strtol has completed?

I *think* it should be OK.  The rule in C++ is that temporary objects are
destroyed after the full expression that lexically contains the point at which
they are created has been evaluated.  In this case the full expression is the
call to strtol, so the temporary object created by the call to substr should
live until the call to strtol is complete.

[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19

2019-04-17 Thread ian at airs dot com
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 string starting with ",".  The function starts
like this:

  this->require_c_string("off_;
  size_t i;
  int c = '\0';
  for (i = start; i < this->body_.length(); ++i)
{
  c = static_cast(this->body_[i]);
  if (c != '-' && (c < '0' || c > '9'))
break;
}
  this->off_ = i + 1;

  char *end;
  long val = strtol(this->body_.substr(start, i - start).c_str(), , 10);
  if (*end != '\0' || i > 0x7fff)
{
  if (!this->saw_error_)
go_error_at(this->location(),
"invalid export data for %qs: expected integer at %lu",
this->name().c_str(),
static_cast(start));
  this->saw_error_ = true;
  return Type::make_error_type();
}

It skips ",".  It steps past the "4". 
Then it passes "4\0" to strtol.  Somehow that is failing.

Since, needless to say, I can't reproduce the problem, do you have time to add
a bit of debugging around the strtol call, to see what is being passed and
returned?

[Bug go/90116] Segmentation fault and what appears to be an implementation error in gofrontend (parse.cc)

2019-04-16 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90116

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
I can recreate the compiler crash with GCC 8 branch, but it is fixed on trunk. 
On trunk I get

foo.go:3:7: error: array bound is not constant
3 | var A[A] A
  |   ^
foo.go:3:7: error: expected type

Your second case is not a bug.  The Go language specification expresses
constraints in the text that are not expressed in the formal grammar.  In the
discussion of constant declaration, the spec says "Within a parenthesized const
declaration list the expression list may be omitted from any but the first
ConstSpec."  In your example the expression list is omitted from the first
ConstSpec, so the compiler is correct in reporting a parse error.

[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19

2019-04-16 Thread ian at airs dot com
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?

[Bug libbacktrace/89669] /usr/ccs/bin/ld: Unsatisfied symbols: backtrace_uncompress_zdebug

2019-03-11 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89669

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Should be fixed.  Thanks.

[Bug go/89447] libgo largefile support is incomplete and inconsistent

2019-03-08 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89447

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Ian Lance Taylor  ---
I've committed a version of your patch, which I hope will fix all the problems.
 Please let me know if not.

One change to your patch in particular was that we shouldn't need a C version
of __go_openat64.  It should suffice to use just __go_openat, since the C code
should call the right function anyhow.  The bug was that
libgo/go/internal/syscall/unix/at.go was referring to openat when it should
have been referring to __go_openat.

[Bug go/89406] Go testing leaves many temporary directories in /tmp around

2019-03-07 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89406

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Ian Lance Taylor  ---
I haven't heard about any more problems, so closing.

[Bug go/89227] gotools test cmd/go fails with link error "call lacks nop, can't restore toc; recompile with -fPIC"

2019-03-06 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89227

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Ian Lance Taylor  ---
Should be fixed.

[Bug go/88406] [9 regression] Many 64-bit Solaris 10/SPARC execution tests FAIL

2019-03-06 Thread ian at airs dot com
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?

[Bug go/89598] [9 Regression] go frontend fails to build against mpfr 2.4.2

2019-03-05 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89598

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Ian Lance Taylor  ---
This time for sure.

[Bug go/89598] [9 Regression] go frontend fails to build against mpfr 2.4.2

2019-03-05 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89598

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Fixed, I hope.

[Bug go/89406] Go testing leaves many temporary directories in /tmp around

2019-03-01 Thread ian at airs dot com
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.

[Bug go/89406] Go testing leaves many temporary directories in /tmp around

2019-02-27 Thread ian at airs dot com
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 directory and run "time make check-go-tool" and see
how long it takes?  Also whether it passes (the full output will go to
cmd_go-testlog)?  Thanks.

[Bug go/89406] Go testing leaves many temporary directories in /tmp around

2019-02-27 Thread ian at airs dot com
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?

[Bug go/89172] FAIL: runtime/pprof

2019-02-27 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89172

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Fixed.

[Bug go/89406] Go testing leaves many temporary directories in /tmp around

2019-02-27 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89406

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Resolution|FIXED   |---

--- Comment #5 from Ian Lance Taylor  ---
Did any of the tests fail?

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

2019-02-26 Thread ian at airs dot com
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 runtime_sysinfo.go.  For
example, that is likely the problem with _CTL_HW and _HW_PAGESIZE.

For sysctl we'll need a declaration with a //extern comment.

I'm happy to advise but I don't realistically have the time to do the work
myself.

[Bug go/89171] FAIL: go/build

2019-02-26 Thread ian at airs dot com
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 binary (and other
stuff) in the directory gotestN/test.  In that directory you can run
"LD_LIBRARY_PATH=../../.libs ./a.out -test.short".  That executable also takes
other options, like "-test.run=TestDependencies" to run just the
TestDependencies test.

[Bug go/89406] Go testing leaves many temporary directories in /tmp around

2019-02-21 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89406

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Ian Lance Taylor  ---
I don't see any more of these when testing on x86_64-pc-linux-gnu, but then I
never saw anything like /tmp/200483472.  If you still see them with current
trunk, give me details like the platform, what is in the directory, and whether
there are any failing tests.  Thanks.

[Bug go/89170] FAIL: net/http

2019-02-21 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89170

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Ian Lance Taylor  ---
Fixed.

[Bug go/89407] [9 Regression] go bootstrap failure on s390x starting with r268941

2019-02-20 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89407

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Fixed, I hope.

[Bug go/89170] FAIL: net/http

2019-02-19 Thread ian at airs dot com
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 insertion to call
compare_constant.  If the constant is an ADDR_EXPR, compare_constant will call
decode_addr_const.  If the constant is an ADDR_EXPR of a number or string,
decode_addr_const will call output_constant_def.  This recursive call to
output_constant_def will in its turn insert a value into const_desc_htab.  If
the hash table is at just the right point, that recursive call can grow the
hash table.  That will change the indexes that the outer hash table insertion
is dealing with.  The eventual result is that the outer call to
output_constant_def returns a location that holds an entirely different
constant value.  It's an unlikely chain of events, but for this particular test
case it causes a function to be called with the wrong string constant, leading
to the test failure.

[Bug go/89169] FAIL: internal/cpu

2019-02-19 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89169

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Fixed.

[Bug go/89123] Too many go test failures on s390x-linux

2019-02-15 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||doko at debian dot org

--- Comment #15 from Ian Lance Taylor  ---
*** Bug 89277 has been marked as a duplicate of this bug. ***

[Bug go/89277] [9 Regression] libgo memory hogs in libgo testsuite (at least on s390x-linux-gnu)

2019-02-15 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89277

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Ian Lance Taylor  ---
Closing as a duplicate per earlier comment.  Please comment if you disagree.

*** This bug has been marked as a duplicate of bug 89123 ***

[Bug go/89171] FAIL: go/build

2019-02-15 Thread ian at airs dot com
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 dependencies, not
unexpected ones.  This may be a bug in the generation of top level composite
literals, though I can't think of any reason that would be specific to riscv64,
and of course it is working on other systems.

Do you have any suggestions for how I could debug this?

[Bug go/89368] [9 regression] ICE in go/gofrontend/expressions.cc:4669 after r268923

2019-02-15 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89368

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Thanks for the report.  Fixed.

[Bug go/89123] Too many go test failures on s390x-linux

2019-02-15 Thread ian at airs dot com
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?

[Bug go/89123] Too many go test failures on s390x-linux

2019-02-15 Thread ian at airs dot com
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
directory and run "make bytes/check".

[Bug go/89168] FAIL: cmd/go/internal/load

2019-02-14 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89168

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Fixed.

[Bug go/89321] cross build with riscv64 gccgo compilation failed due to assert in constructor_expression

2019-02-14 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89321

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Ian Lance Taylor  ---
Should be fixed.

[Bug go/89321] cross build with riscv64 gccgo compilation failed due to assert in constructor_expression

2019-02-13 Thread ian at airs dot com
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.

[Bug go/89193] "make distclean" leaves stuff in gotools/

2019-02-12 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89193

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Thanks, should be fixed.

[Bug go/89321] cross build with riscv64 gccgo compilation failed due to assert in constructor_expression

2019-02-12 Thread ian at airs dot com
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 fields in the struct does not match the
number of values in the composite literal.  That should be impossible, since
the compiler fills in zero values as needed.  So unfortunately I'm not sure
that is all that helpful.

[Bug go/89321] cross build with riscv64 gccgo compilation failed due to assert in constructor_expression

2019-02-12 Thread ian at airs dot com
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 when compiling for amd64?

[Bug libbacktrace/81983] libbacktrace calls bsearch with NULL base

2019-02-11 Thread ian at airs dot com
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.

[Bug libbacktrace/60240] libbacktrace problems with nested functions

2019-02-09 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60240

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Ian Lance Taylor  ---
I agree that this example cannot be expected to work.  The docs for
backtrace_pcinfo say that the function works when "Given PC, a program counter
in the current program."  The value (uintptr_t) is not a program counter in
the current program.

[Bug libbacktrace/78063] libbacktrace fails to handle cross CU DW_AT_abstract_origin

2019-02-06 Thread ian at airs dot com
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 from Ian Lance Taylor  ---
Patch looks basically OK to me.

[Bug go/89199] libgo regression in implementation of CompareAndSwap functions resulting in intermittent testcase failures on ppc64le power9 after r268458

2019-02-06 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89199

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Ian Lance Taylor  ---
Should be fixed, thanks for identifying the problem.

[Bug go/89227] gotools test cmd/go fails with link error "call lacks nop, can't restore toc; recompile with -fPIC"

2019-02-06 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89227

--- Comment #1 from Ian Lance Taylor  ---
Same as https://golang.org/issue/29046?

I would bet that this has something to do with the fact that testenv.HasLink is
inlinable.  Something is wrong with the way that the frontend is passing the
inlinable function to the backend.  The specific code in gcc/go/go-gcc.cc is in
Gcc_backend::function:

  if ((flags & function_only_inline) != 0)
{
  DECL_EXTERNAL(decl) = 1;
  DECL_DECLARED_INLINE_P(decl) = 1;
}

This is intended to tell the backend to treat the function the way it treats a
C gnu89 extern inline function.  This seems to work fine on x86 but perhaps I
am missing something on ppc64le.

[Bug go/52084] go tests fail to link on powerpc-linux-gnu (undefined reference to __sync_add_and_fetch_8)

2019-02-01 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52084

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Ian Lance Taylor  ---
Should be fixed now.

[Bug go/52084] go tests fail to link on powerpc-linux-gnu (undefined reference to __sync_add_and_fetch_8)

2019-02-01 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52084

--- Comment #4 from Ian Lance Taylor  ---
That seems like a new problem, not sure why you are reopening this bug report
from seven years ago.

[Bug go/89123] Too many go test failures on s390x-linux

2019-02-01 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123

--- Comment #8 from Ian Lance Taylor  ---
Created attachment 45590
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45590=edit
Sketch of patch

Thanks.  That does make the problem obvious.  I've attached a sketch of what a
patch should look like.  Basically, we want to call instructions like stfle and
km.  As far as I can tell these are not available as GCC intrinsics, and as
such will have to be invoked using __asm__.  I'm not sure quite what that would
look like on S/390.  Hopefully this patch sketch will let you make some forward
progress.  Let me know if I can help.

[Bug go/89123] Too many go test failures on s390x-linux

2019-02-01 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123

--- Comment #6 from Ian Lance Taylor  ---
Thanks.  I could have predicted that that would be the change.  Unfortunately
that isn't useful as that is a huge change, bringing in a large number of
upstream changes from the master Go library.

While anything is possible I think it's relatively unlikely to be an endianness
problem.  The Go code works on a range of different processors, including
big-endian ones like SPARC.

It seems that programs are crashing fairly early in their run, so I recommend
that you build a failing program and run it under the debugger so see where it
crashes.  That will probably suggest something.

Or I'm willing to look at it if there is guest access available on an S/390
GNU/Linux system.

[Bug go/89123] Too many go test failures on s390x-linux

2019-01-30 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||vogt at linux dot vnet.ibm.com

--- Comment #3 from Ian Lance Taylor  ---
Clearly something is badly broken, but I don't know how to find out what it is.
 There is no S/390 machine on the GCC compile farm.  Added Dominik Vogt who
contributed the initial S/390 support to gccgo.

[Bug go/89019] LTO and gccgo cause ICE during free_lang_data

2019-01-23 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89019

--- Comment #2 from Ian Lance Taylor  ---
Thanks for looking into this.  The patch looks fine, want to send it to
gcc-patches with a ChangeLog entry?  CC i...@golang.org.  Thanks.

[Bug go/88927] [9 Regression] Bootstrap failure on arm in libgo starting with r268084

2019-01-21 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88927

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Ian Lance Taylor  ---
The build problem is fixed, leaving the test failures for another day.

[Bug go/88927] [9 Regression] Bootstrap failure on arm in libgo starting with r268084

2019-01-19 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88927

--- Comment #1 from Ian Lance Taylor  ---
This is likely fixed by https://golang.org/cl/158717.

[Bug libbacktrace/88890] libbacktrace on 32-bit system with _FILE_OFFSET_BITS == 64

2019-01-18 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88890

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ian at airs dot com
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Fixed.

[Bug go/88202] FAIL: runtime/pprof

2019-01-17 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88202

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Fixed.

[Bug go/56431] -lpthread should be added to -lgo

2019-01-16 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56431

--- Comment #8 from Ian Lance Taylor  ---
The workaround for this is probably to change gcc/go/gospec.c to remove the
need_thread variable.  That would have the effect of changing the only use of
need_thread to only test library > 0, which would mean that gccgo would add
-lpthread every time it adds -lgo.  (I don't plan to try implementing and
testing this myself.)

[Bug go/88500] [SH]: SETCONTEXT_CLOBBERS_TLS needs to be handled in libgo

2019-01-16 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88500

--- Comment #1 from Ian Lance Taylor  ---
SETCONTEXT_CLOBBERS_TLS is set by libgo/configure.ac if this program fails to
exit successfully.  So the first step in fixing this bug is finding out why
this program fails on SH.


#include 
#include 
#include 
#include 

__thread int tls;

static char stack[[10 * 1024 * 1024]];
static ucontext_t c;

/* Called via makecontext/setcontext.  */

static void
cfn (void)
{
  exit (tls);
}

/* Called via pthread_create.  */

static void *
tfn (void *dummy)
{
  /* The thread should still see this value after calling
 setcontext.  */
  tls = 0;

  setcontext ();

  /* The call to setcontext should not return.  */
  abort ();
}

int
main ()
{
  pthread_t tid;

  /* The thread should not see this value.  */
  tls = 1;

  if (getcontext () < 0)
abort ();

  c.uc_stack.ss_sp = stack;
#ifdef MAKECONTEXT_STACK_TOP
  c.uc_stack.ss_sp += sizeof stack;
#endif
  c.uc_stack.ss_flags = 0;
  c.uc_stack.ss_size = sizeof stack;
  c.uc_link = NULL;
  makecontext (, cfn, 0);

  if (pthread_create (, NULL, tfn, NULL) != 0)
abort ();

  if (pthread_join (tid, NULL) != 0)
abort ();

  /* The thread should have called exit.  */
  abort ();
}

[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:

2018-12-07 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #7 from Ian Lance Taylor  ---
It looks like that was a real symbol from a real program.  What happens if we
double the recursion limit?

[Bug go/88135] error: reference to undefined identifier ‘syscall.WEXITED’

2018-11-27 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88135

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Should be fixed on trunk.

[Bug go/88171] [9 Regression] libgo bootstrap failure on x86_64-linux-gnu (32bit multilib): ICE: Maximum number of LRA assignment passes is achieved (30)

2018-11-23 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88171

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||bergner at vnet dot ibm.com,
   ||vmakarov at redhat dot com

--- Comment #1 from Ian Lance Taylor  ---
This seems unlikely to be related to the Go frontend.  CC'ing Vlad for LRA
thoughts and Peter Bergner because he seems to have made recent changes in this
area.

[Bug libbacktrace/88063] Libbacktrace leak on dwarf read failure

2018-11-21 Thread ian at airs dot com
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.

[Bug go/88060] ../../../gcc-8.2.0/libgo/go/syscall/libcall_linux_utimesnano.go:17:18: error: reference to undefined name ‘_AT_FDCWD’

2018-11-20 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88060

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Ian Lance Taylor  ---
These problems should be fixed.  Thanks for the info.

[Bug libbacktrace/88063] Libbacktrace leak on dwarf read failure

2018-11-20 Thread ian at airs dot com
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 from Ian Lance Taylor  ---
Created attachment 45048
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45048=edit
Proposed patch

Does this patch look right to you?

[Bug go/88060] ../../../gcc-8.2.0/libgo/go/syscall/libcall_linux_utimesnano.go:17:18: error: reference to undefined name ‘_AT_FDCWD’

2018-11-16 Thread ian at airs dot com
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?

[Bug go/88060] ../../../gcc-8.2.0/libgo/go/syscall/libcall_linux_utimesnano.go:17:18: error: reference to undefined name ‘_AT_FDCWD’

2018-11-16 Thread ian at airs dot com
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 not?  Where is it defined?

[Bug tree-optimization/88011] [9 regression] r266028 causes a bunch of go failures

2018-11-16 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88011

--- Comment #12 from Ian Lance Taylor  ---
Thanks!

[Bug tree-optimization/88011] [9 regression] r266028 causes a bunch of go failures

2018-11-15 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88011

Ian Lance Taylor  changed:

   What|Removed |Added

  Attachment #45013|0   |1
is obsolete||
  Attachment #45018|0   |1
is obsolete||

--- Comment #8 from Ian Lance Taylor  ---
Created attachment 45019
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45019=edit
Standalone test case

An even smaller test case.  The miscompilation is definitely in the lehmerGCD
function.  The computation `ua+q*ub` is being dropped in the 115t.dom2 pass.  I
don't know why.  I haven't been able to recreate this in a C test case.  I
don't know why.

Note that in Go the division a / b compiles to
a == -1 ? (b == -1 ? 1 : 0) : a / b
and a % b compiles to
a == -1 ? (b == -1 ? 0 : a) : a % b
That is related to this, in that it causes extra basic blocks, and something
about the block merging in dom2 is causing the expression to be discarded.

[Bug tree-optimization/88011] [9 regression] r266028 causes a bunch of go failures

2018-11-15 Thread ian at airs dot com
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 like the miscompilation is in lehmerGCD.

[Bug tree-optimization/88011] [9 regression] r266028 causes a bunch of go failures

2018-11-15 Thread ian at airs dot com
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 from Ian Lance Taylor  ---
Created attachment 45013
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45013=edit
Standalone test case

Here is a standalone, but not minimal, test case.  It does still needs to be
linked against libgo, but the erroneously compiled code should be somewhere in
this file.

[Bug go/87470] [9 Regression] libgo/go/runtime/malloc.go failed to build with -mx32

2018-11-14 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87470

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Ian Lance Taylor  ---
This was fixed by https://golang.org/cl/138817,
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00045.html .

[Bug testsuite/88002] libbacktrace and libiberty tests don't use dejagnu

2018-11-13 Thread ian at airs dot com
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 me.

[Bug other/82857] libbacktrace: please support binaries stripped with dwz -m (following the .gnu_debugaltlink)

2018-11-01 Thread ian at airs dot com
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 from Ian Lance Taylor  ---
Are there any docs for the dwz -m format or for .gnu.debugaltlink?

[Bug go/87661] [9 Regression] libgo bootstrap failure on arm-linux-gnueabihf (redefinition of constants)

2018-10-24 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87661

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Ian Lance Taylor  ---
*** Bug 87722 has been marked as a duplicate of this bug. ***

[Bug go/87722] [9 Regression] go bootstrap is broken on armv7l target

2018-10-24 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87722

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Ian Lance Taylor  ---
Dup of 87661, which should have been fixed by revision 265439.

*** This bug has been marked as a duplicate of bug 87661 ***

[Bug go/87661] [9 Regression] libgo bootstrap failure on arm-linux-gnueabihf (redefinition of constants)

2018-10-23 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87661

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Should be fixed now.

[Bug libbacktrace/87653] Calling null pointer in multi-threaded applications

2018-10-19 Thread ian at airs dot com
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 that calls main_test_loop.  If you can recreate the problem
consistently, can you see if this patch fixes it?  Thanks.

[Bug libbacktrace/87529] libbacktrace API forces users to have memory leaks

2018-10-05 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87529

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Ian Lance Taylor  ---
Thanks, closing this PR.

[Bug libbacktrace/87529] libbacktrace API forces users to have memory leaks

2018-10-05 Thread ian at airs dot com
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 from Ian Lance Taylor  ---
Programs are expected to call backtrace_create_state once.  There's no reason
to call it more than once.

Yes, I agree that it would be nice to have backtrace_free_state, but it's hard
to write correctly.  And it's hard to see why any program would want to call
it, as it would be less efficient.

[Bug go/87260] [8/9 Regression] go fails to build a simple program on arm-linux-gnueabihf

2018-09-14 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87260

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Ian Lance Taylor  ---
Should be fixed on trunk and GCC 8 branch.

[Bug go/87260] [8 Regression] go fails to build a simple program on arm-linux-gnueabihf

2018-09-09 Thread ian at airs dot com
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?

[Bug libbacktrace/87182] libbacktrace does not use GCC own zlib

2018-09-03 Thread ian at airs dot com
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 libbacktrace/configure.ac causes -lz to be added to LIBS.  This happens
temporarily during the configure script, but the assignment to LIBS is undone. 
It is not reflected in the generated Makefile.

So while I'm certainly willing to fix this, I can't recreate the problem and I
don't understand the problem.  Can you explain further?  Thanks.

[Bug libbacktrace/87182] libbacktrace does not use GCC own zlib

2018-09-03 Thread ian at airs dot com
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 from Ian Lance Taylor  ---
Note that zlib is only used for the test programs, not for libbacktrace itself.
 Are you sure that libgfortran is picking up a dependency on zlib?  If that is
coming from libbacktrace, then something else is going wrong.

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

2018-07-18 Thread ian at airs dot com
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.

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

2018-07-18 Thread ian at airs dot com
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.

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

2018-07-17 Thread ian at airs dot com
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 able to recreate the problem
myself.

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

2018-07-17 Thread ian at airs dot com
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 

?

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

2018-07-17 Thread ian at airs dot com
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 convinced that it is in some
header file on your system.  When I say a header file I don't mean a file in
the GCC distribution.  I mean a file in /usr/include.  I would specifically
expect it to be defined in /usr/include/netinet/in.h, or some file #included'd
by that one.  Can you find the definition under /usr/include and show it to us?
 Thanks.

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

2018-07-16 Thread ian at airs dot com
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)?

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

2018-07-02 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Ian Lance Taylor  ---
This should now be fixed.

I filed the general issue of syscall.Syscall as https://golang.org/issue/26183.

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

2018-06-29 Thread ian at airs dot com
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 whether a system call failed, this may
require libgo to provide assembly language versions of syscall.Syscall.

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

2018-06-28 Thread ian at airs dot com
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 that waitid is not
returning an error.

The code calls waitid via syscall.Syscall6 (libgo/go/os/wait_waitid.go).  The
Syscall6 function (libgo/go/syscall/syscall_unix.go) sets errno to 0, calls the
C library syscall function, and then reads errno.  If the errno value that it
reads is not 0, the program will think that the system call to waitid has
failed.  At this point my best guess is that in some cases errno is being set
to ENOENT somehow.  As far as I know this approach of setting errno to 0 and
checking it after the syscall is the only general way to tell whether a syscall
has failed.

I wonder if the fact that this is running in a VM could have something to do
with this.  Perhaps something the VM is doing is sometimes causing the errno
value to change.

It's possible that this patch will work around the problem.  Could you try this
to see if it helps?  Thanks.

diff --git a/libgo/go/os/wait_waitid.go b/libgo/go/os/wait_waitid.go
index 5a62b27f..c2a34ff6 100644
--- a/libgo/go/os/wait_waitid.go
+++ b/libgo/go/os/wait_waitid.go
@@ -28,9 +28,12 @@ func (p *Process) blockUntilWaitable() (bool, error) {
// We don't care about the values it returns.
var siginfo [16]uint64
psig := [0]
-   _, _, e := syscall.Syscall6(syscall.SYS_WAITID, _P_PID, uintptr(p.Pid),
uintptr(unsafe.Pointer(psig)), syscall.WEXITED|syscall.WNOWAIT, 0, 0)
+   r, _, e := syscall.Syscall6(syscall.SYS_WAITID, _P_PID, uintptr(p.Pid),
uintptr(unsafe.Pointer(psig)), syscall.WEXITED|syscall.WNOWAIT, 0, 0)
runtime.KeepAlive(p)
-   if e != 0 {
+   // Check r as well as e because https://gcc.gnu.org/PR86331
+   // suggests that on arm64 systems in a VM checking only e is
+   // unreliable.
+   if r != 0 && e != 0 {
// waitid has been available since Linux 2.6.9, but
// reportedly is not available in Ubuntu on Windows.
// See issue 16610.

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

2018-06-28 Thread ian at airs dot com
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.

[Bug go/86343] types built by GO share TYPE_FIELDS in unsupported way

2018-06-28 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86343

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Should be fixed.  Sorry for the problem.

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

2018-06-27 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-06-27
 Ever confirmed|0   |1

--- Comment #1 from Ian Lance Taylor  ---
I'm not clear: does the error "waitid: no such file or directory" happen
randomly, or does it happen every time?

It looks like calling the waitid system call is returning ENOENT.  I don't know
what that would happen.  Can you attach the output of `strace -f` for a failing
run?  Thanks.

[Bug go/86289] Cgo integer constant overflow for 64 bits (unsigned) int

2018-06-26 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86289

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #4 from Ian Lance Taylor  ---
Let's track this on https://golang.org/issue/26066.  Thanks.

[Bug go/86289] Cgo integer constant overflow for 64 bits (unsigned) int

2018-06-26 Thread ian at airs dot com
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.

  1   2   3   4   5   6   7   8   9   10   >