[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
Carl, please revert the patch until you have time to investigate.  This will
cause havoc every time we vectorize with these patterns.

[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||carll at gcc dot gnu.org

--- Comment #7 from Bill Schmidt  ---
(In reply to Bill Schmidt from comment #5)
> The code is being vectorized in the "fails" dump and not being vectorized in
> the "works" dump.  This cannot be due to r249424, which does gimple folding
> on some Power-specific built-ins, for this is a generic test case that makes
> no use of such built-ins.
> 
> So either you have misidentified the revision responsible, or the code is
> somehow being compiled differently so that vectorization happens in one case
> and not the other.
> 
> Bill

Sorry, I got mixed up.  In introducing new multiply built-ins, Carl also
introduced some of the standard patterns that were previously not supported for
the POWER back ends, which allowed vectorization to occur that wouldn't have
before.  Very sorry for the mischaracterization.

Carl, we'll need you to investigate.  I assume that the semantics for the
standard patterns have been implemented incorrectly.  Let me know if you want
to discuss.

Bill

[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424

[seurer at gcc dot gnu.org]

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

--- Comment #6 from seurer at gcc dot gnu.org ---
So here is comparing 249423 (works) with 249424 (fails):


seurer@genoa:~/gcc/build/gcc-test2$ svn info $GCC_SRC
. . .
Revision: 249423
. . .
seurer@genoa:~/gcc/build/gcc-test2$ /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90
-B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/
-B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs
-I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp
-I/home/seurer/gcc/gcc-test2/libgomp/testsuite/../../include
-I/home/seurer/gcc/gcc-test2/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp -O3 -g
-B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs
-fintrinsic-modules-path=/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp
-L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs
-lgfortran -foffload=-lgfortran -lm -o ./a.16.1.exe
seurer@genoa:~/gcc/build/gcc-test2$ ./a.16.1.exe 
 X(   1 ) =55000. , Y(   1 ) =2.
 X(   2 ) =45010. , Y(   2 ) =4.
 X(   3 ) =45020. , Y(   3 ) =6.
 X(   4 ) =45030. , Y(   4 ) =8.
 X(   5 ) =45040. , Y(   5 ) =10.000
 X(   6 ) =45050. , Y(   6 ) =12.000
 X(   7 ) =45060. , Y(   7 ) =14.000
 X(   8 ) =45070. , Y(   8 ) =16.000
 X(   9 ) =45080. , Y(   9 ) =18.000
 X(  10 ) =45090. , Y(  10 ) =20.000


seurer@genoa:~/gcc/build/gcc-test$ svn info $GCC_SRC
Path: /home/seurer/gcc/gcc-test
Working Copy Root Path: /home/seurer/gcc/gcc-test
. . .
Revision: 249424
. . .
seurer@genoa:~/gcc/build/gcc-test$ /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90
-B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/
-B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs
-I/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp
-I/home/seurer/gcc/gcc-test/libgomp/testsuite/../../include
-I/home/seurer/gcc/gcc-test/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp -O3 -g3
-B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs
-fintrinsic-modules-path=/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp
-L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs
-lgfortran -foffload=-lgfortran -lm -o ./a.16.1.exe
seurer@genoa:~/gcc/build/gcc-test$ ./a.16.1.exe 

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x3fff98cb9a9f in ???
Segmentation fault (core dumped)


The options were the same:


<   .string "8 8.0.0 20170620 (experimental) [trunk revision 249424]
-mcpu=power8 -g3 -O3 -fmessage-length=0 -fopenmp
-fintrinsic-modules-path=/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp
-foffload=-lgfortran -fintrinsic-modules-path finclude"
---
>   .string " 8.0.0 20170620 (experimental) [trunk revision 249423] 
> -mcpu=power8 -g3 -O3 -fmessage-length=0 -fopenmp 
> -fintrinsic-modules-path=/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp
>  -foffload=-lgfortran -fintrinsic-modules-path finclude"




11c11
<   .file 1
"/home/seurer/gcc/gcc-test/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90"
---
>   .file 1 
> "/home/seurer/gcc/gcc-test2/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90"
171d170
<   addis 8,2,.LC1@toc@ha
174,187d172
<   addi 8,8,.LC1@toc@l
<   addis 10,2,.LC3@toc@ha
<   std 22,-80(1)
<   std 23,-72(1)
<   addi 10,10,.LC3@toc@l
<   std 24,-64(1)
<   std 25,-56(1)
<   addis 9,2,.LC2@toc@ha
<   std 26,-48(1)
<   std 27,-40(1)
<   addi 9,9,.LC2@toc@l
<   vspltisw 4,4
<   std 28,-32(1)
<   std 30,-16(1)
190,191c175,176
<   vspltisw 6,6
<   vspltisw 7,5
---
>   li 9,1
>   mtctr 9
194,196c179,180
<   std 0,16(1)
<   lis 0,0xfffe
<   std 31,-8(1)
---
>   std 22,-80(1)
>   std 23,-72(1)

[Bug target/81471] [5/6/7/8 Regression] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords|ra  |
   Target Milestone|--- |5.5
Summary|internal compiler error: in |[5/6/7/8 Regression]
   |curr_insn_transform, at |internal compiler error: in
   |lra-constraints.c:3495  |curr_insn_transform, at
   ||lra-constraints.c:3495

[Bug target/81471] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Gian-Carlo Pascutto from comment #4)
> Further reduced testcase:
> 
> #include 
> 
> uint64_t f(uint64_t x) {
> return ((uint32_t)x << 55) | ((uint32_t)x >> -23);
> }
> 
> This makes it more clear the code is UB, but AFAIK a compiler ICE doesn't
> fall under allowable UB :-)

I have following, somehow less UB testcase:

--cut here--
/* PR target/81471 */
/* { dg-do compile { target { ! ia32 } } } */
/* { dg-options "-O2 -mbmi2" } */

static inline unsigned int rotl (unsigned int x, int k)
{
  return (x << k) | (x >> (32 - k));
}

unsigned long long test (unsigned int z)
{
  return rotl (z, 55);
}
--cut here--

[Bug target/81471] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-17
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Ever confirmed|0   |1

--- Comment #5 from Uroš Bizjak  ---
Created attachment 41778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41778=edit
Patch in testing

I have a patch.

[Bug target/81471] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495

[gcp at sjeng dot org]

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

--- Comment #4 from Gian-Carlo Pascutto  ---
Further reduced testcase:

#include 

uint64_t f(uint64_t x) {
return ((uint32_t)x << 55) | ((uint32_t)x >> -23);
}

This makes it more clear the code is UB, but AFAIK a compiler ICE doesn't fall
under allowable UB :-)

[Bug target/81471] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495

[gcp at sjeng dot org]

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

--- Comment #3 from Gian-Carlo Pascutto  ---
Note the flags, -march=native in this case was Intel Haswell.

-O3 -march=haswell is required to trigger this.

[Bug tree-optimization/81428] [7/8 Regression] ICE: in build_one_cst, at tree.c:2079 with -O2. Fixed point division.

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 17 19:45:59 2017
New Revision: 250289

URL: https://gcc.gnu.org/viewcvs?rev=250289=gcc=rev
Log:
PR tree-optimization/81428
* match.pd (X / X -> one): Don't optimize _Fract divisions, as 1
can't be built for those types.

* gcc.dg/fixed-point/pr81428.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/fixed-point/pr81428.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/match.pd
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/81471] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495

[gcp at sjeng dot org]

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

--- Comment #2 from Gian-Carlo Pascutto  ---
#include 

inline uint32_t rotl(const uint32_t x, const int k) {
return (x << k) | (x >> (32 - k));
}

uint64_t s[2];

uint64_t random(void) {
const uint64_t s0 = s[0];
uint64_t s1 = s[1];
const uint64_t result = s0 + s1;

s1 ^= s0;
s[0] = rotl(s0, 55) ^ s1 ^ (s1 << 14); 
s[1] = rotl(s1, 36);

return result;
}

int main(void) {
  int x = random();
  return 0;
}

According to https://godbolt.org/g/8CVJ9a this is broken in all current gcc
versions, not just 5.4.0.

[Bug tree-optimization/81354] [5/6 Regression] Segmentation fault in SSA Strength Reduction using -O3

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
Doesn't reproduce for powerpc64le.  I'll have to build a cross.

[Bug tree-optimization/81365] [7/8 Regression] GCC miscompiles swap

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 17 19:42:37 2017
New Revision: 250288

URL: https://gcc.gnu.org/viewcvs?rev=250288=gcc=rev
Log:
PR tree-optimization/81365
* tree-ssa-phiprop.c (propagate_with_phi): When considering hoisting
aggregate moves onto bb predecessor edges, make sure there are no
loads that could alias the lhs in between the start of bb and the
loads from *phi.

* g++.dg/torture/pr81365.C: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr81365.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-ssa-phiprop.c

[Bug sanitizer/81066] sanitizer_stoptheworld_linux_libcdep.cc:276:22: error: aggregate ‘sigaltstack handler_stack’ has incomplete type and cannot be defined

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 17 19:41:08 2017
New Revision: 250287

URL: https://gcc.gnu.org/viewcvs?rev=250287=gcc=rev
Log:
Backported from mainline
2017-07-14  Jakub Jelinek  

PR sanitizer/81066
* sanitizer_common/sanitizer_linux.h: Cherry-pick upstream r307969.
* sanitizer_common/sanitizer_linux.cc: Likewise.
* sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc: Likewise.
* tsan/tsan_platform_linux.cc: Likewise.

Modified:
branches/gcc-7-branch/libsanitizer/ChangeLog
branches/gcc-7-branch/libsanitizer/sanitizer_common/sanitizer_linux.cc
branches/gcc-7-branch/libsanitizer/sanitizer_common/sanitizer_linux.h
   
branches/gcc-7-branch/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
branches/gcc-7-branch/libsanitizer/tsan/tsan_platform_linux.cc

[Bug c++/81258] [7/8 Regression] ICE on C++1z code with invalid decomposition declaration: in cp_finish_decl, at cp/decl.c:6760

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 17 19:39:23 2017
New Revision: 250286

URL: https://gcc.gnu.org/viewcvs?rev=250286=gcc=rev
Log:
Backported from mainline
2017-07-04  Jakub Jelinek  

PR c++/81258
* parser.c (cp_parser_decomposition_declaration): Diagnose invalid
forms of structured binding initializers.

* g++.dg/cpp1z/decomp21.C (foo): Adjust expected diagnostics.
* g++.dg/cpp1z/decomp30.C: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1z/decomp30.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/parser.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1z/decomp21.C

[Bug target/81225] [6/7 Regression] ICE with -mavx512ifma -O3 -ffloat-store

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 17 19:38:29 2017
New Revision: 250285

URL: https://gcc.gnu.org/viewcvs?rev=250285=gcc=rev
Log:
Backported from mainline
2017-06-30  Jakub Jelinek  

PR target/81225
* config/i386/sse.md (vec_extract_lo_): For
V8FI, V16FI and VI8F_256 iterators, use  instead
of nonimmediate_operand and  instead of m for
the input operand.  For V8FI iterator, always split if input is a MEM.
For V16FI and V8SF_256 iterators, don't test if both operands are MEM
if .  For VI4F_256 iterator, use 
instead of register_operand and  instead of v
for
the input operand.  Make sure both operands aren't MEMs for if not
.

* gcc.target/i386/pr81225.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr81225.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/sse.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/81471] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
(In reply to Gian-Carlo Pascutto from comment #0)

> In another module there is:

Please provide a compilable source file (preferably minimized) that triggers
the ICE, as instructed in [1].

[1] https://gcc.gnu.org/bugs/

[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
The code is being vectorized in the "fails" dump and not being vectorized in
the "works" dump.  This cannot be due to r249424, which does gimple folding on
some Power-specific built-ins, for this is a generic test case that makes no
use of such built-ins.

So either you have misidentified the revision responsible, or the code is
somehow being compiled differently so that vectorization happens in one case
and not the other.

Bill

[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424

[seurer at gcc dot gnu.org]

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

--- Comment #4 from seurer at gcc dot gnu.org ---
Looking at the difference in generated code.  The more recent (failing) builds
are generating a whole bunch of vector ops where the old (working) code did
not.  

< failing code (r250280)
> last working code (r249423)

171d170
<   addis 8,2,.LC1@toc@ha
174,187d172
<   addi 8,8,.LC1@toc@l
<   addis 10,2,.LC3@toc@ha
<   std 22,-80(1)
<   std 23,-72(1)
<   addi 10,10,.LC3@toc@l
<   std 24,-64(1)
<   std 25,-56(1)
<   addis 9,2,.LC2@toc@ha
<   std 26,-48(1)
<   std 27,-40(1)
<   addi 9,9,.LC2@toc@l
<   vspltisw 4,4
<   std 28,-32(1)
<   std 30,-16(1)
190,191c175,176
<   vspltisw 6,6
<   vspltisw 7,5
---
>   li 9,1
>   mtctr 9
194,196c179,180
<   std 0,16(1)
<   lis 0,0xfffe
<   std 31,-8(1)
---
>   std 22,-80(1)
>   std 23,-72(1)
199c183
<   vspltisw 8,2
---
>   lis 7,0x1062
202,203c186,187
<   ori 0,0,0xb560
<   lxvd2x 45,0,8
---
>   std 24,-64(1)
>   std 25,-56(1)
206,210c190
<   lxvd2x 37,0,10
<   li 10,2500
<   mtctr 10
<   lxvd2x 44,0,9
<   vspltisw 9,3
---
>   ori 7,7,0x4dd3
212a193,201
>   li 10,1
>   std 26,-48(1)
>   std 27,-40(1)
>   std 28,-32(1)
>   std 30,-16(1)
>   std 0,16(1)
>   lis 0,0xfffe
>   std 31,-8(1)
>   ori 0,0,0xb560
227,232d215
< .LBB28:
<   .loc 1 31 0
<   vspltisw 10,1
< .LBE28:
<   .loc 1 26 0
<   xxpermdi 45,45,45,2
234,236c217,219
<   addis 9,29,0x1
<   addi 9,9,-25536
<   .p2align 4,,15
---
>   addis 8,29,0x1
>   addi 8,8,-25540
>   .p2align 5,,31
238c221
< .LBB29:
---
> .LBB28:
240,256c223,230
<   vmulosw 11,13,12
<   vmulesw 0,13,12
<   vsraw 1,13,5
<   vmrgew 0,11,0
<   vsraw 0,0,6
<   vsubuwm 1,0,1
<   vslw 0,1,7
<   vsubuwm 0,0,1
<   vslw 0,0,8
<   vadduwm 0,0,1
<   vslw 0,0,9
<   vsubuwm 0,13,0
<   vadduwm 13,13,4
<   vadduwm 0,0,10
<   xxpermdi 0,32,32,2
<   stxvd2x 0,0,9
<   addi 9,9,16
---
>   mulhwu 9,10,7
>   srwi 9,9,6
>   mulli 9,9,1000
>   subf 9,9,10
>   addi 10,10,1
>   addi 9,9,1
>   stwu 9,4(8)
>   .loc 1 30 0

[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424

[seurer at gcc dot gnu.org]

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

--- Comment #3 from seurer at gcc dot gnu.org ---
Created attachment 41777
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41777=edit
Assembler for works

[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
Created attachment 41776
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41776=edit
Assembler for fails

[Bug libstdc++/81468] is_constructible gives the wrong answer for time_point construction

[daniel.kruegler at googlemail dot com]

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

--- Comment #1 from Daniel Krügler  ---
It seems that the implementation simply forgot to constrain overload
resolution, since this is the complete definition of the affected constructor:

template
  constexpr time_point(const time_point& __t)
  : __d(__t.time_since_epoch())
  { }

The constraints were added by LWG 1177,

http://cplusplus.github.io/LWG/lwg-defects.html#1177

[Bug tree-optimization/81162] [8 Regression] UBSAN switch triggers incorrect optimization in SLSR

[wschmidt at gcc dot gnu.org]

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

--- Comment #13 from Bill Schmidt  ---
Author: wschmidt
Date: Mon Jul 17 19:12:11 2017
New Revision: 250284

URL: https://gcc.gnu.org/viewcvs?rev=250284=gcc=rev
Log:
2017-07-17  Bill Schmidt  

PR tree-optimization/81162
* gcc.dg/pr81162.c: Move this to...
* gcc.dg/ubsan/pr81162.c: ...here.


Added:
trunk/gcc/testsuite/gcc.dg/ubsan/pr81162.c
Removed:
trunk/gcc/testsuite/gcc.dg/pr81162.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug other/81345] -Wall resets -Wstringop-overflow to 1 from the default 2

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail|7.1.0   |8.0

--- Comment #7 from Martin Sebor  ---
Removing 7.1 from Known to fail versions because unlike 8.0 (prior to r247401)
it doesn't use LangEnabledBy for -Wstringop-overflow.

[Bug libstdc++/81469] std::uncaught_exception should be marked as deprecated for C++1z

[emi_cuenca at hotmail dot com]

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

emi_cuenca at hotmail dot com changed:

   What|Removed |Added

 CC||emi_cuenca at hotmail dot com

--- Comment #1 from emi_cuenca at hotmail dot com ---
Please assign this bug to me

[Bug c/81471] New: internal compiler error: in curr_insn_transform, at lra-constraints.c:3495

[gcp at sjeng dot org]

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

Bug ID: 81471
   Summary: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3495
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcp at sjeng dot org
  Target Milestone: ---

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

-Wall -Wextra -pipe -O3 -g -ffast-math -march=native -flto -fopenmp -std=c++11
-DNDEBUG -D_CONSOLE

UCTSearch.cpp:130:1: error: unable to generate reloads for:
 }
 ^
(insn 1085 1084 1086 88 (set (reg:DI 538 [ D.12393 ])
(zero_extend:DI (rotatert:SI (subreg:SI (reg/v:DI 321 [ s0 ]) 0)
(const_int -23 [0xffe9] Random.cpp:30 590
{*bmi2_rorxsi3_1_zext}
 (nil))
UCTSearch.cpp:130:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3495
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: fatal error: /usr/bin/g++-5.real returned 1 exit status
compilation terminated.
/usr/bin/ld.bfd.real: error: lto-wrapper failed

The offending function is:

uint64 Random::random(void) {
const uint64 s0 = s[0];
uint64 s1 = s[1];
const uint64 result = s0 + s1;

s1 ^= s0;
s[0] = Utils::rotl(s0, 55) ^ s1 ^ (s1 << 14);<<<
s[1] = Utils::rotl(s1, 36);

return result;
}

In another module there is:

inline uint32 rotl(const uint32 x, const int k) {
return (x << k) | (x >> (32 - k));
}

Note that the code is buggy, the rotl should be using 64-bit integers. But gcc
shouldn't ICE.

[Bug bootstrap/81470] New: [8 Regression] Bootstrap comparison failures in gcc/ada

[rai...@emrich-ebersheim.de]

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

Bug ID: 81470
   Summary: [8 Regression] Bootstrap comparison failures in
gcc/ada
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rai...@emrich-ebersheim.de
  Target Milestone: ---

With current trunk revision 250281 I get several bootstrap comparison failures
in gcc/ada on x86_64-w64-mingw bootstrap with msys2. That's a regression
against trunk.

Bootstrap comparison failure!
gcc/ada/ali-util.o differs
gcc/ada/ali.o differs
gcc/ada/b_gnatb.o differs
gcc/ada/checks.o differs
gcc/ada/erroutc.o differs
gcc/ada/expander.o differs
gcc/ada/exp_aggr.o differs
gcc/ada/exp_attr.o differs
gcc/ada/exp_ch3.o differs
gcc/ada/exp_ch4.o differs
gcc/ada/exp_ch5.o differs
gcc/ada/exp_ch6.o differs
gcc/ada/exp_dbug.o differs
gcc/ada/exp_disp.o differs
gcc/ada/freeze.o differs
gcc/ada/gnat1drv.o differs
gcc/ada/gnatbind.o differs
gcc/ada/lib-xref.o differs
gcc/ada/output.o differs
gcc/ada/par.o differs
gcc/ada/prep.o differs
gcc/ada/prepcomp.o differs
gcc/ada/restrict.o differs
gcc/ada/rtsfind.o differs
gcc/ada/s-os_lib.o differs
gcc/ada/scn.o differs
gcc/ada/sem_attr.o differs
gcc/ada/sem_ch12.o differs
gcc/ada/sem_ch13.o differs
gcc/ada/sem_ch6.o differs
gcc/ada/sem_ch8.o differs
gcc/ada/sem_eval.o differs
gcc/ada/sem_prag.o differs
gcc/ada/sem_warn.o differs
gcc/ada/sinput-d.o differs
gcc/ada/stringt.o differs
gcc/ada/switch-b.o differs
gcc/ada/switch-c.o differs
gcc/ada/targparm.o differs
gcc/ada/tree_io.o differs
gcc/ada/widechar.o differs

[Bug libstdc++/81469] New: std::uncaught_exception should be marked as deprecated for C++1z

[daniel.gutson at intel dot com]

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

Bug ID: 81469
   Summary: std::uncaught_exception should be marked as deprecated
for C++1z
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.gutson at intel dot com
  Target Milestone: ---

I think that in C++1z/17, std::uncaught_exception should be marked as
[[deprecated]].

[Bug libstdc++/81468] New: is_constructible gives the wrong answer for time_point construction

[howard.hinnant at gmail dot com]

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

Bug ID: 81468
   Summary: is_constructible gives the wrong answer for time_point
construction
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: howard.hinnant at gmail dot com
  Target Milestone: ---

This should compile, but does not:

#include 
#include 

template 
using sys_time = std::chrono::time_point;

int
main()
{
using namespace std;
using namespace std::chrono;
static_assert(!is_constructible{}, "");
//sys_time s{sys_time{123ms}};
}

[Bug go/81393] Bootstrap failure on s390x-linux while building libgo against recent glibc

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Only on the trunk.  Could you please backport it to release branches as well? 
I think all of gcc 7, 6 and 5 are affected by this.

[Bug c/81467] New: AVX-512 support for inline assembly

[alekshs at hotmail dot com]

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

Bug ID: 81467
   Summary: AVX-512 support for inline assembly
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alekshs at hotmail dot com
  Target Milestone: ---

I'm trying some avx-512 code with the inline assembly.

1) Clobbering xmm16-31 and k-type registers won't work. I guess it won't work
in ymm16-31 or zmm16-31 either: 

error: unknown register name ‘%xmm16’ in ‘asm’
error: unknown register name ‘%k1’ in ‘asm’

2) I'm having a problem trying to issue a

"VMOVDQU32 0(%0), %%ZMM0 {k1}{z}\n"

I also tried it with 

 "VMOVDQU32 0(%0), %%ZMM0 {%k1}{z}\n"

and

 "VMOVDQU32 0(%0), %%ZMM0 {%%k1}{z}\n"

and I also added % and %% in front of the z flag to see if it'll work. It's
possible I'm doing something wrong in the syntax although I tried several
permutations. Googling for examples didn't get me any meaningful results.

[Bug target/81456] [7/8 Regression] x86-64 optimizer makes wrong decision when optimizing for size

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #2 from James Greenhalgh  ---
(In reply to Martin Liška from comment #1)
> Confirmed, started with r238594.

The cost model relies on the target giving a reasonable approximation for an
instruction size through ix86_rtx_costs.

The basic branch structure looks like:


t = mod
if (a / b % 2)
  t = b - mod


In RTL, this looks like:

  (insn 14 13 15 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 99)
(const_int 0 [0]))) "foo.c":5 3 {*cmpsi_ccno_1}
 (expr_list:REG_DEAD (reg:SI 99)
(nil)))
  (jump_insn 15 14 16 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref:DI 22)
(pc))) "foo.c":5 617 {*jcc_1}
 (expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 2 (nil)))
   -> 22)

  (note 16 15 17 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
  (insn 17 16 22 3 (parallel [
(set (reg/v:SI 93 [  ])
(minus:SI (reg/v:SI 95 [ b ])
(reg/v:SI 93 [  ])))
(clobber (reg:CC 17 flags))
]) "foo.c":5 273 {*subsi_1}
 (expr_list:REG_DEAD (reg/v:SI 95 [ b ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
  (code_label 22 17 25 4 1 (nil) [1 uses])

That is to say, we're starting with a comparison, a branch and a subtract. We
want to know if that sequence is cheaper than a subtract a and conditional
select.

In the cost model, we take an approximation for the branch and comparison of
COST_N_INSNS(2) and the backend tells us the cost of a subtract is
COST_N_INSNS(1). Thus, the cost before transformation is COST_N_INSNS (3) ==
12.

After the transformation, we create this RTL:

  (insn 31 0 32 (set (reg:SI 102)
(reg/v:SI 93 [  ])) 82 {*movsi_internal}
   (nil))

  (insn 32 31 33 (parallel [
(set (reg:SI 101)
(minus:SI (reg/v:SI 95 [ b ])
(reg/v:SI 93 [  ])))
(clobber (reg:CC 17 flags))
]) 273 {*subsi_1}
   (nil))

  (insn 33 32 34 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 99)
(const_int 0 [0]))) 3 {*cmpsi_ccno_1}
   (nil))

  (insn 34 33 0 (set (reg/v:SI 93 [  ])
(if_then_else:SI (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg:SI 101)
(reg:SI 102))) 966 {*movsicc_noc}
   (nil))

That is a set to protect the "false" value, the same subtract, a comparison to
set the flags, and a conditional move. When we ask the backend to give us costs
for this it gives us COST_N_INSNS(1) for the set, COST_N_INSNS(1) for the
subtract, COST_N_INSNS(1) for the comparison, and COST_N_INSNS(2) for the
conditional move. That's a total cost of COST_N_INSNS(5) == 20 for the whole
sequence. 20 > 12, so from the perspective of the ifcvt cost model this is a
bad transformation.

Note that ifcvt is not aware that an extra set will be introduced after the
original subtract, nor does it care about the final movl %edx, %eax as that is
unconditional. I thinks it is being asked to trade test, branch, subtract for
set, subtract, test branch - when you spell it out like that it should be clear
why it makes the decision it does.

I can't treproduce your comment about -m32 - I still see branches at -Os.

[Bug other/52992] Incorrect sprintf format in fixincludes/fixincl.c

[andris at gcc dot gnu.org]

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

Andris Pavenis  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||andris at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |andris at gcc dot 
gnu.org

--- Comment #1 from Andris Pavenis  ---
Fixed by r186759 soon after submitting of the bug

[andris@localhost gcc]$ svn propget --revprop -r 186759 svn:log
2012-04-24  Tristan Gingold  

* fixincl.c (fix_with_system): Add missing specifier.
* configure.ac: Default to twoprocess on vms.
* configure: Regenerate.

(Old bug cleanup)

[Bug middle-end/70140] Inefficient expansion of __builtin_mempcpy

[wilco at gcc dot gnu.org]

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

--- Comment #7 from Wilco  ---
(In reply to Martin Liška from comment #6)
> Created attachment 41772 [details]
> Patch candidate
> 
> I'm going to prepare some test-cases for that. Does it look good?

Yes, it now inlines small constant sizes. However large and variable sized
copies have the wrong return value:

void *f1(void *p, void *q) { return __builtin_mempcpy(p, q, 256); }

f1:
mov x2, 256
b   memcpy

[Bug preprocessor/71681] header.gcc file lookup is broken for -remap

[andris at gcc dot gnu.org]

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

Andris Pavenis  changed:

   What|Removed |Added

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

--- Comment #6 from Andris Pavenis  ---
Fix is committed. Closing

[Bug middle-end/81464] [8 Regression] ICE in expand_omp_for_static_chunk, at omp-expand.c:4236

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Minimal example:
...
program main
  implicit none
  real, dimension(:,:),allocatable :: a, b, c
  real :: sm

  allocate (a(2,2), b(2,2), c(2,2))

  call random_number(a)
  call random_number(b)

  c = matmul(a,b)
  sm = sum(c)

  deallocate(a,b,c)

end program main
...

The assert happens in expand_omp_for_static_chunk when trying to expand a
region from bb71 to bb72:
...
(gdb) p region.entry.index
$1 = 71
(gdb) p region.exit.index
$2 = 72
...

In other words:
...
;;   basic block 71, loop depth 0, freq 48, maybe hot
;;prev block 69, next block 67, flags: (NEW)
;;pred:   69 [always]  (FALLTHRU)
  #pragma omp for schedule(static,2)
  for (ivtmp_87 = 0; ivtmp_87 < _144; ivtmp_87 =  + 1)
;;succ:   67 [always]  (FALLTHRU)
;;72 [never (guessed)]

   ...

;;   basic block 72, loop depth 0, freq 47, maybe hot
;;   Invalid sum of incoming frequencies 269, should be 47
;;prev block 63, next block 70, flags: (NEW)
;;pred:   46 [always]  (FALLTHRU)
;;71 [never (guessed)] 
  # .MEM_88 = PHI <.MEM_86(46), .MEM_86(71)>
  #pragma omp return(nowait)
;;succ:   70 [always]  (FALLTHRU)
...

When we're ICE-ing, we're executing a bit:
...
  /* When we redirect the edge from trip_update_bb to iter_part_bb, we  
 remove arguments of the phi nodes in fin_bb.  We need to create
 appropriate phi nodes in iter_part_bb instead.  */
...

When we look at fin_bb, we see indeed that one of the arguments of the phi has
been dropped.:
...
(gdb) call debug_bb (fin_bb)
;; basic block 72, loop depth 0, freq 47, maybe hot
;;  prev block 100, next block 70, flags: (NEW)
;;  pred:   98 [never (guessed)]  (FALSE_VALUE)
# .MEM_88 = PHI <.MEM_86(98)>
;;  succ:   70 [always]  (FALLTHRU)
...

But since the arguments were equal anyway, this is fine, and there's no need to
do anything.

Tentative patch:
...
diff --git a/gcc/omp-expand.c b/gcc/omp-expand.c
index 929c530..089bffc 100644
--- a/gcc/omp-expand.c
+++ b/gcc/omp-expand.c
@@ -4206,6 +4206,10 @@ expand_omp_for_static_chunk (struct omp_region *region,
  source_location locus;

  phi = psi.phi ();
+ if (operand_equal_p (gimple_phi_arg_def (phi, 0),
+  gimple_phi_arg_def (phi, 1), 0))
+ continue;
+
  t = gimple_phi_result (phi);
  gcc_assert (t == redirect_edge_var_map_result (vm));

...

[Bug c/46742] -Wparentheses unexpectedly misses some cases

[sirl at gcc dot gnu.org]

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

--- Comment #5 from Franz Sirl  ---
Actually, after seeing a large bunch of justified warnings in our codebase with
the disabled APPEARS_TO_BE_BOOLEAN_EXPR_P check, I wonder if a new option like
-Wbool-bitwise-parentheses (thus not depending on the logical NOT) would make
sense?

Note that this is heavily influenced by my code reading/code debugging POV, I
really hate it if I need lots of context to decide whether a statement in a
codebase unknown to me is correct or not. A warning like
-Wbool-bitwise-parentheses encourages programmers to make their intention clear
from the start. Or, in the best case, even uncovers coding bugs or typos early.

[Bug gcov-profile/81442] error: verify_flow_info: REG_BR_PROB is set but cfg probability is not during RTL pass: outof_cfglayout

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
(In reply to cesar from comment #4)
> I posted a patch that fixes this issue on July 13, 2017:
> 
> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00750.html
> 
> It is pending review.

Assuming this is indeed the same issue (which is not easy to verify on the spot
because the link you posted does not mention a specific ICE it's trying to fix,
nor does it reference a PR where the problem is shown in more detail), the
patches handle the issue in different ways:
- handle the case that there's an edge with uninitialized probability
- initialize probability on some edges

At first glance I'd say that one doesn't necessarily exclude the other.

[Bug tree-optimization/81403] [8 Regression] wrong code at -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Kind-of a duplicate of PR80620 as well.  Testing a patch.

[Bug tree-optimization/81403] [8 Regression] wrong code at -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
So this is during partial-PRE insertion where after PRE insertion of

Found partial redundancy for expression {bit_not_expr,_13} (0020)
Inserted _33 = ~_3;
 in predecessor 5 (0014)
Created phi prephitmp_34 = PHI <_33(5), _8(6)>
 in block 7 (0020)

we value-replace 0020 by prephitmp_34 and thus during partial-PRE
phi-translation
find, when translating _14 & 10393, _8 for _14 (0020) to be translated across
the edge exposing the range.

On the other edge we get from translating _14 & 10393 all the way to
translating
var_9.5_12 = var_9 as operand which leads us to var_9.1_2 = var_9 and
ultimatively
to _8 via "simplification" of ~_3 which has a leader of _33 (fine IMHO), but
unfortunately _33 has a value number of _8.

So PRE doing any insertion of a lexically equivalent expression will
necessarily
end up with a SCCVN value-number that might have range info that is not valid
there.  Thus:

tree result = vn_nary_op_lookup_pieces (newnary->length,
newnary->opcode,
newnary->type,
>op[0],
);
if (result && is_gimple_min_invariant (result))
  return get_or_alloc_expr_for_constant (result);

expr = pre_expr_pool.allocate ();
expr->kind = NARY;
expr->id = 0;
if (nary)
  {
PRE_EXPR_NARY (expr) = nary;
new_val_id = nary->value_id;
get_or_alloc_expression_id (expr);
  }

needs adjustment to push away range-info.

[Bug c/81453] relational expression involving null pointer not diagnosed with -Wall

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #1 from Eric Gallager  ---
Related: bug 7651

[Bug tree-optimization/81462] [8 Regression] ICE in estimate_bb_frequencies at gcc/predict.c:3546

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #2 from Markus Trippelsdorf  ---
Looks like a dup of PR81318.

[Bug middle-end/70992] Infinite recursion between fold_build2_stat_loc and fold_binary_loc w/ -fwrapv

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #6 from Alexander Monakov  ---
We can simply fold A / 0 * B and A / 0 + B to 1 / 0 or 0 / 0.

I wonder why fold_plusminus_mult_expr puts the addition inside, that doesn't
appear useful?

[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[kumba at gentoo dot org]

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

--- Comment #3 from Joshua Kinard  ---
It's just build/genrecog.c.  I had a stale build environment file that was
still sending "-j3" to 'make'.  I fixed that and restarted from where it last
left off, and it gets to genrecog.c and spent about ~20 minutes doing something
to that file before exhausting all virtual memory (so it claims).

Here's the last 'ps' output I got right before it stopped:
# ps uw 7054 | grep [g]enrecog
portage   7054 99.5 47.0 2056256 979712 pts/1  R+   09:36  20:57
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/./prev-gcc/cc1plus -quiet
-nostdinc++ -I . -I build -I
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/gcc -I
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/gcc/build -I
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/gcc/../include -I
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/gcc/../libcpp/include
-iprefix
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/prev-gcc/../../../lib/gcc/mips64-unknown-linux-gnu/7.1.0/
-isystem /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/./prev-gcc/include
-isystem
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/./prev-gcc/include-fixed
-D_GNU_SOURCE -D IN_GCC -D HAVE_CONFIG_H -D GENERATOR_FILE -isystem
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/prev-mips64-unknown-linux-gnu/libstdc++-v3/include/mips64-unknown-linux-gnu
-isystem
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/prev-mips64-unknown-linux-gnu/libstdc++-v3/include
-isystem
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/libstdc++-v3/libsupc++
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/gcc/genrecog.c -meb
-quiet -dumpbase genrecog.c -march=mips3 -mtune=mips3 -mplt -mabi=n32 -mllsc
-mips3 -mno-shared -auxbase-strip build/genrecog.o -gtoggle -O2 -Wextra -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wsuggest-attribute=format
-Woverloaded-virtual -Wpedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-fno-PIE -o -

This particular MIPS machine, an old Silicon Graphics platform, has memory
issues in the kernel (limited to 2GB of main memory because of what I think is
a hardware quirk I haven't figured out how to work around yet), but this is the
first time I've ever seen it run out of virtual memory compiling something in
the last 10 years.  It just recently completed gcc-6.3.0 across multiple ISAs
and ABIs about a week ago (it's a build machine), and also did gcc-7.1.0 in O32
under glibc and uclibc-ng.  So this is why I suspect there is something wrong
with the MIPS-III/N32 case.  I have not tried MIPS-IV yet (the machine only
supports the older four MIPS ISAs).  I do not have a bootstrapped N32 userland
under a different libc other than glibc.  I also lack a pure N64 userland to
test with as well.

The CPU is ~600MHz with 2MB of L2 cache, so I find that it spending 20+ minutes
on one C file to be rather abnormal, and I think there's a
runawaysomethinggoing on (linked list allocation or such?).

If there's something else I can grab with gdb or forcing a coredump, let me
know what commands to run.

[Bug c/46742] -Wparentheses unexpectedly misses some cases

[sirl at gcc dot gnu.org]

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

--- Comment #4 from Franz Sirl  ---
APPEARS_TO_BE_BOOLEAN_EXPR_P was introduced with r141340 (PR 7543), but I
cannot find a discussion on why this suppression makes sense. When I disable it
I only see 3 places where it triggers in trunk:

gcc/cp/lex.c:115:24: warning: suggest parentheses around operand of '!' or
change '&' to '&&' or '!' to '~' [-Wparentheses]

libdecnumber/decNumber.c:6036:11: warning: suggest parentheses around operand
of '!' or change '&' to '&&' or '!' to '~' [-Wparentheses]

libgcc/libgcc2.c:1949:36: warning: suggest parentheses around operand of '!' or
change '&' to '&&' or '!' to '~' [-Wparentheses]

To my eyes in all 3 cases a '&&' would be clearer, so the warning shouldn't be
suppressed?
If changing the behaviour of -Wparentheses after this long time is considered a
problem, maybe we could add the stricter check to the relatively new
-Wlogical-not-parentheses like clang? 

Note: clang documents -Wlogical-not-parentheses for comparison AND bitwise
operators, GCC only for comparison operators.

[Bug gcov-profile/81442] error: verify_flow_info: REG_BR_PROB is set but cfg probability is not during RTL pass: outof_cfglayout

[cesar at gcc dot gnu.org]

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

cesar at gcc dot gnu.org changed:

   What|Removed |Added

 CC||cesar at gcc dot gnu.org

--- Comment #4 from cesar at gcc dot gnu.org ---
I posted a patch that fixes this issue on July 13, 2017:

https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00750.html

It is pending review.

[Bug middle-end/70992] Infinite recursion between fold_build2_stat_loc and fold_binary_loc w/ -fwrapv

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
I can confirm that even Comment 4 is the same extract_muldiv_1 <->
fold_plusminus_mult_expr issue:

((2147483648 / 0) * 2) + 2
<->
2 * (2147483648 / 0 + 1)

So the question is: where should we break the tie?

[Bug target/81426] [SH]: unable to find a register to spill in class 'R0_REGS' when building webkit2gtk

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #6 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #5)
> This sounds like a different issue.  Can you please create another PR for
> that with the title "syntax error in @(disp,[Rn, gbr, pc]) when compiling
> with -mlra" and attach the reproducer?

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

Dropping "-mlra" from the command line fixes the issue.

[Bug target/81466] [SH]: Error: syntax error in @(disp,[Rn, gbr, pc]) when building with -mlra

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #1 from John Paul Adrian Glaubitz  ---
Created attachment 41775
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41775=edit
Generated assembly for MapPrototype.cpp (gzipped)

[Bug sanitizer/63361] Test case c-c++-common/ubsan/float-cast-overflow-1.c fails on Pentium2

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
grep FLT_EVAL_METHOD config/*/*
says the only problematic arches are i?86, s390*, m68k*, arm and maybe aarch64.
add-ieee-options has just i?86 and m68k (clearly wrong, because it really
should
not use
[istarget i?86-*-*]
but
[check_effective_target_ia32]
ieee.exp seems to do that properly.
So, I think you should add -ffloat-store if ia32, or if m68k-*-*, and add
-mieee if alpha* or sh*.

[Bug target/81466] New: [SH]: Error: syntax error in @(disp,[Rn, gbr, pc]) when building with -mlra

[glaubitz at physik dot fu-berlin.de]

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

Bug ID: 81466
   Summary: [SH]: Error: syntax error in @(disp,[Rn, gbr, pc])
when building with -mlra
   Product: gcc
   Version: 7.1.0
   URL: https://people.debian.org/~glaubitz/webkit2gtk_2.16.5-
1-mlra_sh4.build
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
  Target Milestone: ---
Target: sh*-*-*

Created attachment 41774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41774=edit
Intermediate source for MapPrototype.cpp (gzipped)

After running into #81426 when trying to build webkit2gtk on Debian sh4
unstable, I tried building with "-mlra". While this actually fixed #81246,
another issue was exposed that only shows when using "-mlra":

[ 21%] Building CXX object
Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/runtime/MapPrototype.cpp.o
cd /<>/obj-sh4-linux-gnu/Source/JavaScriptCore && /usr/bin/c++  
-DBUILDING_GTK__=1 -DBUILDING_JavaScriptCore -DBUILDING_WITH_CMAKE=1
-DDATA_DIR=\"share\" -DGETTEXT_PACKAGE=\"WebKit2GTK-4.0\" -DHAVE_CONFIG_H=1
-DJavaScriptCore_EXPORTS -DLIBDIR=\"/usr/lib/sh4-linux-gnu\"
-DSTATICALLY_LINKED_WITH_WTF -DUSER_AGENT_GTK_MAJOR_VERSION=\"604\"
-DUSER_AGENT_GTK_MINOR_VERSION=\"1\" -DWEBKITGTK_API_VERSION_STRING=\"4.0\"
-isystem /usr/include/glib-2.0 -isystem /usr/lib/sh4-linux-gnu/glib-2.0/include
-I/<>/obj-sh4-linux-gnu -I/<>/Source/JavaScriptCore
-I/<>/Source/JavaScriptCore/..
-I/<>/Source/JavaScriptCore/API
-I/<>/Source/JavaScriptCore/ForwardingHeaders
-I/<>/Source/JavaScriptCore/assembler
-I/<>/Source/JavaScriptCore/b3
-I/<>/Source/JavaScriptCore/b3/air
-I/<>/Source/JavaScriptCore/bindings
-I/<>/Source/JavaScriptCore/builtins
-I/<>/Source/JavaScriptCore/bytecode
-I/<>/Source/JavaScriptCore/bytecompiler
-I/<>/Source/JavaScriptCore/dfg
-I/<>/Source/JavaScriptCore/disassembler
-I/<>/Source/JavaScriptCore/disassembler/udis86
-I/<>/Source/JavaScriptCore/disassembler/ARM64
-I/<>/Source/JavaScriptCore/domjit
-I/<>/Source/JavaScriptCore/ftl
-I/<>/Source/JavaScriptCore/heap
-I/<>/Source/JavaScriptCore/debugger
-I/<>/Source/JavaScriptCore/inspector
-I/<>/Source/JavaScriptCore/inspector/agents
-I/<>/Source/JavaScriptCore/inspector/augmentable
-I/<>/Source/JavaScriptCore/inspector/remote
-I/<>/Source/JavaScriptCore/interpreter
-I/<>/Source/JavaScriptCore/jit
-I/<>/Source/JavaScriptCore/llint
-I/<>/Source/JavaScriptCore/parser
-I/<>/Source/JavaScriptCore/profiler
-I/<>/Source/JavaScriptCore/replay
-I/<>/Source/JavaScriptCore/runtime
-I/<>/Source/JavaScriptCore/tools
-I/<>/Source/JavaScriptCore/wasm
-I/<>/Source/JavaScriptCore/wasm/js
-I/<>/Source/JavaScriptCore/yarr
-I/<>/obj-sh4-linux-gnu/DerivedSources/ForwardingHeaders
-I/<>/obj-sh4-linux-gnu/DerivedSources/JavaScriptCore
-I/<>/obj-sh4-linux-gnu/DerivedSources/JavaScriptCore/inspector
-I/<>/Source/bmalloc -I/<>/Source/WTF
-I/<>/obj-sh4-linux-gnu/DerivedSources
-I/<>/Source/ThirdParty  -g1 -O2
-fdebug-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs
-fstack-protector-strong -Wformat -Werror=format-security -mlra -Wdate-time
-D_FORTIFY_SOURCE=2 -Wall -DENABLE_ASSEMBLER=0 -DNDEBUG -DG_DISABLE_CAST_CHECKS
-Wdate-time -D_FORTIFY_SOURCE=2 -Wall -DENABLE_ASSEMBLER=0 -DNDEBUG
-DG_DISABLE_CAST_CHECKS -fno-exceptions -fno-strict-aliasing -fno-rtti
-std=c++1y -fPIC   -Wall -Wextra -Wcast-align -Wformat-security
-Wmissing-format-attribute -Wpointer-arith -Wundef -Wwrite-strings  -o
CMakeFiles/JavaScriptCore.dir/runtime/MapPrototype.cpp.o -c
/<>/Source/JavaScriptCore/runtime/MapPrototype.cpp
(...)
/tmp/cck5XKuE.s: Assembler messages:
/tmp/cck5XKuE.s:3780: Error: syntax error in @(disp,[Rn, gbr, pc])
/tmp/cck5XKuE.s:3780: Error: invalid operands for opcode
/tmp/cck5XKuE.s:3787: Error: syntax error in @(disp,[Rn, gbr, pc])
/tmp/cck5XKuE.s:3787: Error: invalid operands for opcode
Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/build.make:18583: recipe
for target
'Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/runtime/MapPrototype.cpp.o'
failed
make[3]: ***
[Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/runtime/MapPrototype.cpp.o]
Error 1

Dropping "-mlra" from the command line above fixes the issue.

Full log in [1]. Attaching the output from running with "-save-temps".

> [1] https://people.debian.org/~glaubitz/webkit2gtk_2.16.5-1-mlra_sh4.build

[Bug tree-optimization/81462] [8 Regression] ICE in estimate_bb_frequencies at gcc/predict.c:3546

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Jan Hubicka  ---
Created attachment 41773
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41773=edit
Patch I am testing.

[Bug middle-end/70140] Inefficient expansion of __builtin_mempcpy

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Created attachment 41772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41772=edit
Patch candidate

I'm going to prepare some test-cases for that. Does it look good?

[Bug sanitizer/63361] Test case c-c++-common/ubsan/float-cast-overflow-1.c fails on Pentium2

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #12)
> Comment on attachment 41771 [details]
> Patch candidate
> 
> I don't think we want to add -ffloat-store unconditionally, only for targets
> that really need it.

Ok, thus can you please help me how to do a condition of affected x87 CPUs?

[Bug c/6906] warn about asserts with side effects

[owner at bugs dot debian.org]

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

--- Comment #8 from owner at bugs dot debian.org ---
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian GCC Maintainers 

If you wish to submit further information on this problem, please
send it to 123...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

[Bug tree-optimization/81461] Optimization for removing same variable comparisons in loop: while(it != end1 && it != end2)

[antoshkka at gmail dot com]

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

--- Comment #2 from Antony Polukhin  ---
(In reply to Richard Biener from comment #1)
> jump threading

Thanks, now I know hot the transformation of

for (;it != end && it != *chunks + 128; ++it) {
sum += *it;
}

into

new_end = (it <= end && end <= *chunks + 128 ? end : *chunks + 128);
for (;new_end; ++it) {
sum += *it;
}

is called!

Loop unswitching will also do the job, but it produces a ~5 instructions longer
assembly because of the loop's body duplication: 

if (it <= end && end <= *chunks + 128) {
for (;it != end;
  ++it) { sum += *it; } // duplicated
} else {
for (;it != *chunks + 128;
  ++it) { sum += *it; } // duplicated
}

[Bug sanitizer/63361] Test case c-c++-common/ubsan/float-cast-overflow-1.c fails on Pentium2

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Comment on attachment 41771
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41771
Patch candidate

I don't think we want to add -ffloat-store unconditionally, only for targets
that really need it.

[Bug c/6906] warn about asserts with side effects

[felix.von.s at posteo dot de]

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

felix  changed:

   What|Removed |Added

 CC||felix.von.s at posteo dot de

--- Comment #7 from felix  ---
What's wrong with the __builtin_pure_p approach? Sure, the diagnostics
generated by __attribute__((warning)) will be ugly, but it's still something.
It's also very simple to implement: it's just !TREE_SIDE_EFFECTS().

In fact, I patched my copy of GCC to add __builtin_pure_p defined just like
that and it seems to work fine. Might submit it soon (I didn't write any tests,
though).

[Bug sanitizer/63361] Test case c-c++-common/ubsan/float-cast-overflow-1.c fails on Pentium2

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
Created attachment 41771
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41771=edit
Patch candidate

Can you please test the attached patch on Pentium 2 machine?

[Bug sanitizer/63361] Test case c-c++-common/ubsan/float-cast-overflow-1.c fails on Pentium2

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
It's a typical x87 code, where registers have better precision that a double.
Thus adding -ffloat-store fixed the test-case, I'll send a patch.

[Bug middle-end/28859] GCC calls malloc from within signal context

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Yep, let's forget about it ;)

[Bug sanitizer/63361] Test case c-c++-common/ubsan/float-cast-overflow-1.c fails on Pentium2

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #9 from Martin Liška  ---
Nice, confirmed. There's minimal reproducer:

cat float-cast-overflow-1.i


int
main (void)
{
  volatile double d;

  volatile long long ll;
  d = 0.0;
  d = 0x7fffLL;
  (ll) = (d) -5.0;

  return 0;
}

I'll take a look. Thanks.

[Bug middle-end/28859] GCC calls malloc from within signal context

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Mon, 17 Jul 2017, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28859
> 
> Martin Liška  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2017-07-17
>  Ever confirmed|0   |1
> 
> --- Comment #5 from Martin Liška  ---
> Do I understand it that practically impossible to handle that as we would have
> to somehow detect all malloc-family functions triggered after a crash_signal 
> is
> executed?
> 
> In case of PR81382 we either need to have layout class not containing of types
> that can possibly allocate a memory via malloc, or we can have an env variable
> that will prevent displaying of locations if crash_signal happened? Would it 
> be
> welcomed one of there approaches?

I think it's just not possible to easily do sth here, so we shouldn't care 
too much IMHO.

[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #15 from Jonathan Wakely  ---
Thanks, Daniel. Let's reopen this to make the T -> const T& changes.

[Bug tree-optimization/81354] [5/6 Regression] Segmentation fault in SSA Strength Reduction using -O3

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org

--- Comment #4 from Bill Schmidt  ---
Yes, mine.

[Bug middle-end/28859] GCC calls malloc from within signal context

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-17
 Ever confirmed|0   |1

--- Comment #5 from Martin Liška  ---
Do I understand it that practically impossible to handle that as we would have
to somehow detect all malloc-family functions triggered after a crash_signal is
executed?

In case of PR81382 we either need to have layout class not containing of types
that can possibly allocate a memory via malloc, or we can have an env variable
that will prevent displaying of locations if crash_signal happened? Would it be
welcomed one of there approaches?

[Bug middle-end/81441] slowdown due to -fpeel-loops and -ftracer added by -fprofile-use

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #2 from Joost VandeVondele  
---
No, this is profile-use after a profile-generate, so standard PGO setup. The
profile-generate is using the same benchmark for generation, so coverage should
be good.

[Bug tree-optimization/81162] [8 Regression] UBSAN switch triggers incorrect optimization in SLSR

[wschmidt at gcc dot gnu.org]

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

--- Comment #12 from Bill Schmidt  ---
Right, sorry about the ubsan dependency screwup.  I'll move the test case later
today.

[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[kumba at gentoo dot org]

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

--- Comment #2 from Joshua Kinard  ---
(In reply to Richard Biener from comment #1)
> What file is it compiling?

As far as I can tell, it looks somewhat random.  I initially thought that
'build/genrecog.o' was a single file, but after several re-runs, I noticed
there's several files getting compiled that must get merged into genrecog.o.  I
was running a parallel build, too, though (only -j3, 2x SMP machine), so I
could have been seeing the other parallel thread(s) running.  I've restarted
the builod where it stopped using -j1.  It takes about an hour to get back to
where it will stop.  I'll report what that file is, and then launch it again
and see if it stays consistent.

[Bug tree-optimization/81162] [8 Regression] UBSAN switch triggers incorrect optimization in SLSR

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Mon, 17 Jul 2017, bernd.edlinger at hotmail dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81162
> 
> Bernd Edlinger  changed:
> 
>What|Removed |Added
> 
>  CC||bernd.edlinger at hotmail 
> dot de
> 
> --- Comment #10 from Bernd Edlinger  ---
> The test case don't run if gcc-4.6 is host compiler,
> this means it links against the host compiler libubsan.so.0
> which is not really the correct thing to do:
> 
> Setting LD_LIBRARY_PATH to
> :/home/ed/gnu/gcc-build/gcc:/home/ed/gnu/gcc-build/gcc/32:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/./libatomic/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/./libcilkrts/.libs::/home/ed/gnu/gcc-build/gcc:/home/ed/gnu/gcc-build/gcc/32:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/./libatomic/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/./libcilkrts/.libs:/home/ed/gnu/gcc-build/./gmp/.libs:/home/ed/gnu/gcc-build/./prev-gmp/.libs:/home/ed/gnu/gcc-build/./mpfr/src/.libs:/home/ed/gnu/gcc-build/./prev-mpfr/src/.libs:/home/ed/gnu/gcc-build/./mpc/src/.libs:/home/ed/gnu/gcc-build/./prev-mpc/src/.libs:/home/ed/gnu/gcc-build/./isl/.libs:/home/ed/gnu/gcc-build/./prev-isl/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libsanitizer/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libmpx/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libvtv/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libcilkrts/.libs:/home/ed/gnu/gcc

-build/x86_64-pc-linux-gnu/libssp/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libgomp/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libitm/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libatomic/.libs:/home/ed/gnu/gcc-build/./gcc:/home/ed/gnu/gcc-build/./prev-gcc:/home/ed/gnu/gcc-build/./gmp/.libs:/home/ed/gnu/gcc-build/./prev-gmp/.libs:/home/ed/gnu/gcc-build/./mpfr/src/.libs:/home/ed/gnu/gcc-build/./prev-mpfr/src/.libs:/home/ed/gnu/gcc-build/./mpc/src/.libs:/home/ed/gnu/gcc-build/./prev-mpc/src/.libs:/home/ed/gnu/gcc-build/./isl/.libs:/home/ed/gnu/gcc-build/./prev-isl/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libsanitizer/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libmpx/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libvtv/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libcilkrts/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libssp/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libgo

mp/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libitm/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libatomic/.libs:/home/ed/gnu/gcc-build/./gcc:/home/ed/gnu/gcc-build/./prev-gcc
> spawn [open ...]^M
> ./pr81162.exe: error while loading shared libraries: libubsan.so.0: cannot 
> open
> shared object file: No such file or directory
> FAIL: gcc.dg/pr81162.c execution test

You need to move it to ubsan/

[Bug tree-optimization/81418] [8 Regression] ICE in vect_get_vec_def_for_stmt_copy

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Hrm.  So whenever a reducing pattern is exercised in the reduction "chain" we
cannot handle regular uses of the PHI as we basically have to force a
single_defuse_cycle.

So we can't vectorize this case but we fail to reject it.

[Bug rtl-optimization/81423] [6/7/8 Regression] Wrong code at -O2

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Segher Boessenkool from comment #5)
> There are a few issues here.
> 
> 1) I cannot reproduce it: a trunk x86_64-linux compiler stores to
> memory in that insn 20 (the testcase from comment 3).

Just re-checked with todays SVN. There are two (insn 20) RTXes; one in the
function itself, the second one (the problematic one) in the inlined copy in
the main function.

[Bug target/81426] [SH]: unable to find a register to spill in class 'R0_REGS' when building webkit2gtk

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #4)
> 
> It helps, indeed. The build now passes the problematic source code file.
> However, it now bails out later with:
> 
> /tmp/cck5XKuE.s: Assembler messages:
> /tmp/cck5XKuE.s:3780: Error: syntax error in @(disp,[Rn, gbr, pc])
> /tmp/cck5XKuE.s:3780: Error: invalid operands for opcode
> /tmp/cck5XKuE.s:3787: Error: syntax error in @(disp,[Rn, gbr, pc])
> /tmp/cck5XKuE.s:3787: Error: invalid operands for opcode
> Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/build.make:18583: recipe
> for target
> 'Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/runtime/MapPrototype.
> cpp.o' fai
> led
> make[3]: ***
> [Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/runtime/MapPrototype.
> cpp.o] Error 1
> make[3]: *** Waiting for unfinished jobs...
> 
> 

This sounds like a different issue.  Can you please create another PR for that
with the title "syntax error in @(disp,[Rn, gbr, pc]) when compiling with
-mlra" and attach the reproducer?

[Bug c++/81347] g++ confused by namespaces and friend classes

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
I would guess that the instantiation of A::tree injects the type map into the
enclosing namespace, and then the using-declaration finds two declarations and
thinks it's an error.

bug.cc:17:10: error: ‘map’ is already declared in this scope
 using A::map;
  ^~~

[Bug c++/81347] g++ confused by namespaces and friend classes

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|RESOLVED|NEW
   Last reconfirmed||2017-07-17
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
No, this is definitely a GCC bug:

namespace A {

  template 
class tree
{
  template  friend class  map;
};

}

A::tree x;

namespace A {
  template  class  map { };
}

using A::map;

[Bug tree-optimization/81162] [8 Regression] UBSAN switch triggers incorrect optimization in SLSR

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #10 from Bernd Edlinger  ---
The test case don't run if gcc-4.6 is host compiler,
this means it links against the host compiler libubsan.so.0
which is not really the correct thing to do:

Setting LD_LIBRARY_PATH to
:/home/ed/gnu/gcc-build/gcc:/home/ed/gnu/gcc-build/gcc/32:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/./libatomic/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/./libcilkrts/.libs::/home/ed/gnu/gcc-build/gcc:/home/ed/gnu/gcc-build/gcc/32:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/./libatomic/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/./libcilkrts/.libs:/home/ed/gnu/gcc-build/./gmp/.libs:/home/ed/gnu/gcc-build/./prev-gmp/.libs:/home/ed/gnu/gcc-build/./mpfr/src/.libs:/home/ed/gnu/gcc-build/./prev-mpfr/src/.libs:/home/ed/gnu/gcc-build/./mpc/src/.libs:/home/ed/gnu/gcc-build/./prev-mpc/src/.libs:/home/ed/gnu/gcc-build/./isl/.libs:/home/ed/gnu/gcc-build/./prev-isl/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libsanitizer/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libmpx/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libvtv/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libcilkrts/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libssp/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libgomp/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libitm/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libatomic/.libs:/home/ed/gnu/gcc-build/./gcc:/home/ed/gnu/gcc-build/./prev-gcc:/home/ed/gnu/gcc-build/./gmp/.libs:/home/ed/gnu/gcc-build/./prev-gmp/.libs:/home/ed/gnu/gcc-build/./mpfr/src/.libs:/home/ed/gnu/gcc-build/./prev-mpfr/src/.libs:/home/ed/gnu/gcc-build/./mpc/src/.libs:/home/ed/gnu/gcc-build/./prev-mpc/src/.libs:/home/ed/gnu/gcc-build/./isl/.libs:/home/ed/gnu/gcc-build/./prev-isl/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libsanitizer/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libmpx/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libvtv/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libcilkrts/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libssp/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libgomp/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libitm/.libs:/home/ed/gnu/gcc-build/x86_64-pc-linux-gnu/libatomic/.libs:/home/ed/gnu/gcc-build/./gcc:/home/ed/gnu/gcc-build/./prev-gcc
spawn [open ...]^M
./pr81162.exe: error while loading shared libraries: libubsan.so.0: cannot open
shared object file: No such file or directory
FAIL: gcc.dg/pr81162.c execution test

[Bug sanitizer/81302] [7/8 Regression] Segmentation fault in diagnose_tm_1 at trans-mem.c

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Mon Jul 17 11:44:54 2017
New Revision: 250271

URL: https://gcc.gnu.org/viewcvs?rev=250271=gcc=rev
Log:
Do not allow -fgnu-tm w/ -fsanitize={kernel-,}address (PR sanitizer/81302).

2017-07-17  Martin Liska  

PR sanitizer/81302
* opts.c (finish_options): Do not allow -fgnu-tm
w/ -fsanitize={kernel-,}address.  Say sorry.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/opts.c

[Bug tree-optimization/81388] [7/8 Regression] Incorrect code generation with -O1

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |amker at gcc dot gnu.org

--- Comment #7 from amker at gcc dot gnu.org ---
Thanks for reporting, I will investigate this.

[Bug tree-optimization/81369] [8 Regression] ICE in generate_code_for_partition

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Author: amker
Date: Mon Jul 17 11:40:54 2017
New Revision: 250270

URL: https://gcc.gnu.org/viewcvs?rev=250270=gcc=rev
Log:
PR target/81369
* tree-loop-distribution.c (classify_partition): Only assert on
numer of iterations.
(merge_dep_scc_partitions): Delete prameter.  Update function call.
(distribute_loop): Remove code handling loop with unknown niters.
(pass_loop_distribution::execute): Skip loop with unknown niters.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-loop-distribution.c

[Bug other/81458] Misdetection of gcc_cv_as_cfi_advance_working

[joerg at netbsd dot org]

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

--- Comment #2 from Joerg Sonnenberger  ---
More testing seems to point to binutils 2.28 as fixing objcopy. It is still not
clear whether there is any reason to preferring it though, especially as many
systems ship older versions.

[Bug tree-optimization/81369] [8 Regression] ICE in generate_code_for_partition

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
Author: amker
Date: Mon Jul 17 11:38:15 2017
New Revision: 250269

URL: https://gcc.gnu.org/viewcvs?rev=250269=gcc=rev
Log:
PR target/81369
* tree-loop-distribution.c (merge_dep_scc_partitions): Sink call to
function sort_partitions_by_post_order.

gcc/testsuite
* gcc.dg/tree-ssa/pr81369.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81369.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-loop-distribution.c

[Bug middle-end/81464] [8 Regression] ICE in expand_omp_for_static_chunk, at omp-expand.c:4236

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|7.0 |8.0
   Target Milestone|--- |8.0

[Bug tree-optimization/81462] [8 Regression] ICE in estimate_bb_frequencies at gcc/predict.c:3546

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
Version|7.0 |8.0
   Target Milestone|--- |8.0

[Bug tree-optimization/81463] [8 Regression] ICE in scale_loop_profile at gcc/cfgloopmanip.c:603

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
Version|7.0 |8.0
   Target Milestone|--- |8.0

[Bug tree-optimization/81461] Optimization for removing same variable comparisons in loop: while(it != end1 && it != end2)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||law at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
jump threading

[Bug sanitizer/81460] [8 Regression] ICE in force_constant_size, at gimplify.c:684

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|7.0 |8.0
   Target Milestone|--- |8.0

[Bug middle-end/81457] Inconsistent section flags for section attribute

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Please post the patch to gcc-patches

[Bug tree-optimization/81374] [8 Regression] ICE in bb_top_order_cmp, at tree-loop-distribution.c:391

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
Author: amker
Date: Mon Jul 17 11:34:30 2017
New Revision: 250268

URL: https://gcc.gnu.org/viewcvs?rev=250268=gcc=rev
Log:
PR tree-optimization/81374
* tree-loop-distribution.c (pass_loop_distribution::execute): Record
the max index of basic blocks, rather than number of basic blocks.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-loop-distribution.c

[Bug target/81456] [7/8 Regression] x86-64 optimizer makes wrong decision when optimizing for size

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |7.2

[Bug tree-optimization/81450] Typedef with assume aligned builtin yields segmentation fault in nested loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
>  typedef double __attribute__((aligned (32))) AlignedDouble;
>  AlignedDouble* A = aligned_doubles( size * size );
>  A[j + i * size] += alpha;

here you say that [j+i*size] is aligned to 32 bytes because you dereference
A + j + i*size which is still of type AlignedDouble.

Maybe surprising but this it is.

[Bug target/81426] [SH]: unable to find a register to spill in class 'R0_REGS' when building webkit2gtk

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #4 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #3)
> Please try.  It might allow you to at least build the package.  Regardless
> of that, let's keep this PR open.

It helps, indeed. The build now passes the problematic source code file.
However, it now bails out later with:

/tmp/cck5XKuE.s: Assembler messages:
/tmp/cck5XKuE.s:3780: Error: syntax error in @(disp,[Rn, gbr, pc])
/tmp/cck5XKuE.s:3780: Error: invalid operands for opcode
/tmp/cck5XKuE.s:3787: Error: syntax error in @(disp,[Rn, gbr, pc])
/tmp/cck5XKuE.s:3787: Error: invalid operands for opcode
Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/build.make:18583: recipe
for target
'Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/runtime/MapPrototype.cpp.o'
fai
led
make[3]: ***
[Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/runtime/MapPrototype.cpp.o]
Error 1
make[3]: *** Waiting for unfinished jobs...

Full log in [1].

> [1] https://people.debian.org/~glaubitz/webkit2gtk_2.16.5-1-mlra_sh4.build

[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||mips
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-17
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
What file is it compiling?

[Bug middle-end/81441] slowdown due to -fpeel-loops and -ftracer added by -fprofile-use

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*
 CC||hubicka at gcc dot gnu.org
Version|5.4.0   |7.1.0

--- Comment #1 from Richard Biener  ---
So this is -fprofile-use without previously profiling with -fprofile-generate? 
Esp. -ftracer depends on a usable profile to not go off limits.

[Bug middle-end/81030] [8 Regression] ICE on valid code at -O1 (only) on x86_64-linux-gnu: verify_flow_info failed

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #9 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00963.html

[Bug rtl-optimization/81423] [6/7/8 Regression] Wrong code at -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/81418] [8 Regression] ICE in vect_get_vec_def_for_stmt_copy

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.0

--- Comment #2 from Richard Biener  ---
Mine.

[Bug c++/81410] [5/6/7/8 Regression] -O3 breaks code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P2
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |5.5

--- Comment #6 from Richard Biener  ---
I'll have a looksee.

[Bug gcov-profile/81442] error: verify_flow_info: REG_BR_PROB is set but cfg probability is not during RTL pass: outof_cfglayout

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openacc
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-17
 CC||tschwinge at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Thomas Schwinge  ---
Per my testing, this starts with r249888, "Enable checking of
profile_probability consistency".

Specifically, the ICE is seen for "-O2" testing of both
"libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-5.c" and
"libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-5.c".  (Likely) the
same ICE is also seen for "-O2" and "-O3" testing of
"libgomp.oacc-fortran/reduction-6.f90".  Tom's patch does cure these
regressions.

[Bug middle-end/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
  Component|c++ |middle-end

--- Comment #9 from Richard Biener  ---
Note that -Wunsafe-loop-optimizations is enabled at any -W level.  But yes, I
agree it should be -fopt-info stuff.

[Bug lto/81406] [6/7/8 Regression] ICE in check_die, at dwarf2out.c:6185

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |6.5

[Bug tree-optimization/81403] [8 Regression] wrong code at -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.0

--- Comment #4 from Richard Biener  ---
Mine :/