[Bug go/79443] libgo/math test fails on s390x (undefined symbols cosh, sinh, tanh, hasVX)

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79443

--- Comment #3 from Ian Lance Taylor  ---
Created attachment 40708
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40708=edit
crypto patch

This patch may fix the crypto/sha256 problem.

Any other problems?  `make check-target-libgo` should show all of them.

No need to open separate bugs for each one.

[Bug go/79443] libgo/math test fails on s390x (undefined symbols cosh, sinh, tanh, hasVX)

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79443

--- Comment #1 from Ian Lance Taylor  ---
Created attachment 40707
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40707=edit
Possible patch

Can you check whether this patch fixes the problem?  Thanks.

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281

--- Comment #14 from Ian Lance Taylor  ---
> Could you maybe also backport the fix for PR/79037? [1]

Done.

> Btw, even with the fixes from this PR/79281 and PR/79037, the "go" command is 
> still crashing on m68k with gcc-6. It might be possible that this is the 
> reason the build of gcc-7 fails for this reason, doesn't it?

It could be related, but building GCC does not actually run the go command.

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281

--- Comment #11 from Ian Lance Taylor  ---
Thanks.  I committed the patch to the GCC 6 branch.

GCC 7 will require a different fix, as the code has moved from C to Go.  I'm
not sure what the best approach is.

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281

--- Comment #7 from Ian Lance Taylor  ---
It sounds like you have a patch for GCC 6.  If you send it in I can apply it.

The error you show must be from `make -j`, as compiling a file in libgfortran
would not invoke go1.  What is the actual failure?

[Bug debug/79289] DWARF info for typeof of C function with no args and no prototype is empty pointer

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79289

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #4 from Ian Lance Taylor  ---
Patch committed.

[Bug debug/79289] DWARF info for typeof of C function with no args and no prototype is empty pointer

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79289

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #1 from Ian Lance Taylor  ---
I think the bug is a mismatch in how the code determines the base type to use
for the DIE in this change:

2016-11-03  Jakub Jelinek  
Alexandre Oliva  
Jason Merrill  

PR debug/28767
PR debug/56974
* langhooks.h (struct lang_hooks_for_types): Add type_dwarf_attribute
langhook.
* langhooks.c (lhd_type_dwarf_attribute): New function.
* langhooks-def.h (lhd_type_dwarf_attribute): Declare.
(LANG_HOOKS_TYPE_DWARF_ATTRIBUTE): Define.
(LANG_HOOKS_FOR_TYPES_INITIALIZER): Add
LANG_HOOKS_TYPE_DWARF_ATTRIBUTE.
(check_qualified_type, check_aligned_type): Call it.
* dwarf2out.c (modified_type_die): Don't use type_main_variant
for FUNCTION_TYPE or METHOD_TYPE, instead walk over variants with
check_base_type and check_lang_type.
(gen_ptr_to_mbr_type_die): If lookup_type_die is already non-NULL,
return early.  For pointer-to-data-member add DW_AT_use_location
attribute.
(gen_subroutine_type_die): Add DW_AT_{,rvalue_}reference attribute
if needed.
(gen_type_die_with_usage): Don't use type_main_variant
for FUNCTION_TYPE or METHOD_TYPE, instead walk over variants with
check_base_type and check_lang_type.  Formatting fixes. Call
get_debug_type langhook.

The problem is that the DIE is stored with one type variant in
gen_type_die_with_usage (the last matching variant), but looked up with a
different type variant in modified_type_die (the first matching variant).

This patch seems to fix the problem, but I can't tell whether this is correct
or whether the other obvious change is correct.


Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 244166)
+++ gcc/dwarf2out.c (working copy)
@@ -24395,8 +24395,13 @@ gen_type_die_with_usage (tree type, dw_d
 but try to canonicalize.  */
   tree main = TYPE_MAIN_VARIANT (type);
   for (tree t = main; t; t = TYPE_NEXT_VARIANT (t))
-   if (check_base_type (t, main) && check_lang_type (t, type))
- type = t;
+   {
+ if (check_base_type (t, main) && check_lang_type (t, type))
+   {
+ type = t;
+ break;
+   }
+   }
 }
   else if (TREE_CODE (type) != VECTOR_TYPE
   && TREE_CODE (type) != ARRAY_TYPE)

