[Bug bootstrap/81216] [8 Regression] bootstrap failed on i386 and powerpc64le

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Uuugh, sorry.

I'm testing a fix.  If it doesn't work out, I'll disable the warning
temporarily.

[Bug libstdc++/81221] [7/8 Regression] stl_algo.h: error: ‘__sample’ is not a member of ‘std’

[jeff.science at gmail dot com]

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

--- Comment #2 from Jeff Hammond  ---
Thank you!  Indeed, that fixes it, both when applied directly to the installed
header and when integrated into a build of the latest version.

$ g++-8 -std=gnu++17 -g -O3 -mtune=native -D_GLIBCXX_PARALLEL -fopenmp
test.cc&& echo "SUCCESS" || echo "FAIL"
SUCCESS

$ g++-8 -v
Using built-in specs.
COLLECT_GCC=g++-8
COLLECT_LTO_WRAPPER=/opt/gcc/HEAD/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /opt/gcc//git/configure --program-suffix=-8 --disable-multilib
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --enable-languages=c,c++,fortran --with-tune=native
--enable-bootstrap --enable-lto --enable-gold=yes --enable-ld=yes
--prefix=/opt/gcc//HEAD : (reconfigured) /opt/gcc//git/configure
--program-suffix=-8 --disable-multilib --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--enable-languages=c,c++,fortran --with-tune=native --enable-bootstrap
--enable-lto --enable-gold=yes --enable-ld=yes --prefix=/opt/gcc//HEAD
Thread model: posix
gcc version 8.0.0 20170627 (experimental) (GCC)

[Bug bootstrap/81216] [8 Regression] bootstrap failed on i386 and powerpc64le

[paul.hua.gm at gmail dot com]

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

Paul Hua  changed:

   What|Removed |Added

 CC||paul.hua.gm at gmail dot com

--- Comment #6 from Paul Hua  ---
saw this on mips64el-linux-gnu target.

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

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

--- Comment #56 from Daniel Santos  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #55)
> > --- Comment #54 from Daniel Santos  ---
> > Created attachment 41627 [details]
> >   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41627=edit
> > darwin fixup (on top of v6) -- second attempt
> [...]
> > The macro has only two uses, so if you prefer, I can remove it and just 
> > replace
> > it with inline #if blocks, e.g.,
> >
> > #ifdef __MACH__
> > "   mov " ASMNAME(test_data) "@GOTPCREL(%%rip), %%rax\n"
> > #else
> > "   lea " ASMNAME(test_data) "(%%rip), %%rax\n"
> > #endif
> 
> I'm fine either way, with a slight preference for the macro version (the
> less code duplication, the better ;-)

That's fine with me. :)  


> I've tested this patch last night on both x86_64-apple-darwin11.4.2 and
> i386-pc-solaris2.12 and it worked just fine on both!
> 
> Thanks a lot.
> 
>   Rainer

Wonderful! I presume that we still need libgcc buy-off?  I'll put together a
ChangeLog and post it to gcc-patches tomorrow.

Thanks!
Daniel

[Bug target/81193] PowerPC GCC __builtin_cpu_is and __builtin_cpu_supports should warn about old libraries

[amodra at gmail dot com]

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

--- Comment #6 from Alan Modra  ---
> Alternatively, we would need to do two passes.  On the first pass resolve all
> of the normal functions and data locations, setting the location of ifunc
> functions in the TOC to be an error function.  The second pass would resolve
> the ifunc functions.  If an ifunc function calls another ifunc function that
> hasn't been resolved yet, it would go to the error function.

Don't hold your breath waiting for this solution.  It was proposed first here:
https://gcc.gnu.org/ml/gcc-patches/2009-07/msg01307.html

[Bug libstdc++/81221] [7/8 Regression] stl_algo.h: error: ‘__sample’ is not a member of ‘std’

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |7.2

--- Comment #1 from Jonathan Wakely  ---
This should fix it:

--- a/libstdc++-v3/include/bits/stl_algo.h
+++ b/libstdc++-v3/include/bits/stl_algo.h
@@ -5831,8 +5831,9 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
"sample size must be an integer type");

   typename iterator_traits<_PopulationIterator>::difference_type __d =
__n;
-  return std::__sample(__first, __last, __pop_cat{}, __out, __samp_cat{},
-  __d, std::forward<_UniformRandomBitGenerator>(__g));
+  return _GLIBCXX_STD_A::
+   __sample(__first, __last, __pop_cat{}, __out, __samp_cat{}, __d,
+std::forward<_UniformRandomBitGenerator>(__g));
 }
 #endif // C++17
 #endif // C++14

[Bug libstdc++/81221] [7/8 Regression] stl_algo.h: error: ‘__sample’ is not a member of ‘std’

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-27
 Ever confirmed|0   |1

[Bug target/81193] PowerPC GCC __builtin_cpu_is and __builtin_cpu_supports should warn about old libraries

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner  ---
Given Alan's comments, I think the best thing to do here is to just emit a
warning when using those builtins when the compiler was configured to use an
old glibc.  

If someone disagrees, let me know now, as I'm going to start coding up the
change to add the warning.

[Bug libstdc++/81221] New: stl_algo.h: error: ‘__sample’ is not a member of ‘std’

[jeff.science at gmail dot com]

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

Bug ID: 81221
   Summary: stl_algo.h: error: ‘__sample’ is not a member of ‘std’
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.science at gmail dot com
  Target Milestone: ---

