[Bug libstdc++/80432] std::pow gives wrong results for long double arguments

2017-05-12 Thread theivorytower at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80432

Hao Zhang  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Hao Zhang  ---
The problem is now fixed with the latest gcc 7.1.1.

[Bug lto/80717] LTO wrappers segfault if run with absolute path

2017-05-12 Thread theivorytower at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80717

--- Comment #2 from Hao Zhang  ---
Thank you for your reply. For me basically any arguments with /usr/bin/gcc-ar
fails with segfault, even running /usr/bin/gcc-ar with no additional arguments
at all. 

When I run gcc-ar with gdb (here I don't even need to have the absolute path,
"gdb gcc-ar" fails with segfault), before line 203 of gcc-ar.c, the variable
path.plist consists of the following entries:

{0x6070a0 "/usr/local/sbin/",  0x607010 "/usr/local/bin/", 0x6073c0
"/usr/bin/", 0x607400 "/usr/lib/jvm/default/bin/", 0x607450
"/usr/bin/site_perl/", 0x607490 "/usr/bin/vendor_perl/", 0x6074d0
"/usr/bin/core_perl/"}

After line 203, /usr/bin/ is removed from the list of paths:

{0x6070a0 "/usr/local/sbin/",  0x607010 "/usr/local/bin/", 0x0 , 0x607400
"/usr/lib/jvm/default/bin/", 0x607450 "/usr/bin/site_perl/", 0x607490
"/usr/bin/vendor_perl/", 0x6074d0 "/usr/bin/core_perl/"}

Since the third item is set to 0, strcpy segfaults at file-find.c:81.

[Bug lto/80717] New: LTO wrappers segfault if run with absolute path

2017-05-11 Thread theivorytower at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80717

Bug ID: 80717
   Summary: LTO wrappers segfault if run with absolute path
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theivorytower at gmail dot com
  Target Milestone: ---

When I run any of the LTO wrappers (gcc-ar, gcc-nm, gcc-ranlib) with absolute
path (e.g. /usr/bin/gcc-ar), the program segfaults immediately. I tried to run
some debugging, and I found the culprit is in line 197-204 of gcc-ar.c.

Basically gcc-ar was trying to find ar, and "/usr/bin/" was removed from the
list of path to search for ar in line 203 of gcc-ar.c. As a result ar cannot be
found and the program segfaults.

I'm using Arch Linux and my gcc version info is as follows:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/hao/code/gcc/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,lto --enable-shared --enable-threads=posix
--enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib
--disable-werror --enable-checking=release
Thread model: posix
gcc version 7.1.1 20170508 (GCC)

[Bug libstdc++/80432] std::pow gives wrong results for long double arguments

2017-04-14 Thread theivorytower at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80432

--- Comment #3 from Hao Zhang  ---
(In reply to Hao Zhang from comment #2)
> (In reply to Martin Liška from comment #1)
> > Can't reproduce, can you please provide options you use to build the
> > executable?
> 
> I didn't use any extra options besides g++ pow.cpp, and both my CFLAGS and
> CXXFLAGS environment variables are empty. And I just found out moments ago
> compiling with -O1 gives the right result while compiling with -O0 gives the
> wrong result. I also tried to turn on each of the 42 optimizations provided
> by -O1 individually, and I found none of the 42 optimizations ALONE can get
> rid of the problem. So there must be some combinations of optimizations that
> can get rid of the problem. 
> 
> My glibc version is 2.25 and kernel version is 4.10.9. And I have reproduced
> the error on two different computers. Is there any other information I can
> provide to help pinpoint the problem? Thanks!

I also found out that g++ -O1 pow.cpp gives the expected results, while the
following command gives the wrong results:

g++ -fauto-inc-dec -fbranch-count-reg -fcombine-stack-adjustments
-fcompare-elim -fcprop-registers -fdce -fdefer-pop -fdelayed-branch -fdse
-fforward-propagate -fguess-branch-probability -fif-conversion2 -fif-conversion
-finline-functions-called-once -fipa-pure-const -fipa-profile -fipa-reference
-fmerge-constants -fmove-loop-invariants -freorder-blocks -fshrink-wrap
-fshrink-wrap-separate -fsplit-wide-types -fssa-backprop -fssa-phiopt
-ftree-bit-ccp -ftree-ccp -ftree-ch -ftree-coalesce-vars -ftree-copy-prop
-ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre
-ftree-phiprop -ftree-sink -ftree-slsr -ftree-sra -ftree-pta -ftree-ter
-funit-at-a-time -fomit-frame-pointer pow.cpp

This is weird, isn't the two forms of command equivalent?

[Bug libstdc++/80432] std::pow gives wrong results for long double arguments

2017-04-14 Thread theivorytower at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80432

--- Comment #2 from Hao Zhang  ---
(In reply to Martin Liška from comment #1)
> Can't reproduce, can you please provide options you use to build the
> executable?

I didn't use any extra options besides g++ pow.cpp, and both my CFLAGS and
CXXFLAGS environment variables are empty. And I just found out moments ago
compiling with -O1 gives the right result while compiling with -O0 gives the
wrong result. I also tried to turn on each of the 42 optimizations provided by
-O1 individually, and I found none of the 42 optimizations ALONE can get rid of
the problem. So there must be some combinations of optimizations that can get
rid of the problem. 

My glibc version is 2.25 and kernel version is 4.10.9. And I have reproduced
the error on two different computers. Is there any other information I can
provide to help pinpoint the problem? Thanks!

[Bug libstdc++/80432] New: std::pow gives wrong results for long double arguments

2017-04-14 Thread theivorytower at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80432

Bug ID: 80432
   Summary: std::pow gives wrong results for long double arguments
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theivorytower at gmail dot com
  Target Milestone: ---

With the latest gcc 7.0.1, whenever I pass long double arguments to std::pow,
the results are either nan or inf for most of the times. For example, the
following simple code outputs -nan while the expected result is 2:

#include 
#include 

int main() {
long double a = 4;
long double b = 0.5;
std::cout << std::pow(a, b) << std::endl;
}

If I set = 0.007 and b = 0.2, the output is inf while the expected result is
0.370697. The program behaves as expected if the arguments are double instead
of long double. The following is my gcc version info:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/hao/installers/aur-gcc-git/src/gcc/configure
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,lto --enable-shared --enable-threads=posix
--enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib
--disable-werror --enable-checking=release
Thread model: posix
gcc version 7.0.1 20170413 (experimental) (GCC)