[Bug debug/79289] New: DWARF info for typeof of C function with no args and no prototype is empty pointer

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79289

Bug ID: 79289
   Summary: DWARF info for typeof of C function with no args and
no prototype is empty pointer
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian at airs dot com
  Target Milestone: ---

Compile this program with current mainline with -g on GNU/Linux:

static void sub() {}
void f1() { sub(); }
void f2(void) { sub(); }
__typeof__(f1) *v1;
__typeof__(f2) *v2;

Using readelf --debug to examine the debug info I see this for v1:

<1><2d>: Abbrev Number: 2 (DW_TAG_variable)
<2e>   DW_AT_name: v1   
<31>   DW_AT_decl_file   : 1
<32>   DW_AT_decl_line   : 4
<33>   DW_AT_type: <0x41>   
<37>   DW_AT_external: 1
<37>   DW_AT_location: 9 byte block: 3 8 0 0 0 0 0 0 0  (DW_OP_addr: 8)
 <1><41>: Abbrev Number: 3 (DW_TAG_pointer_type)
<42>   DW_AT_byte_size   : 8

Note that the type of v1 is a pointer, but there is no type listed for what it
points to.

By comparison, the debug info for v2 is:

 <1><43>: Abbrev Number: 4 (DW_TAG_subroutine_type)
<44>   DW_AT_prototyped  : 1
 <1><44>: Abbrev Number: 2 (DW_TAG_variable)
<45>   DW_AT_name: v2   
<48>   DW_AT_decl_file   : 1
<49>   DW_AT_decl_line   : 5
<4a>   DW_AT_type: <0x58>   
<4e>   DW_AT_external: 1
<4e>   DW_AT_location: 9 byte block: 3 8 0 0 0 0 0 0 0  (DW_OP_addr: 8)
 <1><58>: Abbrev Number: 5 (DW_TAG_pointer_type)
<59>   DW_AT_byte_size   : 8
<5a>   DW_AT_type: <0x43>   

Here the type of v2 is clearly a pointer to a function, although there is no
real information about the function: just that it is prototyped.


By comparison, with GCC 6, I see this for v1:

 <1><29>: Abbrev Number: 2 (DW_TAG_subroutine_type)
<2a>   DW_AT_sibling : <0x30>   
 <2><2e>: Abbrev Number: 3 (DW_TAG_unspecified_parameters)
 <2><2f>: Abbrev Number: 0
 <1><30>: Abbrev Number: 4 (DW_TAG_variable)
<31>   DW_AT_name: v1   
<34>   DW_AT_decl_file   : 1
<35>   DW_AT_decl_line   : 4
<36>   DW_AT_type: <0x44>   
<3a>   DW_AT_external: 1
<3a>   DW_AT_location: 9 byte block: 3 8 0 0 0 0 0 0 0  (DW_OP_addr: 8)
 <1><44>: Abbrev Number: 5 (DW_TAG_pointer_type)
<45>   DW_AT_byte_size   : 8
<46>   DW_AT_type: <0x29>   

and I see this for v2 (the same as for GCC 7):

 <1><4a>: Abbrev Number: 6 (DW_TAG_subroutine_type)
<4b>   DW_AT_prototyped  : 1
 <1><4b>: Abbrev Number: 4 (DW_TAG_variable)
<4c>   DW_AT_name: v2   
<4f>   DW_AT_decl_file   : 1
<50>   DW_AT_decl_line   : 5
<51>   DW_AT_type: <0x5f>   
<55>   DW_AT_external: 1
<55>   DW_AT_location: 9 byte block: 3 8 0 0 0 0 0 0 0  (DW_OP_addr: 8)
 <1><5f>: Abbrev Number: 5 (DW_TAG_pointer_type)
<60>   DW_AT_byte_size   : 8
<61>   DW_AT_type: <0x4a>   


I'm not entirely sure what is correct here, but a pointer type that doesn't
point to anything must be wrong.  The change from GCC 6 to GCC 7 in the debug
info for v1 is a regression.

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281

--- Comment #2 from Ian Lance Taylor  ---
Perhaps this would be fixed by adding __attribute__((aligned(4))) to some field
of struct Sched in proc.c.