The trivial parallel STL example from the documentation
(https://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode_using.html) does
not compile with GCC 7.1.0 or 8.0.0 (compiled on June 4, 2017).

$ cat test.cc 
#include 
#include 

int main()
{
std::vector v(100);
__gnu_parallel::sort(v.begin(), v.end());
return 0;
}


$ g++-8 -v
Using built-in specs.
COLLECT_GCC=g++-8
COLLECT_LTO_WRAPPER=/opt/gcc/HEAD/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /opt/gcc//git/configure --program-suffix=-8 --disable-multilib
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --enable-languages=c,c++,fortran --with-tune=native
--enable-bootstrap --enable-lto --enable-gold=yes --enable-ld=yes
--prefix=/opt/gcc//HEAD
Thread model: posix
gcc version 8.0.0 20170604 (experimental) (GCC) 

$ g++-8 -std=gnu++17 -g -O3 -mtune=native -D_GLIBCXX_PARALLEL -fopenmp test.cc 
In file included from /opt/gcc/HEAD/include/c++/8.0.0/algorithm:62:0,
 from /opt/gcc/HEAD/include/c++/8.0.0/parallel/algorithm:34,
 from test.cc:2:
/opt/gcc/HEAD/include/c++/8.0.0/bits/stl_algo.h: In function ‘_SampleIterator
std::__cxx1998::sample(_PopulationIterator, _PopulationIterator,
_SampleIterator, _Distance, _UniformRandomBitGenerator&&)’:
/opt/gcc/HEAD/include/c++/8.0.0/bits/stl_algo.h:5834:19: error: ‘__sample’ is
not a member of ‘std’
   return std::__sample(__first, __last, __pop_cat{}, __out, __samp_cat{},
   ^~~~
/opt/gcc/HEAD/include/c++/8.0.0/bits/stl_algo.h:5834:19: note: suggested
alternative: ‘is_same’
   return std::__sample(__first, __last, __pop_cat{}, __out, __samp_cat{},
   ^~~~
   is_same

$ g++-7 -v
Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/opt/gcc/7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/opt/gcc/7.1.0 --program-suffix=-7
--enable-shared --enable-static --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--enable-languages=c,c++,fortran --with-tune=native --enable-bootstrap
--enable-lto --enable-gold=yes --enable-ld=yes --disable-multilib
Thread model: posix
gcc version 7.1.0 (GCC) 

$ g++-7 -std=gnu++17 -g -O3 -mtune=native -D_GLIBCXX_PARALLEL -fopenmp test.cc 
In file included from /opt/gcc/7.1.0/include/c++/7.1.0/algorithm:62:0,
 from /opt/gcc/7.1.0/include/c++/7.1.0/parallel/algorithm:34,
 from test.cc:2:
/opt/gcc/7.1.0/include/c++/7.1.0/bits/stl_algo.h: In function ‘_SampleIterator
std::__cxx1998::sample(_PopulationIterator, _PopulationIterator,
_SampleIterator, _Distance, _UniformRandomBitGenerator&&)’:
/opt/gcc/7.1.0/include/c++/7.1.0/bits/stl_algo.h:5812:19: error: ‘__sample’ is
not a member of ‘std’
   return std::__sample(__first, __last, __pop_cat{}, __out, __samp_cat{},
   ^~~~
/opt/gcc/7.1.0/include/c++/7.1.0/bits/stl_algo.h:5812:19: note: suggested
alternative: ‘is_same’
   return std::__sample(__first, __last, __pop_cat{}, __out, __samp_cat{},
   ^~~~
   is_same

It does not build with the standard namespace either...

$ cat test.cc c
#include 
#include 

int main()
{
std::vector v(100);
std::sort(v.begin(), v.end());
return 0;
}

$ g++-7 -std=gnu++17 -g -O3 -mtune=native -D_GLIBCXX_PARALLEL -fopenmp test.cc 
In file included from /opt/gcc/7.1.0/include/c++/7.1.0/algorithm:62:0,
 from /opt/gcc/7.1.0/include/c++/7.1.0/parallel/algorithm:34,
 from test.cc:2:
/opt/gcc/7.1.0/include/c++/7.1.0/bits/stl_algo.h: In function ‘_SampleIterator
std::__cxx1998::sample(_PopulationIterator, _PopulationIterator,
_SampleIterator, _Distance, _UniformRandomBitGenerator&&)’:
/opt/gcc/7.1.0/include/c++/7.1.0/bits/stl_algo.h:5812:19: error: ‘__sample’ is
not a member of ‘std’
   return std::__sample(__first, __last, __pop_cat{}, __out, __samp_cat{},
   ^~~~
/opt/gcc/7.1.0/include/c++/7.1.0/bits/stl_algo.h:5812:19: note: suggested
alternative: ‘is_same’
   return std::__sample(__first, __last, __pop_cat{}, __out, __samp_cat{},
   ^~~~
   is_same

$ g++-8 -std=gnu++17 -g -O3 -mtune=native -D_GLIBCXX_PARALLEL -fopenmp test.cc 
In file included from /opt/gcc/HEAD/include/c++/8.0.0/algorithm:62:0,
 from /opt/gcc/HEAD/include/c++/8.0.0/parallel/algorithm:34,
 

[Bug other/81220] [8 regression] ICE during gcc build after r249643

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from seurer at gcc dot gnu.org ---
Duplicate of 81216

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

[Bug bootstrap/81216] [8 Regression] bootstrap failed on i386 and powerpc64le

[seurer at gcc dot gnu.org]

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

--- Comment #5 from seurer at gcc dot gnu.org ---
*** Bug 81220 has been marked as a duplicate of this bug. ***

[Bug bootstrap/81216] [8 Regression] bootstrap failed on i386 and powerpc64le

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #4 from seurer at gcc dot gnu.org ---
On powerpc LE this will occur when building the libraries on stage1, no
bootstrap build needed.  And it is definitely r249643.

[Bug other/81220] New: [8 regression] ICE during gcc build after r249643

[seurer at gcc dot gnu.org]

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

Bug ID: 81220
   Summary: [8 regression] ICE during gcc build after r249643
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This was on a powerpc64 LE system.  I tried this on powerpc64 BE and did not
see the same issue nor when I tried on x86.  r249642 works fine.

It occurs when the just built compiler is being used to build some of the
libraries:

make
. . .
make[5]: Entering directory
`/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/c++98'
/bin/bash ../../libtool --tag CXX --tag disable-shared   --mode=compile
/home/seurer/gcc/build/gcc-test3/./gcc/xgcc -shared-libgcc
-B/home/seurer/gcc/build/gcc-test3/./gcc -nostdinc++
-L/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/install/gcc-test3/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/install/gcc-test3/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/install/gcc-test3/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/install/gcc-test3/powerpc64le-unknown-linux-gnu/sys-include   
-I/home/seurer/gcc/gcc-test3/libstdc++-v3/../libgcc
-I/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test3/libstdc++-v3/libsupc++   -std=gnu++98 -prefer-pic
-D_GLIBCXX_SHARED -fno-implicit-templates  -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi  -fdiagnostics-show-location=once   -ffunction-sections
-fdata-sections  -frandom-seed=codecvt.lo -g -O2 -D_GNU_SOURCE  -c -o
codecvt.lo /home/seurer/gcc/gcc-test3/libstdc++-v3/src/c++98/codecvt.cc
libtool: compile:  /home/seurer/gcc/build/gcc-test3/./gcc/xgcc -shared-libgcc
-B/home/seurer/gcc/build/gcc-test3/./gcc -nostdinc++
-L/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/install/gcc-test3/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/install/gcc-test3/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/install/gcc-test3/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/install/gcc-test3/powerpc64le-unknown-linux-gnu/sys-include
-I/home/seurer/gcc/gcc-test3/libstdc++-v3/../libgcc
-I/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test3/libstdc++-v3/libsupc++ -std=gnu++98
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=codecvt.lo -g -O2 -D_GNU_SOURCE -c
/home/seurer/gcc/gcc-test3/libstdc++-v3/src/c++98/codecvt.cc  -fPIC -DPIC
-D_GLIBCXX_SHARED -o codecvt.o
In file included from
/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/char_traits.h:39:0,
 from
/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/string:40,
 from
/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/locale_classes.h:40,
 from
/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/locale:39,
 from
/home/seurer/gcc/gcc-test3/libstdc++-v3/src/c++98/codecvt.cc:25:
/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:
In static member function 'static bool std::__equal<_BoolType>::equal(_II1,
_II1, _II2)':
/home/seurer/gcc/build/gcc-test3/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:801:20:
internal compiler error: Segmentation fault
return false;
^
0x10c37543 crash_signal
/home/seurer/gcc/gcc-test3/gcc/toplev.c:338
0x116a0870 linemap_location_from_macro_expansion_p(line_maps const*, unsigned
int)
/home/seurer/gcc/gcc-test3/libcpp/line-map.c:1253

[Bug libfortran/81195] SPEC CPU2017 621.wrf_s failure with 40+ openmp threads

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

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

--- Comment #11 from Jim Wilson  ---
Fixed on trunk and gcc 7 branch.

[Bug libfortran/81195] SPEC CPU2017 621.wrf_s failure with 40+ openmp threads

[wilson at gcc dot gnu.org]

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

--- Comment #10 from Jim Wilson  ---
Author: wilson
Date: Mon Jun 26 21:44:50 2017
New Revision: 249668

URL: https://gcc.gnu.org/viewcvs?rev=249668=gcc=rev
Log:
Fix for SPEC CPu2017 621.wrf_s failure, add missing locking code.

libgfortran/
Backport from trunk
PR libfortran/81195
* io/unit.c (get_unit): Call __gthread_mutex_lock before newunit_stack
and newunit_tos references.  Call __gthread_mutex_unlock afterward.

Modified:
branches/gcc-7-branch/libgfortran/ChangeLog
branches/gcc-7-branch/libgfortran/io/unit.c

[Bug libfortran/81195] SPEC CPU2017 621.wrf_s failure with 40+ openmp threads

[wilson at gcc dot gnu.org]

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

--- Comment #9 from Jim Wilson  ---
Author: wilson
Date: Mon Jun 26 21:40:47 2017
New Revision: 249667

URL: https://gcc.gnu.org/viewcvs?rev=249667=gcc=rev
Log:
Fix for SPEC CPU2017 621.wrf_s failure, add missing locking code.

libgfortran/
PR libfortran/81195
* io/unit.c (get_unit): Call __gthread_mutex_lock before newunit_stack
and newunit_tos references.  Call __gthread_mutex_unlock afterward.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/unit.c

[Bug libgcc/81218] libgcc_s.so.1 call to __get_cpuid does not correctly code around 486 cpus lacking cpuid instruction

[tedheadster at gmail dot com]

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

--- Comment #2 from Matthew Whitehead  ---
Here is a better backtrace with more symbols added:

#0  0xb750a142 in __get_cpuid (__edx=0xbf9be478, __ecx=0xbf9be474,
__ebx=0xbf9be470, __eax=0xbf9be46c, __level=0)
at
/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/gcc/include/cpuid.h:2\
42

#1  __get_cpuid_output (__level=__level@entry=0, __eax=__eax@entry=0xbf9be46c,
__ebx=__ebx@entry=0xbf9be470, __ecx=0xbf9be474, __edx=0xbf9be478)
at
/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libgcc/config/i38\
6/cpuinfo.c:337

#2  0xb750a1ba in __cpu_indicator_init ()
at
/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libgcc/config/i38\
6/cpuinfo.c:362

#3  0xb778d5b6 in call_init (l=, argc=argc@entry=1,
argv=argv@entry=0xbf9be524, env=0xbf9be52c) at dl-init.c:72

#4  0xb778d6dd in call_init (env=0xbf9be52c, argv=0xbf9be524, argc=1,
l=) at dl-init.c:30

#5  _dl_init (main_map=, argc=1, argv=0xbf9be524,
env=0xbf9be52c) at dl-init.c:120

#6  0xb777d9cf in _dl_start_user () from /lib/ld-linux.so.2

[Bug target/81158] [8 regression] Many test case failures starting with r249424

[seurer at gcc dot gnu.org]

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

--- Comment #3 from seurer at gcc dot gnu.org ---
I tried 249423 and don't see those failures but do with 249424.

For example:

seurer@genoa:~/gcc/build/gcc-test$ updategcc 249423
seurer@genoa:~/gcc/build/gcc-test$ make -j50
seurer@genoa:~/gcc/build/gcc-test$ make -k check-gcc
RUNTESTFLAGS=execute.exp=gcc.c-torture/execute/pr51581-1.c 2>&1 >
make.249423.out
seurer@genoa:~/gcc/build/gcc-test$ grep FAIL make.249423.out 
seurer@genoa:~/gcc/build/gcc-test$ 

seurer@genoa:~/gcc/build/gcc-test$ updategcc 249424
seurer@genoa:~/gcc/build/gcc-test$ make -j50
seurer@genoa:~/gcc/build/gcc-test$ make -k check-gcc
RUNTESTFLAGS=execute.exp=gcc.c-torture/execute/pr51581-1.c 2>&1 >
make.249424.out

seurer@genoa:~/gcc/build/gcc-test$ grep FAIL make.249424.out 
FAIL: gcc.c-torture/execute/pr51581-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.c-torture/execute/pr51581-1.c   -O3 -g  execution test

[Bug bootstrap/81216] [8 Regression] bootstrap failed on i386

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-26
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Bill Schmidt  ---
I tested with my patch reverted, and the problem still occurs.  I believe this
is r249643.  CCing Marek.

Confirmed, btw.

[Bug middle-end/35307] Missing Simplication for div op

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #4 from Segher Boessenkool  ---
Cannot work in the general case.

[Bug bootstrap/81216] [8 Regression] bootstrap failed on i386

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Bill Schmidt from comment #1)
> Hm, are you sure about the revision?  Folks have been testing broken
> bootstrap on ppc64le with the same symptoms and narrowed it down to r249643.
> 
> I will try to confirm the breakage and see if backing out my change fixes it.

I am verifying it now.

[Bug target/68491] libgcc calls __get_cpuid with 0 level breaks on early 486

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||tedheadster at gmail dot com

--- Comment #8 from Uroš Bizjak  ---
*** Bug 81218 has been marked as a duplicate of this bug. ***

[Bug libgcc/81218] libgcc_s.so.1 call to __get_cpuid does not correctly code around 486 cpus lacking cpuid instruction

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #1 from Uroš Bizjak  ---
This will be fixed in gcc-5.5.

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

[Bug fortran/81205] Hybrid MPI and OpenMp: Blocking code in loops

[pasha.313 at hotmail dot com]

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

--- Comment #7 from Pasha  ---
(In reply to Harald Anlauf from comment #6)
> (In reply to Pasha from comment #5)
> > (In reply to Harald Anlauf from comment #4)
> > > (In reply to Pasha from comment #2)
> > > > This is my main routine for example
> > > > .
> > > > .
> > > > .
> > > > !!$OMP PARALLEL DO DEFAULT(SHARED) PRIVATE(K,jL)
> > > > DO k=1,nG3
> > > >DO jL=1,nL2
> > > >   j = idx2start + jL
> > > 
> > > Any reason you didn't declare j as private?
> > That did not solve the problem as I have other subroutines in main which
> > declared all of index number in main program and in subroutines but again
> > the code Blocks. Even when I disabled OMP commands in the loop of main
> > program, the code get inside the subroutine but again blocks in the loop of
> > that subroutines.
> > I used ulimit -s 1000 or ulimit -Hd to increase the capacity of each CPU
> > but still get nowhere.   
> 
> You're saying your code blocks even without OpenMP?
> Then it's not an OpenMP problem.
No it works with OpenMp. Actually 60% of code works with OpenMp without having
any problems right now. But Please imagine this program

Program A
.
.
!$OMP Parallel ..
Do I=1, 100
   call B(...)   => main program
End do 
!$OMP End 
.
.
end program

Subroutine B
.
.
!$OMP Parallel ..
Do I=1, 100
   D=.   => subroutine
End do 
!$OMP ENd 

end Subroutine B

in any subroutines which is called inside of a loop and also that subroutine
has one or more loops I faced with this problem. I disabled OMP commands in
main program first to check whether the problem was solved but it blocked again
so I disabled OMP commands in those subroutines. The program run after that. In
the rest of the code OMP works well. But I could not parallel those loops and
subroutines. 


> 
> Your comments sound your code has a more serious issue that
> cannot be understood given the code parts you've shown.
> 
> > > 
> > > >   IF(masque(j,k))THEN
> > > > 
> > > >  ! dudx
> > > >  CALL fvec (nG1,curC(1:nG1,jL,k), difles1C(1:nG1,jL,k))
> > > >  CALL tridgn (ff,s1,w1,difles1C(1:nG1,jL,k), nG1,1)
> > > >   ENDIF
> > > >ENDDO
> > > > ENDDO
> > > > !!$OMP END PARALLEL DO
> > > 
> > > Have you tried some thread-checking tool to debug the code,
> > > or cross-checked with another compiler?
> > 
> > Some of my friends suggested to compile the code with ifort, but I do not
> > access to that. I asked my supervisor to buy or find it on other lab to
> > check it.
> > Will you please offer a name of thread-checking tools? can I do it with
> > visual studio? or you mean something else?
> 
> I can't say anything about visual whatever.
> 
> I'd recommend valgrind (for memory and thread checking),
> or a newer gcc release supporting thread and memory sanitizing.
> 
> With the Intel compiler (you could try an evaluation license) I've
> used the tools belonging to the Intel suite for doing the same.  They
> have a fancy GUI, if that's what you prefer.

I will try and will let you now.

[Bug bootstrap/81216] [8 Regression] bootstrap failed on i386

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #1 from Bill Schmidt  ---
Hm, are you sure about the revision?  Folks have been testing broken bootstrap
on ppc64le with the same symptoms and narrowed it down to r249643.

I will try to confirm the breakage and see if backing out my change fixes it.

[Bug c++/81204] [7/8 Regression] Rejects boost headers

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug bootstrap/81219] [8 regression] SEGV in linemap_location_from_macro_expansion_p

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug bootstrap/81219] New: [8 regression] SEGV in linemap_location_from_macro_expansion_p

[ro at gcc dot gnu.org]

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

Bug ID: 81219
   Summary: [8 regression] SEGV in
linemap_location_from_macro_expansion_p
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---
Target: i386-pc-solaris2.12, i686-pc-linux-gnu,
sparc-sun-solaris2.12

Between 20170625 (r249632) and 20170626 (r249656), bootstrap broke on several
targets.

E.g on i686-pc-linux-gnu and sparc-sun-solaris2.12, building stage2 libstdc++:

In file included from
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include/bits/char_traits.h:39:0,
 from
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include/string:40,
 from
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include/bits/locale_classes.h:40,
 from
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include/bits/ios_base.h:41,
 from
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include/streambuf:41,
 from
/vol/gcc/src/hg/trunk/local/libstdc++-v3/src/c++98/streambuf.cc:29:
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include/bits/stl_algobase.h:
In static member function âstatic bool std::__equal<_BoolType>::equal(_II1,
_II1, _II2)â:
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include/bits/stl_algobase.h:801:20:
internal compiler error: Segmentation Fault
return false;
^
0x15201ff crash_signal
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:338
0x20c3ea0 linemap_location_from_macro_expansion_p(line_maps const*, unsigned
int)
/vol/gcc/src/hg/trunk/local/libcpp/line-map.c:1254
0x20c3e6b linemap_location_from_macro_expansion_p(line_maps const*, unsigned
int)
/vol/gcc/src/hg/trunk/local/libcpp/line-map.c:1252

cc1plus -quiet -nostdinc++ -v -I
/vol/gcc/src/hg/trunk/local/libstdc++-v3/../libgcc -I
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include/sparc-sun-solaris2.12
-I
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include
-I /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++ -iprefix
/var/gcc/regression/trunk/12-gcc/build.bad/gcc/../lib/gcc/sparc-sun-solaris2.12/8.0.0/
-isystem /var/gcc/regression/trunk/12-gcc/build.bad/./gcc/include -isystem
/var/gcc/regression/trunk/12-gcc/build.bad/./gcc/include-fixed -D__sparcv8 -D
_GLIBCXX_SHARED -D PIC -D _GLIBCXX_SHARED -isystem
/vol/gcc/sparc-sun-solaris2.12/include -isystem
/vol/gcc/sparc-sun-solaris2.12/sys-include
/vol/gcc/src/hg/trunk/local/libstdc++-v3/src/c++98/streambuf.cc -quiet
-dumpbase streambuf.cc -mcpu=v9 -auxbase-strip streambuf.o -g -O2 -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi -std=gnu++98 -version -fno-implicit-templates
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=streambuf.lo -fPIC -o streambuf.s

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x020c3ea0 in linemap_location_from_macro_expansion_p (set=0xfbbf6000, 
location=4209776568) at /vol/gcc/src/hg/trunk/local/libcpp/line-map.c:1254
1254 &
MAX_SOURCE_LOCATION].locus;
(gdb) where
#0  0x020c3ea0 in linemap_location_from_macro_expansion_p (set=0xfbbf6000, 
location=4209776568) at /vol/gcc/src/hg/trunk/local/libcpp/line-map.c:1254
#1  0x00cb2e78 in warn_for_multistatement_macros (body_loc=4209776568, 
next_loc=72017509, guard_loc=72005218, keyword=RID_FOR)
at /vol/gcc/src/hg/trunk/local/gcc/c-family/c-warn.c:2431
#2  0x009e72c4 in cp_parser_already_scoped_statement (parser=0xfac27e98, 
if_p=0x0, guard_tinfo=...)
at /vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:12452
#3  0x009e6348 in cp_parser_iteration_statement (parser=0xfac27e98, if_p=0x0, 
ivdep=false) at /vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:12113
#4  0x009e1b34 in cp_parser_statement (parser=0xfac27e98, 
in_statement_expr=0x0, in_compound=true, if_p=0x0, chain=0x0, 
loc_after_labels=0x0) at /vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:10696
#5  0x009e3264 in cp_parser_statement_seq_opt (parser=0xfac27e98, 
in_statement_expr=0x0) at /vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:11165
#6  0x009e30f0 in cp_parser_compound_statement (parser=0xfac27e98, 
in_statement_expr=0x0, bcs_flags=0, function_body=true)
at /vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:9
#7  0x009fed84 in cp_parser_function_body (parser=0xfac27e98, 
in_function_try_block=false)
at /vol/gcc/sr

[Bug libgcc/81218] New: libgcc_s.so.1 call to __get_cpuid does not correctly code around 486 cpus lacking cpuid instruction

[tedheadster at gmail dot com]

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

Bug ID: 81218
   Summary: libgcc_s.so.1 call to __get_cpuid does not correctly
code around 486 cpus lacking cpuid instruction
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tedheadster at gmail dot com
  Target Milestone: ---

Programs calling libgcc_s.so.1 are failing with an "illegal instruction" signal
on old i486 processors that do not support the cpuid instruction. Later i486
had the instruction, but earlier ones lacked it. The code looks like it
attempts to detect support for the instruction, but it is not working. 

Below is a backtrace (with only partial symbols available):

(gdb) bt
#0  0xb74b5142 in __get_cpuid (__edx=0xbfe5fd18, __ecx=0xbfe5fd14,
__ebx=0xbfe5fd10, __eax=0xbfe5fd0c, __level=0)
at
/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/gcc/include/cpuid.h:2\
42

#1  __get_cpuid_output (__level=__level@entry=0, __eax=__eax@entry=0xbfe5fd0c,
__ebx=__ebx@entry=0xbfe5fd10, __ecx=0xbfe5fd14, __edx=0xbfe5fd18)
at
/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libgcc/config/i38\
6/cpuinfo.c:337

#2  0xb74b51ba in __cpu_indicator_init ()
at
/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libgcc/config/i38\
6/cpuinfo.c:362

#3  0xb77385b6 in ?? () from /lib/ld-linux.so.2
#4  0xb77386dd in ?? () from /lib/ld-linux.so.2
#5  0xb77289cf in ?? () from /lib/ld-linux.so.2
(gdb)

I can move the hard drive between an i486DX/75 and an x86_64 machine. It fails
on the i486 and succeeds on the x86_64 machine.

[Bug bootstrap/81217] Makefile:22754: warning: overriding recipe for target 'profiledbootstrap'

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Confirmed, I saw this over the weekend also.

[Bug bootstrap/81217] Makefile:22754: warning: overriding recipe for target 'profiledbootstrap'

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

[Bug bootstrap/81217] New: Makefile:22754: warning: overriding recipe for target 'profiledbootstrap'

[hjl.tools at gmail dot com]

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

Bug ID: 81217
   Summary: Makefile:22754: warning: overriding recipe for target
'profiledbootstrap'
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: mliska at suse dot cz
  Target Milestone: ---

r249366 caused:

Makefile:22754: warning: overriding recipe for target 'profiledbootstrap'
Makefile:22614: warning: ignoring old recipe for target 'profiledbootstrap'
Makefile:22765: warning: overriding recipe for target 'profiledbootstrap-lean'
Makefile:22625: warning: ignoring old recipe for target
'profiledbootstrap-lean'
[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory
'/export/gnu/import/git/gcc-regression-bootstrap/mas
ter/249645/bld'
Makefile:22754: warning: overriding recipe for target 'profiledbootstrap'
Makefile:22614: warning: ignoring old recipe for target 'profiledbootstrap'
Makefile:22765: warning: overriding recipe for target 'profiledbootstrap-lean'
Makefile:22625: warning: ignoring old recipe for target
'profiledbootstrap-lean'
make[2]: Entering directory
'/export/gnu/import/git/gcc-regression-bootstrap/mas
ter/249645/bld'
Makefile:22754: warning: overriding recipe for target 'profiledbootstrap'
Makefile:22614: warning: ignoring old recipe for target 'profiledbootstrap'
Makefile:22765: warning: overriding recipe for target 'profiledbootstrap-lean'
Makefile:22625: warning: ignoring old recipe for target
'profiledbootstrap-lean'
make[2]: Leaving directory
'/export/gnu/import/git/gcc-regression-bootstrap/mast
er/249645/bld'
make[2]: Entering directory
'/export/gnu/import/git/gcc-regression-bootstrap/mas
ter/249645/bld'
Makefile:22754: warning: overriding recipe for target 'profiledbootstrap'
Makefile:22614: warning: ignoring old recipe for target 'profiledbootstrap'
Makefile:22765: warning: overriding recipe for target 'profiledbootstrap-lean'
Makefile:22625: warning: ignoring old recipe for target
'profiledbootstrap-lean'

[Bug rtl-optimization/81194] [8 Regression] ICE during RTL pass: expand

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

--- Comment #7 from Peter Bergner  ---
Ok, with -O2 -std=c++17 -fno-exceptions I have it recreated.  I'll have a look.

[Bug sanitizer/81209] [7/8 Regression] -fsanitize=undefined ICE on darwin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-26
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 41635
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41635=edit
gcc8-pr81209.patch

Untested fix.

[Bug bootstrap/81216] New: [8 Regression] bootstrap failed on i386

[hjl.tools at gmail dot com]

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

Bug ID: 81216
   Summary: [8 Regression] bootstrap failed on i386
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: wschmidt at linux dot vnet.ibm.com
  Target Milestone: ---

On i386, r249648 gave

libtool: compile:  /export/gnu/import/git/gcc-test-ia32/bld/./gcc/xgcc
-shared-libgcc -B/export/gnu/import/git/gcc-test-ia32/bld/./gcc -nostdinc++
-L/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/src
-L/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/src/.libs
-L/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/libsupc++/.libs
-B/usr/8.0.0/i686-linux/bin/ -B/usr/8.0.0/i686-linux/lib/ -isystem
/usr/8.0.0/i686-linux/include -isystem /usr/8.0.0/i686-linux/sys-include
-I/export/gnu/import/git/gcc-test-ia32/src-trunk/libstdc++-v3/../libgcc
-I/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include/i686-linux
-I/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include
-I/export/gnu/import/git/gcc-test-ia32/src-trunk/libstdc++-v3/libsupc++
-std=gnu++98 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=codecvt.lo -g -O2
-D_GNU_SOURCE -c ../../../../../src-trunk/libstdc++-v3/src/c++98/codecvt.cc 
-fPIC -DPIC -D_GLIBCXX_SHARED -o codecvt.o
In file included from
/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include/bits/char_traits.h:39:0,
 from
/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include/string:40,
 from
/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include/bits/locale_classes.h:40,
 from
/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include/locale:39,
 from
../../../../../src-trunk/libstdc++-v3/src/c++98/codecvt.cc:25:
/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include/bits/stl_algobase.h:
In static member function ‘static bool std::__equal<_BoolType>::equal(_II1,
_II1, _II2)’:
/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include/bits/stl_algobase.h:801:20:
internal compiler error: Segmentation fault
return false;
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Makefile:565: recipe for target 'codecvt.lo' failed
make[9]: *** [codecvt.lo] Error 1
make[9]: *** Waiting for unfinished jobs
make[9]: Leaving directory
'/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/src/c++98'
Makefile:641: recipe for target 'all-recursive' failed
make[8]: *** [all-recursive] Error 1
make[8]: Leaving directory
'/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/src'
Makefile:510: recipe for target 'all-recursive' failed
make[7]: *** [all-recursive] Error 1
make[7]: Leaving directory
'/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3'
Makefile:417: recipe for target 'all' failed
make[6]: *** [all] Error 2
make[6]: Leaving directory
'/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3'
Makefile:15088: recipe for target 'all-stage2-target-libstdc++-v3' failed
make[5]: *** [all-stage2-target-libstdc++-v3] Error 2
make[5]: Leaving directory '/export/gnu/import/git/gcc-test-ia32/bld'
Makefile:24033: recipe for target 'stage2-bubble' failed
make[4]: *** [stage2-bubble] Error 2
make[4]: Leaving directory '/export/gnu/import/git/gcc-test-ia32/bld'
Makefile:24236: recipe for target 'bootstrap' failed
make[3]: *** [bootstrap] Error 2

r249645 is OK.  GCC is configured with

 --prefix=/usr/8.0.0 --enable-clocale=gnu --with-system-zlib --enable-shared
--with-demangler-in-ld --enable-libmpx i686-linux --with-fpmath=sse

[Bug fortran/81205] Hybrid MPI and OpenMp: Blocking code in loops

[anlauf at gmx dot de]

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

--- Comment #6 from Harald Anlauf  ---
(In reply to Pasha from comment #5)
> (In reply to Harald Anlauf from comment #4)
> > (In reply to Pasha from comment #2)
> > > This is my main routine for example
> > > .
> > > .
> > > .
> > > !!$OMP PARALLEL DO DEFAULT(SHARED) PRIVATE(K,jL)
> > > DO k=1,nG3
> > >DO jL=1,nL2
> > >   j = idx2start + jL
> > 
> > Any reason you didn't declare j as private?
> That did not solve the problem as I have other subroutines in main which
> declared all of index number in main program and in subroutines but again
> the code Blocks. Even when I disabled OMP commands in the loop of main
> program, the code get inside the subroutine but again blocks in the loop of
> that subroutines.
> I used ulimit -s 1000 or ulimit -Hd to increase the capacity of each CPU
> but still get nowhere.   

You're saying your code blocks even without OpenMP?
Then it's not an OpenMP problem.

Your comments sound your code has a more serious issue that
cannot be understood given the code parts you've shown.

> > 
> > >   IF(masque(j,k))THEN
> > > 
> > >  ! dudx
> > >  CALL fvec (nG1,curC(1:nG1,jL,k), difles1C(1:nG1,jL,k))
> > >  CALL tridgn (ff,s1,w1,difles1C(1:nG1,jL,k), nG1,1)
> > >   ENDIF
> > >ENDDO
> > > ENDDO
> > > !!$OMP END PARALLEL DO
> > 
> > Have you tried some thread-checking tool to debug the code,
> > or cross-checked with another compiler?
> 
> Some of my friends suggested to compile the code with ifort, but I do not
> access to that. I asked my supervisor to buy or find it on other lab to
> check it.
> Will you please offer a name of thread-checking tools? can I do it with
> visual studio? or you mean something else?

I can't say anything about visual whatever.

I'd recommend valgrind (for memory and thread checking),
or a newer gcc release supporting thread and memory sanitizing.

With the Intel compiler (you could try an evaluation license) I've
used the tools belonging to the Intel suite for doing the same.  They
have a fancy GUI, if that's what you prefer.

[Bug c++/81215] [7/8 Regression] deduction failure with variadic template template parameter

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Mon Jun 26 18:49:25 2017
New Revision: 249665

URL: https://gcc.gnu.org/viewcvs?rev=249665=gcc=rev
Log:
PR c++/81215

* pt.c (unify_bound_ttp_args): Restore old logic for C++14 and down.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/variadic-ttp7.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/pt.c

[Bug c++/81215] [7/8 Regression] deduction failure with variadic template template parameter

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Mon Jun 26 18:49:18 2017
New Revision: 249664

URL: https://gcc.gnu.org/viewcvs?rev=249664=gcc=rev
Log:
PR c++/81215 - deduction failure with variadic TTP.

* pt.c (unify_bound_ttp_args): Restore old logic for C++14 and down.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-ttp7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug fortran/81205] Hybrid MPI and OpenMp: Blocking code in loops

[pasha.313 at hotmail dot com]

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

--- Comment #5 from Pasha  ---
(In reply to Harald Anlauf from comment #4)
> (In reply to Pasha from comment #2)
> > This is my main routine for example
> > .
> > .
> > .
> > !!$OMP PARALLEL DO DEFAULT(SHARED) PRIVATE(K,jL)
> > DO k=1,nG3
> >DO jL=1,nL2
> >   j = idx2start + jL
> 
> Any reason you didn't declare j as private?
That did not solve the problem as I have other subroutines in main which
declared all of index number in main program and in subroutines but again the
code Blocks. Even when I disabled OMP commands in the loop of main program, the
code get inside the subroutine but again blocks in the loop of that
subroutines.
I used ulimit -s 1000 or ulimit -Hd to increase the capacity of each CPU
but still get nowhere.   
> 
> >   IF(masque(j,k))THEN
> > 
> >  ! dudx
> >  CALL fvec (nG1,curC(1:nG1,jL,k), difles1C(1:nG1,jL,k))
> >  CALL tridgn (ff,s1,w1,difles1C(1:nG1,jL,k), nG1,1)
> >   ENDIF
> >ENDDO
> > ENDDO
> > !!$OMP END PARALLEL DO
> 
> Have you tried some thread-checking tool to debug the code,
> or cross-checked with another compiler?

Some of my friends suggested to compile the code with ifort, but I do not
access to that. I asked my supervisor to buy or find it on other lab to check
it.
Will you please offer a name of thread-checking tools? can I do it with visual
studio? or you mean something else?

[Bug c++/81215] [7/8 Regression] deduction failure with variadic template template parameter

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

[Bug c++/81215] New: [7/8 Regression] deduction failure with variadic template template parameter

[jason at gcc dot gnu.org]

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

Bug ID: 81215
   Summary: [7/8 Regression] deduction failure with variadic
template template parameter
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: jason at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
  Target Milestone: ---

From https://bugzilla.redhat.com/show_bug.cgi?id=1464612

template struct X { };
template struct set { };

template  class C>
void bar (const X&)
{
}

void
foo (X& x)
{
  bar (x);
}

[Bug rtl-optimization/81194] [8 Regression] ICE during RTL pass: expand

[marc.mutz at kdab dot com]

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

--- Comment #6 from Marc Mutz  ---
Sorry. Here it comes:

make[2]: Entering directory
'/home/marc/Qt/qt5-build/qtdeclarative/src/qmldevtools'
g++ -c -pipe -Wno-error=expansion-to-defined -Wno-error=maybe-uninitialized
-Wno-error=expansion-to-defined -Wno-error=maybe-uninitialized
-Wno-c++0x-compat -ffunction-sections -O2 -fPIC -std=c++1z -fvisibility=hidden
-fvisibility-inlines-hidden -fno-exceptions -Wall -W
-Wno-error=expansion-to-defined -Wno-error=maybe-uninitialized
-Wno-error=expansion-to-defined -Wno-error=maybe-uninitialized
-Wno-c++0x-compat -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond
-Werror -Wno-error=cpp -Wno-error=deprecated-declarations
-Wno-error=strict-overflow -Wno-error=implicit-fallthrough
-Wno-error=class-memaccess -D_REENTRANT -DWTF_EXPORT_PRIVATE=
-DJS_EXPORT_PRIVATE= -DENABLE_ASSEMBLER_WX_EXCLUSIVE=1
-DWTFReportAssertionFailure=qmlWTFReportAssertionFailure
-DWTFReportBacktrace=qmlWTFReportBacktrace
-DWTFInvokeCrashHook=qmlWTFInvokeCrashHook -DENABLE_LLINT=0 -DENABLE_DFG_JIT=0
-DENABLE_DFG_JIT_UTILITY_METHODS=1 -DENABLE_JIT_CONSTANT_BLINDING=0
-DBUILDING_QT__ -DWTF_USE_UDIS86=0 -DNDEBUG -DWTF_EXPORT_PRIVATE=
-DJS_EXPORT_PRIVATE= -DENABLE_ASSEMBLER_WX_EXCLUSIVE=1
-DWTFReportAssertionFailure=qmlWTFReportAssertionFailure
-DWTFReportBacktrace=qmlWTFReportBacktrace
-DWTFInvokeCrashHook=qmlWTFInvokeCrashHook -DENABLE_LLINT=0 -DENABLE_DFG_JIT=0
-DENABLE_DFG_JIT_UTILITY_METHODS=1 -DENABLE_JIT_CONSTANT_BLINDING=0
-DBUILDING_QT__ -DWTF_USE_UDIS86=0 -DNDEBUG
-DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_QMLDEVTOOLS_LIB
-DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_CORE_LIB
-I/home/marc/Qt/qt5/qtdeclarative/src/qmldevtools -I.
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/jit
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/assembler
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/runtime
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/wtf
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/stubs
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/stubs/wtf
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/disassembler
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/disassembler/udis86
-I/home/marc/Qt/qt5/qtdeclarative/src/qml/jsruntime -I.
-I/home/marc/Qt/qt5/qtdeclarative/src/qml/compiler -I.
-I/home/marc/Qt/qt5/qtdeclarative/src/qml/memory -I.
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/jit
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/assembler
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/runtime
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/wtf
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/stubs
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/stubs/wtf
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/disassembler
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/disassembler/udis86
-I/home/marc/Qt/qt5/qtdeclarative/src/qml/jit -I. -I.generated
-I/home/marc/Qt/qt5-build/qtbase/include
-I/home/marc/Qt/qt5-build/qtbase/include/QtQml
-I/home/marc/Qt/qt5-build/qtbase/include/QtQml/5.10.0
-I/home/marc/Qt/qt5-build/qtbase/include/QtQml/5.10.0/QtQml
-I/home/marc/Qt/qt5-build/qtbase/include/QtCore/5.10.0
-I/home/marc/Qt/qt5-build/qtbase/include/QtCore/5.10.0/QtCore
-I/home/marc/Qt/qt5-build/qtbase/include/QtCore -I.moc
-I/home/marc/Qt/qt5/qtbase/mkspecs/linux-g++ -o .obj/qv4isel_masm.o
/home/marc/Qt/qt5/qtdeclarative/src/qml/jit/qv4isel_masm.cpp

[Bug fortran/81205] Hybrid MPI and OpenMp: Blocking code in loops

[anlauf at gmx dot de]

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

--- Comment #4 from Harald Anlauf  ---
(In reply to Pasha from comment #2)
> This is my main routine for example
> .
> .
> .
> !!$OMP PARALLEL DO DEFAULT(SHARED) PRIVATE(K,jL)
> DO k=1,nG3
>DO jL=1,nL2
>   j = idx2start + jL

Any reason you didn't declare j as private?

>   IF(masque(j,k))THEN
> 
>  ! dudx
>  CALL fvec (nG1,curC(1:nG1,jL,k), difles1C(1:nG1,jL,k))
>  CALL tridgn (ff,s1,w1,difles1C(1:nG1,jL,k), nG1,1)
>   ENDIF
>ENDDO
> ENDDO
> !!$OMP END PARALLEL DO

Have you tried some thread-checking tool to debug the code,
or cross-checked with another compiler?

[Bug c++/81211] Unhelpful error messages using template instance with non-copyable type argument

[srk31 at srcf dot ucam.org]

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

--- Comment #5 from Stephen Kell  ---
I take the point in general, and I see the specific difficulty in how result_of
works.

In this specific case, there still seems to be a more low-hanging solution.
Perhaps having a lambda that is not callable ought to raise a warning? That
seems like a more straightforward diagnostic. In particular, by addressing the
lambda rather than the std::function, the problem with pointers to member
functions doesn't arise.

As for the rule of five: a fine reference, but it's rather circular to say what
amounts to "don't make mistakes in your code". :-) This error came up after a
rather large bout of refactoring that deleted slightly too much stuff

[Bug tree-optimization/81196] Number of iterations found for p!=q but not for p

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
(In reply to amker from comment #4)
> Hmm, the function can only be vectorized with "-march=skylake"?

Er, it also vectorizes without any -march on x86_64 (with shorter vectors).

[Bug c++/81211] Unhelpful error messages using template instance with non-copyable type argument

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
That's not really very practical. std::function uses std::result_of to check
for a callable type, and it's not an error for std::result_of to decide the
type isn't callable. The error happens when std::function requests the
std::result_of<>::type member, which doesn't exist. But the reason for it not
existing is long gone by that point, decided earlier in the internals of
std::result_of and not available to the compiler.

Using decltype(std::declval<_Func&>()(std::declval<_ArgTypes>()...)) instead of
result_of gives a nice diagnostic:

/home/jwakely/gcc/8/include/c++/8.0.0/bits/std_function.h:465:2: note:
candidate: ‘template std::function<_Res(_ArgTypes
...)>::function(_Functor)’
  function(_Functor);
  ^~~~
/home/jwakely/gcc/8/include/c++/8.0.0/bits/std_function.h:465:2: note:  
template argument deduction/substitution failed:
/home/jwakely/gcc/8/include/c++/8.0.0/bits/std_function.h:394:55: error: use of
deleted function ‘constexpr T::T(const T&)’
 typename _Res2 =
decltype(std::declval<_Func&>()(std::declval<_ArgTypes>()...))>
   ^~
func.cc:2:8: note: ‘constexpr T::T(const T&)’ is implicitly declared as deleted
because ‘T’ declares a move constructor or move assignment operator
 struct T
^
func.cc:16:33: note:   initializing argument 1 of ‘main()::’
   std::function f{ [](T) { } };
 ^

But using decltype there is incorrect, it wouldn't work for pointers to
members. Which is why we use result_of.

We can't add something like:

static_assert( __and_::value,
   "arguments can be passed to the target function" );

Because that would reject this valid code:

#include 

struct T
{
T(int) {}
// uncomment one of the  below to make the code compile
//T(const T&) {}
//T(T&& t) {}
T& operator=(const T&) { return *this; }
T& operator=(T&&) { return *this; }
};

int main()
{
std::function f{ [](T&&) {} };
f( {1} );
}

I don't see anything that can really be done to improve things here.

(In reply to Stephen Kell from comment #3)
> It'd be nice if I didn't have to guess that the reason it's not callable is
> that I omitted the copy constructor. The rules for when constructors are
> defaulted/deleted are baroque enough to catch anybody out from time to time.

Not if you follow the rule of five:
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c21-if-you-define-or-delete-any-default-operation-define-or-delete-them-all

Your class has user-provided assignment operators and fails to declare copy and
move constructors. Define them (maybe as =default) and there's no problem.

[Bug c++/81169] [8 Regression] gcc 8.0dev -Wclass-memaccess illegitimate warning related to volatile

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Mon Jun 26 17:19:15 2017
New Revision: 249660

URL: https://gcc.gnu.org/viewcvs?rev=249660=gcc=rev
Log:
PR c++/81169 - -Wclass-memaccess illegitimate warning related to volatile

gcc/cp/ChangeLog:

PR c++/81169
* call.c (maybe_warn_class_memaccess): Preserve explicit conversions
to detect casting away cv-qualifiers.

gcc/testsuite/ChangeLog:

PR c++/81169
* g++.dg/Wclass-memaccess-2.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/Wclass-memaccess-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/81169] [8 Regression] gcc 8.0dev -Wclass-memaccess illegitimate warning related to volatile

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Fixed in r249660.

[Bug rtl-optimization/81194] [8 Regression] ICE during RTL pass: expand

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner  ---
(In reply to Jakub Jelinek from comment #3)
> I don't see g++ options mentioned anywhere, the testcase compiles even with
> latest trunk just fine with -O0 -std=c++17 or -O2 -std=c++17.

...and compiles fine with -O1 -std=c++17 and -O3 -std=c++17 too, so I'll need
more info to be able to recreate this.

[Bug middle-end/80775] [8 Regression] -O3 produces ice in group_case_labels_stmt

[bergner at gcc dot gnu.org]

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

--- Comment #15 from Peter Bergner  ---
(In reply to Peter Bergner from comment #14)
> I don't see this on powerpc64le-linux using -O3.  What target are you using?
> Any options other than -O3?

Doesn't fail for me on x86_64 either, so I'll need target/configure options as
well as full compile options.

[Bug c++/81147] [avr] C++ for -mmcu=atmega2560 doesn't do NRVO or RVO when class inherits from empty base

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

[Bug middle-end/81207] [7/8 Regression] tree check fail in simplify_builtin_call

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 41634
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41634=edit
gcc8-pr81207.patch

Untested fix.

[Bug target/81210] FAIL: gcc.dg/torture/pr68037-*.c -O* execution test

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
The following reduced test segfault also on darwin

#define IP  0x12345671
#define CS  0x12345672
#define FLAGS   0x12345673
#define SP  0x12345674
#define SS  0x12345675

#define STRING(x)   XSTRING(x)
#define XSTRING(x)  #x

int
main ()
{
  asm ("push$" STRING (SS) ";   \
push$" STRING (SP) ";   \
push$" STRING (FLAGS) ";\
push$" STRING (CS) ";   \
push$" STRING (IP) ";");
  return 0;
}

[Bug ipa/81214] New: GCC target_clone support does not work for global functions with no references

[meissner at gcc dot gnu.org]

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

Bug ID: 81214
   Summary: GCC target_clone support does not work for global
functions with no references
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41633
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41633=edit
Test case.

If you define a global target_clone function but there are no references to it,
because the references will be in another file, the compiler deletes the ifunc
entry and the ifunc resolver function, but it leaves the target clone functions
(which no longer have references to them once the resolver function was
deleted).

The following is the NM output from the attached file compiled with -O3:

$ file="test-x86-clone3"; ~/fsf-install-x86_64/trunk-249567-x86_64/bin/gcc -O3 
-save-temps -c $file.c && nm $file.o
01b0 t vadd.arch_core_avx2.2.default.3
0150 t vadd.arch_slm.1.default.4
0060 t vadd.avx.0.default.5
 T vadd.default.6

[Bug middle-end/80775] [8 Regression] -O3 produces ice in group_case_labels_stmt

[bergner at gcc dot gnu.org]

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

--- Comment #14 from Peter Bergner  ---
I don't see this on powerpc64le-linux using -O3.  What target are you using? 
Any options other than -O3?

[Bug ipa/81213] New: GCC target_clone support does not work for static functions

[meissner at gcc dot gnu.org]

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

Bug ID: 81213
   Summary: GCC target_clone support does not work for static
functions
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41632
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41632=edit
Test case.

The current target_clone support does not work if the function is static.  The
ifunc entry has to be a global entry point for ifunc to work.  The code does
not change the name for the ifunc handler to be unique.

With attached source compiled for -O3, the following are the symbols in the
object file.

-> ~/fsf-install-x86_64/trunk-249567-x86_64/bin/gcc -O3  -save-temps -c
test-x86-clone2.c && nm test-x86-clone2.o
 U __cpu_indicator_init
 U __cpu_model
0540 i vadd
0380 t vadd.arch_core_avx2.2.default.3
02a0 t vadd.arch_slm.1.default.4
00e0 t vadd.avx.0.default.5
 t vadd.default.6
0540 T vadd._GLOBAL___vdbl.resolver
0590 T vdbl

Note that vadd is external (which it needs to be), but it isn't unique.

The resolver function is external, but it doesn't need to be external.  It can
be internal.  The function name is changed by calling make_unique_name in the
i386.c function make_resolver_func.  The i386 code explicitly sets the resolver
function to static, but it is changed in the machine dependent code.

[Bug c++/81211] Unhelpful error messages using template instance with non-copyable type argument

[srk31 at srcf dot ucam.org]

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

--- Comment #3 from Stephen Kell  ---
I agree that this message is better (my bad for not trying a supported
release).

It'd be nice if I didn't have to guess that the reason it's not callable is
that I omitted the copy constructor. The rules for when constructors are
defaulted/deleted are baroque enough to catch anybody out from time to time.

[Bug middle-end/81212] New: -Wreturn-type is disabled when used together with -fsanitize=return

[vanyacpp at gmail dot com]

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

Bug ID: 81212
   Summary: -Wreturn-type is disabled when used together with
-fsanitize=return
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

Consider this code snippet:

struct X
{
X(void* p);

void* p;
};


X f(bool x, void* p)
{
if (x)
return X(p);
}

Compiling it with gcc 7.1 -Wreturn-type gives a warning:
warning: control reaches end of non-void function [-Wreturn-type]

But compiling it with gcc 7.1 -Wreturn-type and -fsanitize=return gives no
warning. Clang 4.0 gives the warning in both cases. It would be great if gcc
gave the warning in both cases too.

[Bug libstdc++/70472] is_copy_constructible<vector<unique_ptr>>::value is true

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
That would only work for vector not vector , for the reasons given
above.

[Bug c++/81211] Unhelpful error messages using template instance with non-copyable type argument

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Stephen Kell from comment #0)
> > (It may also be a bug in libstdc++ that std::function should require this of
> > its argument type, although that's not completely bonkers.)
> 
> It's explicitly required by the standard.

Oh, you're talking about the argument to the call operator not the argument to
the constructor (which is required to be CopyConstructible).

If you declare std::function then obviously it takes a T by value,
because that's what the type "bool(T)" means. If you can't pass the type by
value, you can't call the function.

(In reply to Stephen Kell from comment #0)
> Meanwhile, g++ 6 (Debian 6.3.0-18) says basically the same thing.

Note really, all supported releases (which 4.9 is not one of) say:

/home/jwakely/gcc/6/include/c++/6.3.1/functional:1914:2: note:   template
argument deduction/substitution failed:
/home/jwakely/gcc/6/include/c++/6.3.1/functional:1913:9: error: no type named
‘type’ in ‘class std::result_of&(T)>’
 typename = _Requires<_Callable<_Functor>, void>>
 ^~~~

Because your lambda with a parameter of type T is not callable with an argument
of type T.


> Naively at least, I'd expect the error trace to reveal something about
> trying to copy a T, presumably in some non-viable constructor of
> std::function.

It tells you the lambda can't be called, which is why the constructor isn't
viable.

[Bug target/81210] FAIL: gcc.dg/torture/pr68037-*.c -O* execution test

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Dominique d'Humieres from comment #2)
> > Is this a regression?
> 
> AFAICT the tests have never passed.

These tests try to emulate interrupt in user space.  If the emulation
doesn't work on darwin, they should be skipped on darwin.

[Bug target/81193] PowerPC GCC __builtin_cpu_is and __builtin_cpu_supports should warn about old libraries

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

--- Comment #4 from Michael Meissner  ---
I have no problems with restricting use of __builtin_cpu_ and target_clone
to GLIBC 2.19 or newer (or whatever the release version is).  Now that I think
of it, yeah, we don't want to run ifunc resolvers if it has relocations.  I
don't know whether the linker should warn about problematic code (it probably
should, or at least we need to document it somewhere).  I was just surprised
that the compiler silently sets the test to 0.

Alternatively, we would need to do two passes.  On the first pass resolve all
of the normal functions and data locations, setting the location of ifunc
functions in the TOC to be an error function.  The second pass would resolve
the ifunc functions.  If an ifunc function calls another ifunc function that
hasn't been resolved yet, it would go to the error function.

I think for the problem of using __builtin_cpu_, we should issue a warning
(not a fatal error) if the configured GLIBC is too old saying you need to link
against a newer library, but generate the same code that we normally do.  Given
there is a reference to an external provided with the new glibc, it should be
safe, because you would get a linker error if you actually tried to use it with
an old library.  It would allow creation of libraries with functions using
__builtin_cpu_* and target_clone with an old compiler, providing the library is
linked appropriately.

It would also allow the tests for target_clone to work.  Though I probably will
switch my builds to use --with-advance-toolchain to always get the new library
(now that works with bootstrap).

[Bug c/81208] 'uninitialized' warning is missed while self initializing

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is by design.

See
https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Warning-Options.html#index-Winit-self
.

[Bug c++/81211] Unhelpful error messages using template instance with non-copyable type argument

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Stephen Kell from comment #0)
> (It may also be a bug in libstdc++ that std::function should require this of
> its argument type, although that's not completely bonkers.)

It's explicitly required by the standard.

[Bug target/81210] FAIL: gcc.dg/torture/pr68037-*.c -O* execution test

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Dominique d'Humieres  ---
> Is this a regression?

AFAICT the tests have never passed.

[Bug libstdc++/70472] is_copy_constructible<vector<unique_ptr>>::value is true

[safinaskar at mail dot ru]

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

--- Comment #8 from Askar Safin  ---
Recently I noticed this bug can be easily fixed simply by manually implementing
is_copy_constructible. So, please, apply the fix. And same for other type
traits (is_copy_assignable etc).

#include 
#include 
#include 
#include 

namespace std{
template  struct is_copy_constructible> : public
is_copy_constructible<_Tp>
{
};
}

struct foo
{
  std::vector x; 
};

struct bar
{
  std::vector x;
  std::unique_ptr y;
};

// First column is what we want, second is actual result
int
main ()
{
  std::cout << "1 " << std::is_copy_constructible::value <<
"\n";
  std::cout << "0 " <<
std::is_copy_constructible>::value << "\n";
  std::cout << "1 " << std::is_copy_constructible::value << "\n";
  std::cout << "0 " << std::is_copy_constructible::value << "\n";
}

[Bug c++/81211] New: Unhelpful error messages using template instance with non-copyable type argument

[srk31 at srcf dot ucam.org]

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

Bug ID: 81211
   Summary: Unhelpful error messages using template instance with
non-copyable type argument
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: srk31 at srcf dot ucam.org
  Target Milestone: ---

Created attachment 41631
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41631=edit
Small test case

The following code (also attached) fails to compile, and experiments show that
the fix is to make T copy-constructible or move-constructible.

The bug is that the error messages are worse than useless, because they are
about constructing a std::function rather than a T.

(It may also be a bug in libstdc++ that std::function should require this of
its argument type, although that's not completely bonkers.)

#include 
struct T
{
T() {}
// uncomment one of the  below to make the code compile
//T(const T&) {}
//T(T&& t) {}
T& operator=(const T& arg) { return *this; }
T& operator=(T&& arg) { return *this; }
};
int main(int argc, char **argv)
{
std::function f([](T x) -> bool {
return false;
});
return 0;
}


gcc 4.9 (Debian 4.9.2-10) says:

test.cc: In function ‘int main(int, char**)’:
test.cc:15:3: error: no matching function for call to
‘std::function::function(main(int, char**)::)’
  });
   ^
test.cc:15:3: note: candidates are:
In file included from test.cc:1:0:
/usr/include/c++/4.9/functional:2226:2: note: template
std::function<_Res(_ArgTypes ...)>::function(_Functor)
  function(_Functor);
  ^
/usr/include/c++/4.9/functional:2226:2: note:   template argument
deduction/substitution failed:
/usr/include/c++/4.9/functional:2201:7: note: std::function<_Res(_ArgTypes
...)>::function(std::function<_Res(_ArgTypes ...)>&&) [with _Res = bool;
_ArgTypes = {T}]
   function(function&& __x) : _Function_base()
   ^
/usr/include/c++/4.9/functional:2201:7: note:   no known conversion for
argument 1 from ‘main(int, char**)::’ to ‘std::function&&’
/usr/include/c++/4.9/functional:2404:5: note: std::function<_Res(_ArgTypes
...)>::function(const std::function<_Res(_ArgTypes ...)>&) [with _Res = bool;
_ArgTypes = {T}]
 function<_Res(_ArgTypes...)>::
 ^
/usr/include/c++/4.9/functional:2404:5: note:   no known conversion for
argument 1 from ‘main(int, char**)::’ to ‘const
std::function&’
/usr/include/c++/4.9/functional:2181:7: note: std::function<_Res(_ArgTypes
...)>::function(std::nullptr_t) [with _Res = bool; _ArgTypes = {T};
std::nullptr_t = std::nullptr_t]
   function(nullptr_t) noexcept
   ^
/usr/include/c++/4.9/functional:2181:7: note:   no known conversion for
argument 1 from ‘main(int, char**)::’ to ‘std::nullptr_t’
/usr/include/c++/4.9/functional:2174:7: note: std::function<_Res(_ArgTypes
...)>::function() [with _Res = bool; _ArgTypes = {T}]
   function() noexcept
   ^
/usr/include/c++/4.9/functional:2174:7: note:   candidate expects 0 arguments,
1 provided


Meanwhile, g++ 6 (Debian 6.3.0-18) says basically the same thing.

Naively at least, I'd expect the error trace to reveal something about trying
to copy a T, presumably in some non-viable constructor of std::function.

[Bug target/81210] FAIL: gcc.dg/torture/pr68037-*.c -O* execution test

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Is this a regression?

[Bug tree-optimization/81196] Number of iterations found for p!=q but not for p

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Hmm, the function can only be vectorized with "-march=skylake"?  So what
requirement is needed to add a test case for this?

Thanks.

[Bug testsuite/81058] FAIL: gcc.target/i386/avx512bw-vpmovu?swb-1.c scan-assembler-times vpmovu?swb.*

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Any chance to have these failures fixed in a near future?

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #12 from Bill Schmidt  ---
Fixed.  Actual fix revision is 249648 (forgot the PR line).

[Bug target/68037] x86 interrupt attribute doesn't work with DRAP

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Some tests are failing on darwin: see pr81210.

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
Author: wschmidt
Date: Mon Jun 26 14:19:33 2017
New Revision: 249649

URL: https://gcc.gnu.org/viewcvs?rev=249649=gcc=rev
Log:
[gcc]

2016-06-26  Bill Schmidt  

PR tree-optimization/71815
* gimple-ssa-strength-reduction.c (uses_consumed_by_stmt): New
function.
(find_basis_for_candidate): Call uses_consumed_by_stmt rather than
has_single_use.
(slsr_process_phi): Likewise.
(replace_uncond_cands_and_profitable_phis): Don't replace a
multiply candidate with a stride of 1 (copy or cast).
(phi_incr_cost): Call uses_consumed_by_stmt rather than
has_single_use.
(lowest_cost_path): Likewise.
(total_savings): Likewise.

[gcc/testsuite]

2016-06-26  Bill Schmidt  

PR tree-optimization/71815
* gcc.dg/tree-ssa/slsr-35.c: Remove -fno-code-hoisting workaround.
* gcc.dg/tree-ssa/slsr-36.c: Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug target/81210] New: FAIL: gcc.dg/torture/pr68037-*.c -O* execution test

[dominiq at lps dot ens.fr]

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

Bug ID: 81210
   Summary: FAIL: gcc.dg/torture/pr68037-*.c   -O*  execution test
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: hjl at gnu dot org, iains at gcc dot gnu.org, ro at gcc dot 
gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin16
Target: x86_64-apple-darwin16
 Build: x86_64-apple-darwin16

The test gcc.dg/torture/pr68037-*.c fail on darwin (r249645) with a
"Segmentation fault"

FAIL: gcc.dg/torture/pr68037-1.c   -O0  execution test
FAIL: gcc.dg/torture/pr68037-2.c   -O1  execution test
FAIL: gcc.dg/torture/pr68037-2.c   -O2  execution test
FAIL: gcc.dg/torture/pr68037-2.c   -O2 -flto  execution test
FAIL: gcc.dg/torture/pr68037-2.c   -O2 -flto -flto-partition=none  execution
test
FAIL: gcc.dg/torture/pr68037-2.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pr68037-2.c   -Os  execution test
FAIL: gcc.dg/torture/pr68037-3.c   -O1  execution test
FAIL: gcc.dg/torture/pr68037-3.c   -O2  execution test
FAIL: gcc.dg/torture/pr68037-3.c   -O2 -flto  execution test
FAIL: gcc.dg/torture/pr68037-3.c   -O2 -flto -flto-partition=none  execution
test
FAIL: gcc.dg/torture/pr68037-3.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pr68037-3.c   -Os  execution test

[Bug sanitizer/81209] New: [7/8 Regression] -fsanitize=undefined ICE on darwin

[dominiq at lps dot ens.fr]

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

Bug ID: 81209
   Summary: [7/8 Regression] -fsanitize=undefined ICE on darwin
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
iains at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at 
gcc dot gnu.org,
marxin at gcc dot gnu.org, ro at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin16
Target: x86_64-apple-darwin16
 Build: x86_64-apple-darwin16

The test is still failing on darwin (r249645):

FAIL: g++.dg/ubsan/pr81125.C   -O0  (internal compiler error)
FAIL: g++.dg/ubsan/pr81125.C   -O0  (test for excess errors)
FAIL: g++.dg/ubsan/pr81125.C   -O1  (internal compiler error)
FAIL: g++.dg/ubsan/pr81125.C   -O1  (test for excess errors)
FAIL: g++.dg/ubsan/pr81125.C   -O2  (internal compiler error)
FAIL: g++.dg/ubsan/pr81125.C   -O2  (test for excess errors)
FAIL: g++.dg/ubsan/pr81125.C   -O2 -flto  (internal compiler error)
FAIL: g++.dg/ubsan/pr81125.C   -O2 -flto  (test for excess errors)
FAIL: g++.dg/ubsan/pr81125.C   -O2 -flto -flto-partition=none  (internal
compiler error)
FAIL: g++.dg/ubsan/pr81125.C   -O2 -flto -flto-partition=none  (test for excess
errors)
FAIL: g++.dg/ubsan/pr81125.C   -O3 -g  (internal compiler error)
FAIL: g++.dg/ubsan/pr81125.C   -O3 -g  (test for excess errors)

With trunk the ICE is

/opt/gcc/_clean/gcc/testsuite/g++.dg/ubsan/pr81125.C:19:14: internal compiler
error: in gimple_add_tmp_var, at gimplify.c:716
   long b = a % c;
~~^~~

With gcc-7 it is

/opt/gcc/_clean/gcc/testsuite/g++.dg/ubsan/pr81125.C:19:14: internal compiler
error: in make_decl_rtl, at varasm.c:1311
   long b = a % c;
~~^~~

[Bug c/81208] New: 'uninitialized' warning is missed while self initializing

[streletsaa at mail dot ru]

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

Bug ID: 81208
   Summary: 'uninitialized' warning is missed while self
initializing
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: streletsaa at mail dot ru
  Target Milestone: ---

Created attachment 41630
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41630=edit
example project that reproduces the bug

The following code does not produce an 'uninitialized' warning in gcc for 'px':

{
int x = 3, *px = 
printf("main: %p\n", px);   // suppress 'unused variable px'

do {
int *px = px;// <--- here must be a WARNING
...
} while(0);
}

See the attached project for more details.

gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609

Linux ubuntu 4.4.0-81-generic #104-Ubuntu SMP Wed Jun 14 08:17:06 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux

[Bug rtl-optimization/81194] [8 Regression] ICE during RTL pass: expand

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  ---
Will do, but as Jakub said, we'll need the compiler options used.

[Bug libgomp/81177] Dump cubin module to file before offloading in nvptx libgomp plugin

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01918.html

[Bug fortran/81205] Hybrid MPI and OpenMp: Blocking code in loops

[pasha.313 at hotmail dot com]

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

--- Comment #3 from Pasha  ---
For example, in this case index variables are not the same in both subroutines
but it blocks running.

[Bug c++/81147] [avr] C++ for -mmcu=atmega2560 doesn't do NRVO or RVO when class inherits from empty base

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P5

[Bug c++/81147] [avr] C++ for -mmcu=atmega2560 doesn't do NRVO or RVO when class inherits from empty base

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #2 from Georg-Johann Lay  ---
Your testcase doesn't compile:

$ avr-g++ pr81147.cpp
pr81147.cpp:1:20: fatal error: iterator: No such file or directory
 #include 
^
compilation terminated.

[Bug fortran/81205] Hybrid MPI and OpenMp: Blocking code in loops

[pasha.313 at hotmail dot com]

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

--- Comment #2 from Pasha  ---
This is my main routine for example
.
.
.
!!$OMP PARALLEL DO DEFAULT(SHARED) PRIVATE(K,jL)
DO k=1,nG3
   DO jL=1,nL2
  j = idx2start + jL
  IF(masque(j,k))THEN

 ! dudx
 CALL fvec (nG1,curC(1:nG1,jL,k), difles1C(1:nG1,jL,k))
 CALL tridgn (ff,s1,w1,difles1C(1:nG1,jL,k), nG1,1)
  ENDIF
   ENDDO
ENDDO
!!$OMP END PARALLEL DO
.
.
.

This is one of those subroutine

SUBROUTINE fvec (n,y,q)
!
!Multiplie le vecteur y par les coefs de la matrice
!passee en common (param6) et le retourne dans q
USE OMP_LIB
IMPLICIT NONE

INTEGER,INTENT(IN) :: n
REAL(prec), DIMENSION(n), INTENT(IN)  :: y
REAL(prec), DIMENSION(n), INTENT(OUT) :: q

INTEGER :: i,nm,nmm
!
nmm=n-2
nm =n-1

q(1) = af0*y(1)+bf0*y(2) +cf0*y(3)  +df0*y(4)  +ef0*y(5)
q(2) = af1*y(3)-af1*y(1)
q(nm)= af1*y(n)-af1*y(nmm)
q(n) =-ag0*y(n)-bg0*y(nm)-cg0*y(nmm)-dg0*y(n-3)-eg0*y(n-4)
!
IF(bf2.EQ.ZERO)THEN
!!$OMP PARALLEL DO DEFAULT(SHARED) PRIVATE(I)
DO i=3,nmm
  q(i)=af2*y(i+1)-af2*y(i-1)
ENDDO
!!$OMP END PARALLEL DO
ELSE
!!$OMP PARALLEL DO DEFAULT(SHARED) PRIVATE(I)
DO i=3,nmm
  q(i)=af2*y(i+1)-af2*y(i-1)+bf2*y(i+2)-bf2*y(i-2)
ENDDO
!!$OMP END PARALLEL DO
ENDIF

  END SUBROUTINE fvec

please be aware that OMP commands works well in other subroutines except those
who has loops and calling from inside a main code.
So for running the program, I disabled all OMP commands in these subroutines
and some part of codes as you can see.

[Bug rtl-optimization/67483] combine.c sanitizer detects undefined negative left shift

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #4 from Segher Boessenkool  ---
Fixed.

[Bug libstdc++/81138] [DR 2983] std::money_put facet does not write '0' before decimal point

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED
Summary|std::money_put facet does   |[DR 2983] std::money_put
   |not write '0' before|facet does not write '0'
   |decimal point   |before decimal point

--- Comment #3 from Jonathan Wakely  ---
This is now https://wg21.link/lwg2983

[Bug rtl-optimization/67856] callee-saved register saves should be shrink-wrapped

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #6 from Segher Boessenkool  ---
There now is generic code (in trunk and 7) for -fshrink-wrap-separate;
for this to do anything on x86, someone who understands the i386 backend
will have to write an implementation for the hooks.

[Bug c++/81204] [7/8 Regression] Rejects boost headers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
Reduced:

namespace std {
  template struct set { };
}

using namespace std;

template 
inline void set(Result & res)
{
res.template set();
}

[Bug target/68690] PowerPC64: TOC save in PHP core loop results in load hit store

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
This now compiles to

main:
.LCF1:
0:  addis 2,12,.TOC.-.LCF1@ha
addi 2,2,.TOC.-.LCF1@l
.localentry main,.-main
addis 9,2,.LC0@toc@ha   # gpr load fusion, type long
ld 9,.LC0@toc@l(9)
addis 10,2,do_nothing@toc@ha
li 3,0
addi 10,10,do_nothing@toc@l
std 10,0(9)
blr

but the problem is still there, just this testcase is defeated; remove
the assignment to fn to make the problem pop up again.

[Bug middle-end/81207] [7/8 Regression] tree check fail in simplify_builtin_call

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
I'll have a look.

[Bug target/70098] PowerPC64: eigen hits ICE following invalid register assignment

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #15 from Segher Boessenkool  ---
This has been fixed.

[Bug bootstrap/70173] make distclean: leaves stage_final and libcc1/compiler-name.h

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #9 from Segher Boessenkool  ---
Fixed.

[Bug middle-end/81207] [7/8 Regression] tree check fail in simplify_builtin_call

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Apparently in the IR we have
# VUSE <.MEM>
_13 = __builtin_strchr (_12, 39);

(gdb) p vuse
$1 = 

and SSA_NAME_DEF_STMT crashes on that.

[Bug tree-optimization/81196] Number of iterations found for p!=q but not for p

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Probably some more elaborate handling in number_of_iterations_cond is
> required:
> 
>   /* We can handle the case when neither of the sides of the comparison is
>  invariant, provided that the test is NE_EXPR.  This rarely occurs in
>  practice, but it is simple enough to manage.  */
>   if (!integer_zerop (iv0->step) && !integer_zerop (iv1->step))
> {
>   tree step_type = POINTER_TYPE_P (type) ? sizetype : type;
>   if (code != NE_EXPR)
> return false;
> 
>   iv0->step = fold_binary_to_constant (MINUS_EXPR, step_type,
>iv0->step, iv1->step);
>   iv0->no_overflow = false;
>   iv1->step = build_int_cst (step_type, 0);
>   iv1->no_overflow = true;
> }
> 
> I think this exit is premature and the following works for the testcase.
> I suppose exiting is still required but can be moved to a later point,
> or the helpers now fully handle the case of non-constant iv1 ...
> Vectorization still fails with this due to runtime aliasing so it
> probably exposes some wrong-code issue.  CCing Bin who is now most
> familiar with the niter code.
> 
> Index: gcc/tree-ssa-loop-niter.c
> ===
> --- gcc/tree-ssa-loop-niter.c   (revision 249638)
> +++ gcc/tree-ssa-loop-niter.c   (working copy)
> @@ -1674,14 +1674,14 @@ number_of_iterations_cond (struct loop *
>if (!integer_zerop (iv0->step) && !integer_zerop (iv1->step))
>  {
>tree step_type = POINTER_TYPE_P (type) ? sizetype : type;
> -  if (code != NE_EXPR)
> -   return false;
> -
> -  iv0->step = fold_binary_to_constant (MINUS_EXPR, step_type,
> -  iv0->step, iv1->step);
> -  iv0->no_overflow = false;
> -  iv1->step = build_int_cst (step_type, 0);
> -  iv1->no_overflow = true;
> +  if (code == NE_EXPR)
> +   {
> + iv0->step = fold_binary_to_constant (MINUS_EXPR, step_type,
> +  iv0->step, iv1->step);
> + iv0->no_overflow = false;
> + iv1->step = build_int_cst (step_type, 0);
> + iv1->no_overflow = true;
> +   }
No, at least we need to adjust for other code like LT_EXPR/LE_EXPR too. 
Following code can't handle comparison with both sides non-zero ivs.
I guess it only handles NE_EXPR, otherwise it's possible to end up with wrong
result because of wrapping behavior.  Considering below test:

unsigned int i = 0xfff0, j=0xfff8;
for (; i < j; i++, j+=2)
it only iterates for 4 times before j wrapping to 0.  It's not equal to:
unsigned int i = 0xfff0, j=0xfff8;
for (; i < j; i--)

The tricky part is to identify safe cases.  I will try to improve this.

Thanks.

[Bug middle-end/81207] [7/8 Regression] tree check fail in simplify_builtin_call

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

  Component|c   |middle-end
   Target Milestone|--- |7.2
Summary|tree check fail in  |[7/8 Regression] tree check
   |simplify_builtin_call   |fail in
   ||simplify_builtin_call

[Bug c/81207] tree check fail in simplify_builtin_call

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-26
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r243378.

[Bug c/81207] New: tree check fail in simplify_builtin_call

[dcb314 at hotmail dot com]

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

Bug ID: 81207
   Summary: tree check fail in simplify_builtin_call
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

This code

typedef a;
static *b[] = {"'", ""};
c(d) {
  for (a e = 0; b[0]; e++)
if (strstr(d, b[e]))
  return 1;
}

does this

$ ~/gcc/results/bin/gcc -c -w -O2 bug361.c
during GIMPLE pass: forwprop
bug361.c: In function ‘c’:
bug361.c:3:1: internal compiler error: tree check: expected ssa_name, have
var_decl in simplify_builtin_call, at tree-ssa-forwprop.c:1244
 c(d) {
 ^
0x5793ee tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../trunk/gcc/tree.c:9861
0xda5f8d tree_check(tree_node*, char const*, int, char const*, tree_code)
../../trunk/gcc/tree.h:3083
0xda5f8d simplify_builtin_call
../../trunk/gcc/tree-ssa-forwprop.c:1244
0xda76bc execute
../../trunk/gcc/tree-ssa-forwprop.c:2473
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

This seems to be going wrong since some time before gcc revision 236947.

[Bug tree-optimization/81196] Number of iterations found for p!=q but not for p

[amker at gcc dot gnu.org]

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

--- Comment #2 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Probably some more elaborate handling in number_of_iterations_cond is
> required:
> 
>   /* We can handle the case when neither of the sides of the comparison is
>  invariant, provided that the test is NE_EXPR.  This rarely occurs in
>  practice, but it is simple enough to manage.  */
>   if (!integer_zerop (iv0->step) && !integer_zerop (iv1->step))
> {
>   tree step_type = POINTER_TYPE_P (type) ? sizetype : type;
>   if (code != NE_EXPR)
> return false;
> 
>   iv0->step = fold_binary_to_constant (MINUS_EXPR, step_type,
>iv0->step, iv1->step);
>   iv0->no_overflow = false;
>   iv1->step = build_int_cst (step_type, 0);
>   iv1->no_overflow = true;
> }
> 
> I think this exit is premature and the following works for the testcase.
> I suppose exiting is still required but can be moved to a later point,
> or the helpers now fully handle the case of non-constant iv1 ...
> Vectorization still fails with this due to runtime aliasing so it
> probably exposes some wrong-code issue.  CCing Bin who is now most
> familiar with the niter code.
> 
> Index: gcc/tree-ssa-loop-niter.c
> ===
> --- gcc/tree-ssa-loop-niter.c   (revision 249638)
> +++ gcc/tree-ssa-loop-niter.c   (working copy)
> @@ -1674,14 +1674,14 @@ number_of_iterations_cond (struct loop *
>if (!integer_zerop (iv0->step) && !integer_zerop (iv1->step))
>  {
>tree step_type = POINTER_TYPE_P (type) ? sizetype : type;
> -  if (code != NE_EXPR)
> -   return false;
> -
> -  iv0->step = fold_binary_to_constant (MINUS_EXPR, step_type,
> -  iv0->step, iv1->step);
> -  iv0->no_overflow = false;
> -  iv1->step = build_int_cst (step_type, 0);
> -  iv1->no_overflow = true;
> +  if (code == NE_EXPR)
> +   {
> + iv0->step = fold_binary_to_constant (MINUS_EXPR, step_type,
> +  iv0->step, iv1->step);
> + iv0->no_overflow = false;
> + iv1->step = build_int_cst (step_type, 0);
> + iv1->no_overflow = true;
> +   }
>  }
>  
>/* If the result of the comparison is a constant,  the loop is weird. 
> More

thanks for ccing, I will study the case.

[Bug tree-optimization/81192] [8 Regression] gcc ICE at -Os on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||tom at codesourcery dot com

--- Comment #3 from Richard Biener  ---
Ugh.  Tail-merging does very stupid stuff here, commoning a loop header with an
inner loop latch.

Now it _seems_ to me we run into a pre-existing bug in same_succ_flush_bbs
that 'same' might be NULL.  But it seems to be NULL from the start...

The following fixes it but not tail-mergings stupid (dangerous?) transform
that messes up loops.  Where do we get a chance to "cancel" merging
candidates?  We should cancel any that do not belong to the same loop father.

Index: gcc/tree-ssa-tail-merge.c
===
--- gcc/tree-ssa-tail-merge.c   (revision 249645)
+++ gcc/tree-ssa-tail-merge.c   (working copy)
@@ -810,7 +810,9 @@ same_succ_flush_bb (basic_block bb)
 {
   same_succ *same = BB_SAME_SUCC (bb);
   BB_SAME_SUCC (bb) = NULL;
-  if (bitmap_single_bit_set_p (same->bbs))
+  if (! same)
+;
+  else if (bitmap_single_bit_set_p (same->bbs))
 same_succ_htab->remove_elt_with_hash (same, same->hashval);
   else
 bitmap_clear_bit (same->bbs, bb->index);


Tom?

[Bug c/80116] Warn about macros expanding to multiple statements

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Done for GCC 8.

[Bug tree-optimization/81206] New: missed tail recursion

[rguenth at gcc dot gnu.org]

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

Bug ID: 81206
   Summary: missed tail recursion
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

We do not handle the tail-recursion in gcc.dg/torture/pr81203.c because there's
a stmt in the way (see PR81203).  A proper fix is to re-do tail-recursion
elimination isolating the individual paths to the return I think.

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[rguenth at gcc dot gnu.org]

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

Bug 81203 Summary: [8 Regression] tail recursion: internal compiler error: 
verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81203

   What|Removed |Added

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