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

2019-04-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110

--- Comment #12 from Richard Biener  ---
(In reply to Ian Lance Taylor from comment #11)
> Fixed, I hope.

Yes.

[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 gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110

--- Comment #10 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu Apr 18 04:11:22 2019
New Revision: 270434

URL: https://gcc.gnu.org/viewcvs?rev=270434=gcc=rev
Log:
PR go/90110
compiler: use temporary to avoid early destruction

The code was passing a substr directly to strtol, and then checking
the *end value returned by strtol.  But the substr could be destroyed
as soon as strtol returns, making the test of *end invalid.

Also fix an incorrect test of the string index rather than the value.

Fixes https://gcc.gnu.org/PR90110

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/172663

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/gcc/go/gofrontend/import.cc

[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 fw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #8 from Florian Weimer  ---
(In reply to Ian Lance Taylor from comment #7)
> > 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.

I think the *end != '\0' check is the problem here.  The temporary object is
gone at that point.

[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 rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110

--- Comment #6 from rguenther at suse dot de  ---
On Wed, 17 Apr 2019, ian at airs dot com wrote:

> 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("   size_t start = this->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);

Just a wild guess - does this->body_.substr(start, i - start).c_str() 
really live until after strtol has completed?  IIRC I saw this kind
of errors in other codes...  since the temporary std::string isn't
passed to the function it should be destroyed.  Assuming this->body_
is a std::string, of course.

Using profiledbootstrap might just expose this "issue" I guess.

Trying whether

Index: gcc/go/gofrontend/import.cc
===
--- gcc/go/gofrontend/import.cc (revision 270403)
+++ gcc/go/gofrontend/import.cc (working copy)
@@ -1478,7 +1478,8 @@ Import_function_body::read_type()
   this->off_ = i + 1;

   char *end;
-  long val = strtol(this->body_.substr(start, i - start).c_str(), , 
10);
+  std::string subs = this->body_.substr(start, i - start);
+  long val = strtol(subs.c_str(), , 10);
   if (*end != '\0' || i > 0x7fff)
 {
   if (!this->saw_error_)

fixes the issue for me (will report back tomorrow).  Just in case
this is indeed an obvious error feel free to fix faster than that ;)

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

2019-04-17 Thread sch...@linux-m68k.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110

--- Comment #5 from Andreas Schwab  ---
What is the condition i > 0x7fff for?  Shouldn't that test val instead?

[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/90110] [9 Regression] libgo fails to build against glibc 2.19

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

--- Comment #3 from Richard Biener  ---
Btw, I just checked and the build also fails with glibc 2.22 in the same way.

Oddly enough it only fails in a controlled environment but not on a development
machine with the same glibc I do regular testing on.  (controlled environment
aka package builds for SLES 12 based distros)

I configure with

../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man
--libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--disable-werror --with-gxx-include-dir=/usr/include/c++/9 --enable-ssp
--disable-libssp --disable-libvtv --disable-cet --disable-libcc1
--disable-plugin --with-bugurl=https://bugs.opensuse.org/
'--with-pkgversion=SUSE Linux' --with-slibdir=/lib64 --with-system-zlib
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--with-default-libstdcxx-abi=gcc4-compatible --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-9 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux

and build like

setarch x86_64 -R make profiledbootstrap 'STAGE1_CFLAGS=-g -O2'
'BOOT_CFLAGS=-fmessage-length=0 -grecord-gcc-switches -O2 -D_FORTIFY_SOURCE=2
-funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE' -j3

the build uses trunk as of r270275

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

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

--- Comment #2 from Richard Biener  ---
Created attachment 46183
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46183=edit
32bit math.gox

Here it is.  The 64bit one looks similar btw.

[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 go/90110] [9 Regression] libgo fails to build against glibc 2.19

2019-04-16 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 Target||x86_64-*-*, i?86-*-*,
   ||ppc64le-*-*, aarch64-*-*,
   ||s390x-*-*
   Priority|P3  |P4
   Target Milestone|--- |9.0