This code is all different on trunk/GCC7.  I don't know whether it still has
the same problem or not.  Probably it does but the fix would have to be
different.

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037

--- Comment #9 from Ian Lance Taylor  ---
The backend.h interface says that if you set the alignment, that is the
alignment.  I could change it to the GCC version--you can only increase the
alignment--but I'd rather keep the backend.h interface simple.

[Bug go/79146] [7 Regression] Bootstrapping go on s390x fails; redefined symbols

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79146

--- Comment #5 from Ian Lance Taylor  ---
Well, it helped in that it uncovered a different problem.

Fixed again.

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037

--- Comment #7 from Ian Lance Taylor  ---
Can someone with m68k hardware please test the patch at
https://golang.org/cl/35478?  Thanks.  (To download just the patch as a zip
file: https://go-review.googlesource.com/changes/35478/revisions/1/patch?zip).

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037

--- Comment #6 from Ian Lance Taylor  ---
I don't think it's the type descriptors that need to be aligned, I think it's
just the GC symbol pointers.  Those are the ones whose names end in "$gc" in
the list above.

[Bug go/79146] [7 Regression] Bootstrapping go on s390x fails; redefined symbols

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79146

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/79122] go test -race reports import cycles with gccgo

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79122

--- Comment #2 from Ian Lance Taylor  ---
Note that the race detector doesn't work at all with gccgo.  So while this is a
pretty bad error message, the only fix for this bug is going to be to produce a
better error message.

[Bug bootstrap/79068] [7 Regression] Bootstrap failure on powerpc64-linux and armv7hl-linux-gnueabi in libgo

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79068

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #4 from Ian Lance Taylor  ---
Yes, that is the fix for the bug.

[Bug go/78978] [7 regression] runtime/pprof FAILs on Solaris 2/x86

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78978

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/78789] Error: no such instruction: `aesenc %xmm0,%xmm2' when compiling libgo/runtime/aeshash.c

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78789

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/78978] [7 regression] runtime/pprof FAILs on Solaris 2/x86

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78978

--- Comment #1 from Ian Lance Taylor  ---
If the libstdc++ approach works and is acceptable, it seems to me we should do
the same for libgo.

[Bug go/78763] go1: internal compiler error: in do_get_backend, at go/gofrontend/expressions.cc:8352

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78763

--- Comment #8 from Ian Lance Taylor  ---
Here is a test case that recreates the problem.

package p

import (
"unsafe"
)

func F() int {
if unsafe.Sizeof(0) == 8 {
return 8
}
return 0
}

[Bug go/78431] [7 regression] ICE in go_append_padding, at godump.c:636

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78431
Bug 78431 depends on bug 78432, which changed state.

Bug 78432 Summary: [7 Regression] -fdump-go-spec ICEs for aligned causing x32 
libgo library to fail to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78432

   What|Removed |Added

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

[Bug go/78431] [7 regression] ICE in go_append_padding, at godump.c:636

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78431

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/78432] [7 Regression] -fdump-go-spec ICEs for aligned causing x32 libgo library to fail to build

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78432

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/77910] [7 Regression] go: open zversion.go: no such file or directory

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77910

Ian Lance Taylor  changed:

   What|Removed |Added

 Resolution|WONTFIX |FIXED

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

[Bug go/77910] [7 Regression] go: open zversion.go: no such file or directory

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77910

--- Comment #7 from Ian Lance Taylor  ---
Coincidentally I am going to submit the patch to fix this today.  It was held
up for a while in code review on the master repository.  (The fix in the master
repository is https://golang.org/cl/33295).

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #11 from Ian Lance Taylor  ---
I would guess that this problem is fixed now on trunk.  Please let me know if
not.

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172

--- Comment #9 from Ian Lance Taylor  ---
Regarding arpcom, the syscall package is not really intended to include
everything that seems useful.  That is the goal of the external package
golang.org/x/sys/unix.  The syscall package only includes everything needed by
the standard library, and some functions and types that were there historically
and are now hard to remove.

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172

--- Comment #7 from Ian Lance Taylor  ---
Thanks.  Does a patch like this fix the immediate ucred problem?

diff --git a/libgo/mksysinfo.sh b/libgo/mksysinfo.sh
index 3640476..6c457b6 100755
--- a/libgo/mksysinfo.sh
+++ b/libgo/mksysinfo.sh
@@ -268,7 +268,7 @@ fi
 # is not empty, the structure or type is renamed to $2.
 upcase_fields () {
   name="$1"
-  def=`grep "^type $name" gen-sysinfo.go`
+  def=`grep "^type $name " gen-sysinfo.go`
   fields=`echo $def | sed -e 's/^[^{]*{\(.*\)}$/\1/'`
   prefix=`echo $def | sed -e 's/{.*//'`
   if test "$2" != ""; then

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172

--- Comment #5 from Ian Lance Taylor  ---
Thanks.  I do not see any problem in that file you attached.  I also don't see
anything like the line in the original error message.

Looking more closely at that line, I see now that it appears to have several
separate statements stuck together.  Each "type" keyword should appear at the
beginning of a line (this is not required by the Go language, but it is a
result of how sysinfo.go is generated).  And indeed in the sysinfo.go file that
you attached that is what I see.  I think we need to understand why that is not
true in the original report.

sysinfo.go is generated by the script libgo/mksysinfo.sh from the generated
file gen-sysinfo.go.  The file gen-sysinfo.go is generated by running gcc
-fdump-go-spec on sysinfo.c.  Where did things go wrong?

[Bug go/78145] Several go.test tests fail with error: integer constant overflow on 32bit targets

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78145

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172

--- Comment #3 from Ian Lance Taylor  ---
If that is the complete line, then something has gone badly wrong.

Can you get a copy of the complete generated sysinfo.go file?

[Bug go/78172] gen-sysinfo.go vs AIX cred.h

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172

--- Comment #1 from Ian Lance Taylor  ---
What does that whole line look like?  It seems to be truncated in the output
for some reason.

Is _priv_t defined elsewhere in the file?  That is, is there a line that starts
with "type _priv_t "?  If not, that will be a problem.

[Bug go/78144] FAIL: time on systems with tzdata2016g installed

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78144

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/78143] [7 Regression] bootstrap broken in libgo on powerpc-linux-gnu

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78143

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/77977] stage3 bootstrap error in libgo on x86_64: cannot stat 'stubs.o'

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77977

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #1 from Ian Lance Taylor  ---
Jakub, did you figure anything out about this?

[Bug go/77910] [7 Regression] go: open zversion.go: no such file or directory

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77910

--- Comment #1 from Ian Lance Taylor  ---
Works for me.

Do you have a copy of the gc toolchain on your computer?  Is the environment
variable GOROOT set?

[Bug go/77861] GO and Mac OS X : configure impossible

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77861

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Dup of existing bug.

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

[Bug go/46986] Go is not supported on Darwin

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||socnet.delphin at laposte dot 
net

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

[Bug go/77809] [7 regression] "_LITTLE_ENDIAN" redefined

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77809

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/77780] Go front-end ignores NO_DOLLAR_IN_LABEL

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77780

--- Comment #3 from Ian Lance Taylor  ---
My inclination would be to overhaul all the identifiers in the gofrontend to
rationalize them from the rather random collection they are now.

[Bug go/77688] [7 Regression] libgo bootstrap broken on mips*-linux-gnu and sparc*-linux-gnu

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77688

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/77701] suspicious code in go/go-gcc.cc

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77701

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #3 from Ian Lance Taylor  ---
Fixed.  Thanks for noticing.

[Bug go/77625] go/gofrontend/ast-dump.cc:169:42: error: ‘new’ of type ‘std::ofstr eam {aka std::basic_ofstream}’ with extended alignment 16

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77625

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/77642] GO Bootstrap fail starting with r239872 splitstack signature does not match

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77642

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #4 from Ian Lance Taylor  ---
Should be fixed.  Thanks for the patch.

[Bug bootstrap/11660] libffi only builds when java is selected as language

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11660

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ian at airs dot com
 Resolution|--- |WONTFIX

--- Comment #12 from Ian Lance Taylor  ---
I don't think there is anything to fix here, so I'm going to close this.  GCC
is not the master source for libffi.

[Bug go/70597] [6/7 Regression] cmd/go: deduplicate gccgo afiles by package path, not *Package

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70597

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|6.3 |6.2

--- Comment #4 from Ian Lance Taylor  ---
A patch to fix this was committed to the GCC 6 branch before the 6.2 release. 
It is also fixed on mainline.

[Bug go/72814] reflect FAILs on 32-bit Solaris/SPARC: SIGILL

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72814

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/72814] reflect FAILs on 32-bit Solaris/SPARC: SIGILL

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72814

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-08-08
 Ever confirmed|0   |1

--- Comment #1 from Ian Lance Taylor  ---
The failing test is a function that returns a zero-sized struct.  The libffi
library does not support a zero-sized struct, so libgo and libffi togther wind
up treating the return type as a struct whose size is 1 byte.  On 32-bit SPARC,
a call to a function that returns a struct whose size is larger than 0 is
followed by an unimp instruction.  The function is compiled to skip the unimp
instruction when it returns.  See the handling of %) in sparc_print_operand in
gcc/config/sparc/sparc.c.  So libffi, thinking that the function returns a
non-empty struct, provides an unimp instruction to be skipped.  But the actual
function returns an empty struct, and therefore does not expect the unimp
instruction, and therefore does not skip it.  The result is an attempt to
execute the instruction, causing the SIGILL.

[Bug go/72812] reflect FAILs with Solaris as

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72812

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/72812] reflect FAILs with Solaris as

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72812

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-08-05
 Ever confirmed|0   |1

--- Comment #1 from Ian Lance Taylor  ---
The Solaris assembler is unhappy with the use of non-ASCII characters in
symbols.  The symbols in question are being generated by

func TestStructOfExportRules(t *testing.T) {
type ΦType struct{}
type φType struct{}

so in this case they aren't even externally visible.  But similar issues arise
when writing

func φFunc() {}

I think we need a general rewriting of non-ASCII symbols, ideally without
disturbing debug info.  I'll see if I can do this in the GCC backend interface.

[Bug go/71697] go link error

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71697

--- Comment #3 from Ian Lance Taylor  ---
The running the failing command yourself with the -v option and see which
options are being passed to the linker.

[Bug go/71697] go link error

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71697

--- Comment #1 from Ian Lance Taylor  ---
Note that as far as I can tell that error is only emitted by the GNU linker
when the --no-add-needed option is passed to the linker.  Is something on your
system adding that option or making it the default in some way?

[Bug go/71692] Running target unix FAIL: syscall

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71692

--- Comment #2 from Ian Lance Taylor  ---
The relevant failures are:

--- FAIL: TestCloneNEWUSERAndRemapNoRootDisableSetgroups (0.00s)
exec_linux_test.go:74: Cmd failed with err fork/exec /usr/bin/whoami:
in
valid argument, output: 
--- FAIL: TestCloneNEWUSERAndRemapNoRootSetgroupsEnableSetgroups (0.00s)
exec_linux_test.go:114: Unprivileged gid_map rewriting with
GidMappingsE
nableSetgroups must fail
--- FAIL: TestEmptyCredGroupsDisableSetgroups (0.00s)
exec_linux_test.go:122: fork/exec /usr/bin/whoami: invalid argument

This means that your system doesn't support some kinds of user namespace
features.  The test should arrange to not fail when those features are not
supported.

[Bug go/70850] Bootstrap fails building libgo: gccgo: error: ../x86_64-pc-linux-gnu/libgo/zstdpkglist.go: No such file or directory

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70850

--- Comment #3 from Ian Lance Taylor  ---
Do we support ./configure these days?

Historically we have only supported SRCDIR/configure run in an empty directory.

[Bug testsuite/69766] go.test/test/env.go fails on biarch

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69766

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #4 from Ian Lance Taylor  ---
This is fixed by your patch, I think.  Let me know if not.

[Bug go/70304] 5.3.0 solaris: objcopy: errors.o: no group info for section .group%__go_pimt__I5_ErrorFrN6_stringeee__N18_errors.errorString

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70304

--- Comment #1 from Ian Lance Taylor  ---
This looks like a disagreement between the Solaris assembler and the GNU
objcopy program.  I don't know if there is anything that gccgo can do to fix
it.  You should probably report this as a GNU binutils bug.

[Bug c++/70182] c++filt fails to demangle _ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typ

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70182

--- Comment #11 from Ian Lance Taylor  ---
g++ has generated (what I think is) the incorrect mangling since at least GCC
4.7, so this probably needs to be controlled by yet another -fabi-version
value.

[Bug c++/70182] c++filt fails to demangle _ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typ

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70182

--- Comment #9 from Ian Lance Taylor  ---
Yes.  The relevant bits in the mangling ABI are


   ::= [gs] 
   ::= sr  
   ::= srN  + E

   ::= [gs] sr + E 


   ::= 
   ::= on 
   ::= on  
   ::= dn 

 ::= 

 ::=  [  ]

 ::=  


srT_ must be sr  , where the T_ is the
, so it must be followed by . 
 can only start with a digit or "on" or "dn".  So I see
no way that srT_cl could meet the requirements of the ABI.  It has to be
srT_oncl, where the "on" is needed to indicate that "cl" is an operator name.

That said, GCC is not crazy, as there is no other way to parse this.  The
result is unambiguous.  But it doesn't meet the documented standard.

I think the bug may be that cp/mangle.c:write_member_name needs to check
IDENTIFIER_OPNAME_P and print "on" if it is true, as write_expression does. 
But I'm not sure.

[Bug c++/70182] c++filt fails to demangle _ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typ

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70182

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #7 from Ian Lance Taylor  ---
For the record, I've fixed these cases in github.com/ianlancetaylor/demangle. 
Looking at the patch there should show how to fix it elsewhere.

https://github.com/ianlancetaylor/demangle/commit/33b3934fafc5026e0b38854a7976b91ad0014a02

[Bug go/69966] libgo: Port syscall.SetsockoptUcred from golang

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69966

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Fixed on mainline, thanks.

[Bug go/67180] Gccgo does not support MIPS

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67180

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-02-10
 Ever confirmed|0   |1

[Bug go/68562] morestack misaligns stack on x86_64

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68562

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #12 from Ian Lance Taylor  ---
Thanks for testing it.  Patch committed to mainline and GCC 5 branch.

[Bug go/68503] [powerpc64le] miscompilation of composite literal

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68503

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Ian Lance Taylor  ---
I can't rebuild this any more.  With gc I get

# github.com/juju/juju/environs/configstore
../environs/configstore/disk.go:488: not enough arguments in call to
fslock.NewLock
# github.com/juju/juju/provider/gce/google
../provider/gce/google/instance.go:231: cannot use value (type string) as type
*string in field value
../provider/gce/google/instance.go:247: cannot use item.Value (type *string) as
type string in assignment


I'm going to close this.  If you see anything similar, please attach the first
GIMPLE file.  That should be enough to identify the problem, or put the blame
on the assembler or linker.  Thanks.

[Bug go/66904] cmd/go: "#cgo pkg-config:" comments do not work with gccgo

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66904

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/66368] [5 Regression] go tool crashes on powerpc-linux-gnu

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66368

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-02-10
 Ever confirmed|0   |1

[Bug go/65134] gccgo ignores the attribute "constructor" in a subdirectory

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65134

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #7 from Ian Lance Taylor  ---
This was fixed by the fix for PR 68255.

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

[Bug go/68255] cgo-generated constructor not being called

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68255

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||e29253 at jp dot ibm.com

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

[Bug go/63731] Fallback to netgo does not work

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #38 from Ian Lance Taylor  ---
This seems to be fixed, and the core problem has become less important now that
the net package prefers to use the Go DNS library when possible.

[Bug go/64001] gccgo: crash on stack splitting

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64001

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-02-10
 Ever confirmed|0   |1

[Bug go/68420] Errors with go escape analysis

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68420

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2016-02-10
 Ever confirmed|0   |1

--- Comment #2 from Ian Lance Taylor  ---
Suspending until the new escape analysis implementation is complete.

[Bug go/68562] morestack misaligns stack on x86_64

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68562

--- Comment #4 from Ian Lance Taylor  ---
Created attachment 37650
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37650=edit
Possible patch

Do you have a way to test whether this patch fixes the problem?

[Bug go/69511] G.gcstack_size uses uintptr instead of size_t

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69511

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Committed.  Thanks.

[Bug go/68562] morestack misaligns stack on x86_64

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68562

--- Comment #6 from Ian Lance Taylor  ---
Your build is passing the option "-B/usr/local/x86_64-pc-linux-gnu/lib/"; why?

You have an old version of the Go libraries installed under that directory. 
Either remove the -B option or remove the old version of the Go libraries.

[Bug go/69357] libgo refers to _end in a non-weak way

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69357

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #4 from Ian Lance Taylor  ---
Fixed on trunk.

[Bug go/68980] [6 regression] ps -o cmd in gotest isn't portable

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68980

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug other/69050] libbacktrace: bsearch over unsorted array in unit_addrs_search

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69050

--- Comment #1 from Ian Lance Taylor  ---
The algorithms aren't unrelated.  unit_addrs_compare sorts by low then high
then lineoff.  unit_addrs_search returns any entry that includes the PC for
which we are searching, where it includes the PC if it is between low and high.
 As the comment says, dwarf_fileline (the only caller) then moves forward to
the last range that includes PC.  This will return a consistent answer if
low/high ranges are always subsets or supersets--that is, if a->low <= b->low,
then a->high >= b->high.  That is always the case for DWARF.

If you are encountering a problem, please describe it in more detail.

[Bug go/68931] gccgo fails to build using MUSL libc

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68931

--- Comment #1 from Ian Lance Taylor  ---
I don't understand your patch, because I don't understand where CONFIG_USE_MUSL
gets set.

It also seems like the wrong approach.  The basic goal of configure tests is to
test for features, not systems.  mksysinfo.sh already works that way.  What
fails without this patch?

[Bug go/67198] [5/6 Regression] change of type of syscall.RawSockaddr.Data on ppc64 breaks compilation of existing programs

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67198

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.4 |5.3

--- Comment #9 from Ian Lance Taylor  ---
Closing.

[Bug go/66147] [5/6 Regression] go fails to cross build

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66147

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.3 |6.0

--- Comment #3 from Ian Lance Taylor  ---
This should be somewhat better on trunk.  Closing tentatively, but please
reopen if you find more problems.  Thanks.

(It's also to backport to GCC 5 branch when the branch reopens.)

[Bug go/65717] 64-bit runtime FAILs with 32-bit compiler

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65717

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #6 from Ian Lance Taylor  ---
Fixed on trunk.

[Bug go/68477] error: type variant differs by TYPE_STRING_FLAG.

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68477

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Dec  1 04:45:53 2015
New Revision: 231096

URL: https://gcc.gnu.org/viewcvs?rev=231096=gcc=rev
Log:
PR go/68477
* go-gcc.cc (Gcc_backend::string_constant_expression): Don't set
TYPE_STRING_FLAG on a variant type.

Modified:
trunk/gcc/go/ChangeLog
trunk/gcc/go/go-gcc.cc

--- Comment #3 from Ian Lance Taylor  ---
Fixed.  Thanks for reporting it.

[Bug go/61303] gccgo: segfault, regression since 4.8.2

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61303

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #12 from Ian Lance Taylor  ---
This seems to have been due to a bug in the select support, which is only used
on Solaris.  Should be fixed on mainline and GCC 5 branch.

[Bug go/68496] [libgo] reflect test fails on Linux x86-64

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68496

--- Comment #1 from Ian Lance Taylor  ---
I can not recreate this problem.  It works fine for me.

The stack trace is incomplete for some reason so I don't know what is going
wrong.

If you cd into x86_64-pc-linux-gnu/libgo, you can run
make GOTESTFLAGS="--keep" reflect/check
Presumably that will fail.  It will leave behind a gotest directory.  In
that directory you will find an a.out executable.  Running that executable runs
the test (you may have to set LD_LIBRARY_PATH so that it finds libgo.so).  Try
running that executable under gdb and see if you can get a better backtrace.

[Bug go/66574] Time is provided in millisecond precision instead of nanoseconds as described in go documentation

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66574

--- Comment #7 from Ian Lance Taylor  ---
I'm a little worried because I'm not 100% confident that clock_gettime is
available in the standard library on all systems.  I don't want to break GCC 5
is that is the case.  Admittedly I haven't seen any bug reports on mainline
yet, but it's only been a few days.

[Bug go/68496] [libgo] reflect test fails on Linux x86-64

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68496

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #5 from Ian Lance Taylor  ---
Thanks for the tip.  Should be fixed on mainline and GCC 5 branch.

[Bug go/66368] [5 Regression] go tool crashes on powerpc-linux-gnu

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66368

--- Comment #9 from Ian Lance Taylor  ---
I'm not having any luck reproducing this.  I built a 32-bit PPC GNU/Linux (on
the GCC compile farm, which is a PPC64 machine, using glibc 2.18).  I deleted
the libgo files and rebuilt them with -fstack-protector-strong.  I built a new
go tool.  It seems to work fine.

Let's try this: if you can still recreate this problem, send me the crashing
binary.  Maybe I can see something there.

[Bug go/68072] malformed DWARF TagVariable entry

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68072

--- Comment #9 from Ian Lance Taylor  ---
Thanks very much for taking the time to narrow down the test case.  That is
nice and simple.

[Bug go/68072] malformed DWARF TagVariable entry

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68072

--- Comment #10 from Ian Lance Taylor  ---
FYI, refiled as https://golang.org/issue/13344 and sent out
https://golang.org/cl/17151 , a variant of the patch you suggested.

[Bug testsuite/65785] libgo TestIPv4MulticastListener test fails on machine with no network connection

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65785

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-21
 CC||ian at airs dot com
 Ever confirmed|0   |1

--- Comment #2 from Ian Lance Taylor  ---
Sent https://golang.org/cl/17154 to fix this in the master libgo sources.

[Bug go/68072] malformed DWARF TagVariable entry

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68072

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #13 from Ian Lance Taylor  ---
Should be fixed on mainline and GCc 5 branch.

[Bug go/67976] Cgo + Gccgo not working like Cgo + Golang?

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67976

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2015-11-20
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #6 from Ian Lance Taylor  ---
Actually, I'll pull the patch into GCC 5 branch too.

[Bug go/67976] Cgo + Gccgo not working like Cgo + Golang?

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67976

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #5 from Ian Lance Taylor  ---
The patch has been pulled in with the update to Go 1.5, so this should be
fixed.

[Bug go/67976] Cgo + Gccgo not working like Cgo + Golang?

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67976

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Version|6.0 |5.3.0
 Resolution|--- |FIXED

--- Comment #8 from Ian Lance Taylor  ---
Now really fixed.

[Bug go/68141] go/gofrontend/import-archive.cc: 2 * poor choice of function parameter type ?

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68141

Ian Lance Taylor  changed:

   What|Removed |Added

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

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

[Bug go/66574] Time is provided in millisecond precision instead of nanoseconds as described in go documentation

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66574

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #5 from Ian Lance Taylor  ---
Fixed on mainline.

[Bug go/65785] libgo TestIPv4MulticastListener test fails on machine with no network connection

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65785

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #5 from Ian Lance Taylor  ---
Should be fixed.  Thanks for reporting the problem.

[Bug go/66406] go.test/test/nilptr.go FAILs with PIE

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66406

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Should be fixed on mainline, by skipping the test.  Thanks for reporting it.

[Bug go/66378] libgo syscall.Sendfile() does not honor/use offset argument

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66378

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #3 from Ian Lance Taylor  ---
Thanks for reporting the bug.  It should be fixed now on mainline and GCC 5
branch.

[Bug c++/68383] Demangler stack overflow

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68383

--- Comment #5 from Ian Lance Taylor  ---
Thanks for the test case.  Which version of GCC are you using to compile?  When
I try to compile the test case I get

/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/avx512fintrin.h: In function
‘__m512i _mm512_set1_epi64(long long int)’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/avx512fintrin.h:3631:25: error:
‘__builtin_ia32_pbroadcastq512_mem_mask’ was not declared in this scope
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/avx512fintrin.h: In function
‘__m512i _mm512_mask_set1_epi64(__m512i, __mmask8, long long int)’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/avx512fintrin.h:3644:14: error:
‘__builtin_ia32_pbroadcastq512_mem_mask’ was not declared in this scope
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/avx512fintrin.h: In function
‘__m512i _mm512_maskz_set1_epi64(__mmask8, long long int)’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/avx512fintrin.h:3661:11: error:
‘__builtin_ia32_pbroadcastq512_mem_mask’ was not declared in this scope


The version of avx512fintrin.h on mainline does not seem to call the function
__builtin_ia32_pbroadcastq512_mem_mask.