[Bug target/82139] New: unnecessary movapd with _mm_castsi128_pd to use BLENDPD on __m128i results

[peter at cordes dot ca]

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

Bug ID: 82139
   Summary: unnecessary movapd with _mm_castsi128_pd to use
BLENDPD on __m128i results
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

#include 
#include 
// stripped down from a real function that did something more useful
void foo(uint64_t blocks[]) {
for (int i = 0 ; i<10240 ; i+=2) {
__m128i v = _mm_loadu_si128((__m128i*)[i]);
__m128i t1 = _mm_add_epi32(v, _mm_set1_epi32(1));
__m128i t2 = _mm_add_epi32(v, _mm_set1_epi32(-1));
__m128d blend = _mm_blend_pd(_mm_castsi128_pd(t1),
 _mm_castsi128_pd(t2), 2);
  // is this even aliasing-safe?  Could cast back to __m128i
_mm_storeu_pd((double*)(__m128d*)[i], blend);
}
}

https://godbolt.org/g/im1kcc for source and gcc-trunk asm output (and the
slightly larger version of this function that I simplified).

blendpd/blendps have better throughput than pblendw on Intel CPUs, so I played
with that in this function I was looking at.

gcc4.8 and later waste a MOVAPD for no reason instead of clobbering one of the
PADDD results with the blend.  (The larger version of this function,
pairs_u64_sse2 in the godbolt link, avoids the extra MOVAPD with gcc4.9.4 and
earlier, but not in foo().  So maybe it's just by chance, or maybe 4.8 changed
something.  Anyway, still present in 7.2 and 8.0-trunk, and with -O2 or -O3

(GCC-Explorer-Build) 8.0.0 20170907 -xc -std=gnu99 -O3 -Wall -msse4 -mno-avx

foo:
pcmpeqd %xmm2, %xmm2
leaq81920(%rdi), %rax
movdqa  .LC0(%rip), %xmm3
.L6:
movdqa  %xmm3, %xmm1
addq$16, %rdi
movdqu  -16(%rdi), %xmm0
paddd   %xmm0, %xmm1
movapd  %xmm1, %xmm4
paddd   %xmm2, %xmm0
blendpd $2, %xmm0, %xmm4
movups  %xmm4, -16(%rdi)
cmpq%rdi, %rax
jne .L6
rep ret

Notice that BLENDPD's operands aren't the two output registers from the PADDD
instructions.  Different versions/options (like -mtune=skylake) put the extra
MOVAPD between the PADDD instructions, or right before BLENDPD, so don't let it
fool you. :P

With the function even simpler (like only one _mm_add_epi32), blending between
the original load result and the add result didn't appear to have an extra
MOVAPD

[Bug target/82138] [8 Regression] Assembler messages: Error: can't resolve `.got2' {.got2 section} - `.LCF0' {.text.unlikely section}

[asolokha at gmx dot com]

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

--- Comment #1 from Arseny Solokha  ---
This was fixed in r251843 for rs6000.

[Bug target/82138] New: [8 Regression] Assembler messages: Error: can't resolve `.got2' {.got2 section} - `.LCF0' {.text.unlikely section}

[asolokha at gmx dot com]

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

Bug ID: 82138
   Summary: [8 Regression] Assembler messages: Error: can't
resolve `.got2' {.got2 section} - `.LCF0'
{.text.unlikely section}
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: assemble-failure
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: andrewjenner at gcc dot gnu.org, charlet at gcc dot gnu.org,
unassigned at gcc dot gnu.org
  Target Milestone: ---
Target: powerpcspe-*-linux-gnu*

+++ This bug was initially created as a clone of Bug #81979 +++

gas 2.28.1 rejects the code generated by gcc-8.0.0-alpha20170820 snapshot
(r251211) w/ -fPIC -O2 -freorder-blocks-and-partition for the following
snippet:

int du;

void
xf (int ee)
{
  int cq;

  while (cq < 1)
{
  int ox;

  for (ox = 0; ox < 4; ++ox)
cq /= (ee != 0) ? 2 : ee;
}

  du = 1;
  for (;;)
{
}
}

% powerpc-e500v2-linux-gnuspe-gcc-8.0.0-alpha20170820 -fPIC -O2
-freorder-blocks-and-partition -c v8qdkqlm.c
/tmp/cchaREkd.s: Assembler messages:
/tmp/cchaREkd.s:15: Error: can't resolve `.got2' {.got2 section} - `.LCF0'
{.text.unlikely section}

[Bug target/82136] x86: -mavx256-split-unaligned-load should try to fold other shuffles into the load/vinsertf128

[peter at cordes dot ca]

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

--- Comment #1 from Peter Cordes  ---
Whoops, the compiler-explorer link had aligned=1.  This one produces the asm I
showed in the original report: https://godbolt.org/g/WsZ5S9

See bug 82137 for a much more efficient vectorization strategy gcc should use
instead, with just in-lane shuffle + blend and some duplicated work.

[Bug tree-optimization/82137] New: auto-vectorizing shuffles way to much to avoid duplicate work

[peter at cordes dot ca]

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

Bug ID: 82137
   Summary: auto-vectorizing shuffles way to much to avoid
duplicate work
   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: peter at cordes dot ca
  Target Milestone: ---

(same code as bug 82136, but with aligned pointers, and discussing the overall
vectorization strategy)

static const int aligned = 1;

void pairs_double(double blocks[]) {
if(aligned) blocks = __builtin_assume_aligned(blocks, 64);
for (int i = 0 ; i<10240 ; i+=2) {
double x = blocks[i];
double y = blocks[i+1];
blocks[i] = x*y;
blocks[i+1] = x+y;
}
}

https://godbolt.org/g/pTY5iU has this + a uint64_t version (with ^ and &)

i.e. load a pair of 64-bit elements and replace them with 2 different
combinations of the pair.  See
https://stackoverflow.com/questions/46038401/unpack-m128i-m256i-to-m64-mmx-sse2-avx2.

gcc auto-vectorizes this *way* too much shuffling when AVX / AVX2 are
available, same for the integer version.  It's especially bad with AVX1 only,
but even AVX2 is a mess and will totally bottleneck on shuffle throughput on
Intel and AMD CPUs (Ryzen has good shuffle throughput, but lane-crossing
shuffles are much more expensive than in-lane).

gcc 8.0.8 -O3 -march=haswell

pairs_double:
leaq81920(%rdi), %rax
.L2:
vmovapd (%rdi), %ymm1
vmovapd 32(%rdi), %ymm0
addq$64, %rdi
vunpcklpd   %ymm0, %ymm1, %ymm2
vunpckhpd   %ymm0, %ymm1, %ymm0
vpermpd $216, %ymm2, %ymm2
vpermpd $216, %ymm0, %ymm0
vmulpd  %ymm2, %ymm0, %ymm1
vaddpd  %ymm2, %ymm0, %ymm0
vpermpd $68, %ymm0, %ymm3
vpermpd $238, %ymm0, %ymm0
vpermpd $68, %ymm1, %ymm2
vpermpd $238, %ymm1, %ymm1
vshufpd $12, %ymm3, %ymm2, %ymm2
vshufpd $12, %ymm0, %ymm1, %ymm0
vmovapd %ymm2, -64(%rdi)
vmovapd %ymm0, -32(%rdi)
cmpq%rdi, %rax
jne .L2
vzeroupper
ret

I haven't worked through the constants to see how its shuffling, but the same
function with uint64_t (and operators ^ &) uses 4 shuffles per 2 vectors after
the actual work:

# vpand / vpxor in ymm0 / ymm1
vpunpcklqdq %ymm0, %ymm1, %ymm2
vpunpckhqdq %ymm0, %ymm1, %ymm0
vperm2i128  $32, %ymm0, %ymm2, %ymm1
vperm2i128  $49, %ymm0, %ymm2, %ymm0
vmovdqa %ymm1, -64(%rdi)
vmovdqa %ymm0, -32(%rdi)

It uses equivalent shuffles to prepare for vpand/vpxor, so vunpckl/hpd + 2x
vperm2f128 should do the same shuffle.  Using split stores would help a lot on
Intel and AMD: 2x vmovdqa xmm, then 2x vextractf128 xmm.  SnB/HSW/SKL
vextractf128 to memory is 2 fused-domain uops (Agner Fog's table) but there's
no ALU uop.  It's just a non-micro-fused store.  Since gcc's code horribly
bottlenecks on shuffles, split stores would be a win here.

It's a huge win on Ryzen, where vperm2f128 is 8 uops with 3c throughput. 
(-march=ryzen enables -mprefer-avx128, but -march=haswell running on Ryzen is
probably a relevant use-case.  When all else is equal for Intel, do something
that doesn't suck on Ryzen.)



However, a different strategy entirely is *MUCH* better for most CPUs, and as a
bonus it only needs AVX1 and no lane-crossing shuffles:

Do far less shuffling in exchange for doing more mul/add (or whatever), by
allowing duplicates.  Doing the same operation twice is allowed, even when it
can raise FP exceptions (in C and C++).

b0 b1   |b2   b3   # load 256b
b1 b0   |b3   b2   # vshufpd or vpermilpd for in-lane
swap

b0*b1  b1*b0|b2*b3b3*b2# vmulpd
b0+b1  b1+b0|b2+b3b3+b2# vaddpd

b0*b1  b0+b1|b2*b3b2+b3# vblendpd
   # store 256b

Per two 128b pairs, that's 1 load, 1 shuffle, 2x FP math, 1 immediate-blend, 1
store.  No lane-crossing shuffles is a huge plus for Ryzen (vperm2f128 is very
slow).

That's 6 fused-domain uops on Intel, and should easily run at 1 iter per 1.5
cycles (+ loop overhead), without bottlenecking on any ports.  The bottleneck
is the front-end, so unrolling helps.

That's 0.75c per 128b pair.  (Slower on SnB/IvB, bottlenecking on load/store
throughput.)

Immediate-blend can run on any port on HSW+, or p0/p5 on SnB (and good
throughput on BD/Ryzen) so it's much more throughput-friendly than using
vunpcklpd to mix the mul and add result vectors.  If the operation hadn't been
commutative (e.g. sub instead of add), you might have to use vpunpck.

This same strategy is also optimal for integer booleans with AVX2.  (Or
possibly even with AVX1, but using VXORPS / 

[Bug target/82136] New: x86: -mavx256-split-unaligned-load should try to fold other shuffles into the load/vinsertf128

[peter at cordes dot ca]

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

Bug ID: 82136
   Summary: x86: -mavx256-split-unaligned-load should try to fold
other shuffles into the load/vinsertf128
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

static const int aligned = 0;

void pairs_double(double blocks[]) {
if(aligned) blocks = __builtin_assume_aligned(blocks, 64);
for (int i = 0 ; i<10240 ; i+=2) {
double x = blocks[i];
double y = blocks[i+1];
blocks[i] = x*y;
blocks[i+1] = x+y;
}
}

i.e. load a pair of 64-bit elements and replace them with 2 different
combinations of the pair.

https://godbolt.org/g/Y9eJF3  (also includes a uint64_t version that shuffles
similarly with AVX2).  See
https://stackoverflow.com/questions/46038401/unpack-m128i-m256i-to-m64-mmx-sse2-avx2
for the original integer question.


GCC autovectorizes this poorly with AVX, and *very* poorly in the unaligned
case with split loads/stores.  It's doing two movupd/vinsertf128 pairs to
emulate a ymm load, and then shuffling with vinsertf128 / vperm2f128.  Using
split loads from non-contiguous addresses would definitely allow dropping at
least one shuffle.

with gcc 8.0.0 20170907  -xc -std=gnu11 -O3 -Wall -march=sandybridge

pairs_double:
leaq81920(%rdi), %rax
.L2:
vmovupd (%rdi), %xmm1
vinsertf128 $0x1, 16(%rdi), %ymm1, %ymm1
addq$64, %rdi
vmovupd -32(%rdi), %xmm2
vinsertf128 $0x1, -16(%rdi), %ymm2, %ymm2
vinsertf128 $1, %xmm2, %ymm1, %ymm0
vperm2f128  $49, %ymm2, %ymm1, %ymm1
vunpcklpd   %ymm1, %ymm0, %ymm2
vunpckhpd   %ymm1, %ymm0, %ymm0
vmulpd  %ymm2, %ymm0, %ymm1
vaddpd  %ymm2, %ymm0, %ymm0
vinsertf128 $1, %xmm1, %ymm1, %ymm2
vperm2f128  $49, %ymm1, %ymm1, %ymm1
vinsertf128 $1, %xmm0, %ymm0, %ymm3
vperm2f128  $49, %ymm0, %ymm0, %ymm0
vshufpd $12, %ymm3, %ymm2, %ymm2
vshufpd $12, %ymm0, %ymm1, %ymm0
vmovups %xmm2, -64(%rdi)
vextractf128$0x1, %ymm2, -48(%rdi)
vextractf128$0x1, %ymm0, -16(%rdi)
vmovups %xmm0, -32(%rdi)
cmpq%rdi, %rax
jne .L2
vzeroupper
ret


This is obviously pretty horrible, with far too much shuffling just to set up
for a mul and add.  Things are not bad with -mprefer-avx128 and aligned
pointers (4x vunpckl/h per 2 vectors), which should be good on Ryzen or
SnB-family, but maybe not faster than scalar on Haswell with limited shuffle
throughput.  (Same for the uint64_t version of the same thing.)

[Bug target/80568] x86 -mavx256-split-unaligned-load (and store) is affecting AVX2 code, but probably shouldn't be.

[peter at cordes dot ca]

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

Peter Cordes  changed:

   What|Removed |Added

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

--- Comment #3 from Peter Cordes  ---
Bug 78762 is asking for the same thing: disable at least load-splitting in
-mtune=generic when -mavx2 is enabled.

Or more generally, ISA-aware tune=generic.

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

[Bug target/78762] Regression: Splitting unaligned AVX loads also when AVX2 is enabled

[peter at cordes dot ca]

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

Peter Cordes  changed:

   What|Removed |Added

 CC||peter at cordes dot ca

--- Comment #16 from Peter Cordes  ---
*** Bug 80568 has been marked as a duplicate of this bug. ***

[Bug c++/82067] G++ has an internal compiler error in possible_polymorphic_call_targets, at ipa-devirt.c:1557

[jupitercuso4 at gmail dot com]

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

--- Comment #7 from jupitercuso4 at gmail dot com ---
$ g++ -std=c++11 -O3 --verbose test.i
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/project/usr-tensilica-RHEL5/stools-8.0-2017-06-05/bin/../libexec/gcc/x86_64-pc-linux-gnu/4.9.4/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-4.9.4/configure --with-checking=release
--build=x86_64-pc-linux-gnu --prefix=/usr/xtensa/stools-8.0-2017-06-05
LD_OPTIONS=-R/usr/xtensa/stools-8.0-2017-06-05/lib
--with-gmp=/usr/xtensa/stools-8.0-2017-06-05
--with-mpfr=/usr/xtensa/stools-8.0-2017-06-05 --enable-languages=c,c++
--disable-libgcj
Thread model: posix
gcc version 4.9.4 (GCC)
COLLECT_GCC_OPTIONS='-std=c++11' '-O3' '-v' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'

/project/usr-tensilica-RHEL5/stools-8.0-2017-06-05/bin/../libexec/gcc/x86_64-pc-linux-gnu/4.9.4/cc1plus
-fpreprocessed test.i -quiet -dumpbase test.i -mtune=generic -march=x86-64
-auxbase test -O3 -std=c++11 -version -o /tmp/cc6LMkmh.s
GNU C++ (GCC) version 4.9.4 (x86_64-pc-linux-gnu)
compiled by GNU C version 4.9.4, GMP version 6.1.2, MPFR version 3.1.5,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.9.4 (x86_64-pc-linux-gnu)
compiled by GNU C version 4.9.4, GMP version 6.1.2, MPFR version 3.1.5,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e4a50cb5767031363285860fcbf01e45
test.cpp: In constructor
'xtsc_component::xtsc_queue_pin::xtsc_queue_pin(sc_core::sc_module_name, const
xtsc_component::xtsc_queue_pin_parms&)':
test.cpp:32:1: internal compiler error: in possible_polymorphic_call_targets,
at ipa-devirt.c:1557
 xtsc_component::xtsc_queue_pin::xtsc_queue_pin(sc_module_name module_name,
const xtsc_queue_pin_parms& queue_parms) :
 ^
0x6828cb possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, int*)
../../gcc-4.9.4/gcc/ipa-devirt.c:1557
0x665cea possible_polymorphic_call_targets(tree_node*, bool*, void**)
../../gcc-4.9.4/gcc/ipa-utils.h:142
0xc87198 gimple_fold_call
../../gcc-4.9.4/gcc/gimple-fold.c:1127
0xc87198 fold_stmt_1
../../gcc-4.9.4/gcc/gimple-fold.c:1302
0xd909b8 fold_marked_statements
../../gcc-4.9.4/gcc/tree-inline.c:4549
0xd8c2e0 optimize_inline_calls(tree_node*)
../../gcc-4.9.4/gcc/tree-inline.c:4630
0xf48b89 inline_transform(cgraph_node*)
../../gcc-4.9.4/gcc/ipa-inline-transform.c:457
0xd1b58a execute_one_ipa_transform_pass
../../gcc-4.9.4/gcc/passes.c:2066
0xd1b58a execute_all_ipa_transforms()
../../gcc-4.9.4/gcc/passes.c:2107
0xbd8abd expand_function
../../gcc-4.9.4/gcc/cgraphunit.c:1775
0xf99653 expand_all_functions
../../gcc-4.9.4/gcc/cgraphunit.c:1916
0xf99653 compile()
../../gcc-4.9.4/gcc/cgraphunit.c:2260
0xf98f17 finalize_compilation_unit()
../../gcc-4.9.4/gcc/cgraphunit.c:2337
0xb149dd cp_write_global_declarations()
../../gcc-4.9.4/gcc/cp/decl2.c:4647
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[daniel.black at au dot ibm.com]

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

--- Comment #27 from Daniel Black  ---
reduced test case, quite similar however just to be sure:

int a, b;
__attribute__((__cold__)) fn1();
__attribute__((always_inline)) fn2() { fn1(); }
fn3() {
  fn2();
  if (b)
a = 0;
}

[Bug middle-end/81768] [8 Regression] error: control flow in the middle of basic block

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep  7 20:41:42 2017
New Revision: 251857

URL: https://gcc.gnu.org/viewcvs?rev=251857=gcc=rev
Log:
Backported from mainline
2017-09-05  Jakub Jelinek  

PR middle-end/81768
* omp-low.c (lower_omp_for): Recompute tree invariant if
gimple_omp_for_initial/final is ADDR_EXPR.

* gcc.dg/gomp/pr81768-2.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/gomp/pr81768-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/omp-low.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug middle-end/81768] [8 Regression] error: control flow in the middle of basic block

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep  7 20:40:06 2017
New Revision: 251856

URL: https://gcc.gnu.org/viewcvs?rev=251856=gcc=rev
Log:
Backported from mainline
2017-09-05  Jakub Jelinek  

PR middle-end/81768
* omp-expand.c (expand_omp_simd): Force second operands of COND_EXPR
into gimple val before gimplification fo the COND_EXPR.

* gcc.dg/gomp/pr81768-1.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/gomp/pr81768-1.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/omp-expand.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/82135] Missed constant propagation through possible unsigned wraparound, with std::align() variable pointer, constant everything else.

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
This PR is a bit messy, please minimize your examples...
Looking at the dse2 dump (before reassoc messes things up):

  __intptr_2 = (const long unsigned int) voidp_9(D);
  _3 = __intptr_2 + 63;
  __aligned_4 = _3 & 18446744073709551552;
  __diff_5 = __aligned_4 - __intptr_2;
  _6 = __diff_5 + 64;
  if (_6 > 1024)

IIUC, essentially, you would like gcc to realize that __diff_5 is in [0,63], so
the condition is always false.

If aligned was not reused, we could simplify ((x+63)&-64)-x to 63&-x, but we
don't want to do it in general. Maybe we could add a very special case in VRP
(or CCP for nonzero bits)...
(we could also add if(__diff>__align)__builtin__unreachable() in  but
that's getting really specific)

[Bug sanitizer/81923] [ASAN] gcc emites wrong odr asan instrumentation for glibc

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep  7 20:29:04 2017
New Revision: 251854

URL: https://gcc.gnu.org/viewcvs?rev=251854=gcc=rev
Log:
Backported from mainline
2017-09-01  Jakub Jelinek  

PR sanitizer/81923
* asan.c (create_odr_indicator): Strip name encoding from assembler
name before appending it after __odr_asan_.

* gcc.dg/asan/pr81923.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/asan/pr81923.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/asan.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c/81687] Compiler drops label in OpenMP region

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep  7 20:26:34 2017
New Revision: 251853

URL: https://gcc.gnu.org/viewcvs?rev=251853=gcc=rev
Log:
2017-09-07  Jakub Jelinek  

Backported from mainline
2017-08-09  Jakub Jelinek  

PR c/81687
* omp-low.c (omp_copy_decl): Don't remap FORCED_LABEL or DECL_NONLOCAL
LABEL_DECLs.
* tree-cfg.c (move_stmt_op): Don't adjust DECL_CONTEXT of FORCED_LABEL
or DECL_NONLOCAL labels.
(move_stmt_r) : Adjust DECL_CONTEXT of FORCED_LABEL
or DECL_NONLOCAL labels here.

* testsuite/libgomp.c/pr81687-1.c: New test.
* testsuite/libgomp.c/pr81687-2.c: New test.

Added:
branches/gcc-7-branch/libgomp/testsuite/libgomp.c/pr81687-1.c
branches/gcc-7-branch/libgomp/testsuite/libgomp.c/pr81687-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/omp-low.c
branches/gcc-7-branch/gcc/tree-cfg.c
branches/gcc-7-branch/libgomp/ChangeLog

[Bug target/81621] ICE in delete_insn, at cfgrtl.c:167 with s390x cross compiler

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep  7 20:23:14 2017
New Revision: 251851

URL: https://gcc.gnu.org/viewcvs?rev=251851=gcc=rev
Log:
Backported from mainline
2017-08-03  Jakub Jelinek  

PR target/81621
* bb-reorder.c (pass_partition_blocks::execute): Return TODO_df_finish
after setting changeable df flags.

* gcc.dg/pr81621.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr81621.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/bb-reorder.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug driver/81650] gcc -m32 mishandles -Walloc-size-larger-than=9223372036854775807

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep  7 20:20:43 2017
New Revision: 251850

URL: https://gcc.gnu.org/viewcvs?rev=251850=gcc=rev
Log:
Backported from mainline
2017-08-03  Jakub Jelinek  

PR driver/81650
* calls.c (alloc_max_size): Use HOST_WIDE_INT_UC (10??)
instead of 10??LU, perform unit multiplication in wide_int,
don't change alloc_object_size_limit if the limit is larger
than SSIZE_MAX.

* gcc.dg/pr81650.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr81650.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/calls.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug middle-end/81052] ICE in verify_dominators, at dominance.c:1184

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep  7 20:19:47 2017
New Revision: 251849

URL: https://gcc.gnu.org/viewcvs?rev=251849=gcc=rev
Log:
Backported from mainline
2017-08-03  Jakub Jelinek  

PR middle-end/81052
* omp-low.c (diagnose_sb_0): Handle flag_openmp_simd like flag_openmp.
(pass_diagnose_omp_blocks::gate): Enable also for flag_openmp_simd.

* c-c++-common/pr81052.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/c-c++-common/pr81052.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/omp-low.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c/45784] gcc OpenMP - error: invalid controlling predicate

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep  7 20:18:45 2017
New Revision: 251848

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

PR c/45784
* c-omp.c (c_finish_omp_for): If the condition is wrapped in
rhs of COMPOUND_EXPR(s), skip them and readd their lhs into
new COMPOUND_EXPRs around the rhs of the comparison.

* testsuite/libgomp.c/pr45784.c: New test.
* testsuite/libgomp.c++/pr45784.C: New test.

Added:
branches/gcc-7-branch/libgomp/testsuite/libgomp.c++/pr45784.C
branches/gcc-7-branch/libgomp/testsuite/libgomp.c/pr45784.c
Modified:
branches/gcc-7-branch/gcc/c-family/ChangeLog
branches/gcc-7-branch/gcc/c-family/c-omp.c
branches/gcc-7-branch/libgomp/ChangeLog

[Bug c/82133] unroll-loops too aggressive

[nickpapior at gmail dot com]

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

Nick  changed:

   What|Removed |Added

  Known to work||6.3.0

--- Comment #1 from Nick  ---
I completely forgot to say that there were no problems using GCC-6.3.0 compiler
on the Debian stretch box.

[Bug tree-optimization/82135] New: Missed constant propagation through possible unsigned wraparound, with std::align() variable pointer, constant everything else.

[peter at cordes dot ca]

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

Bug ID: 82135
   Summary: Missed constant propagation through possible unsigned
wraparound, with std::align() variable pointer,
constant everything else.
   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: peter at cordes dot ca
  Target Milestone: ---

The code in this report is easiest to look at here:
https://godbolt.org/g/DffP3J, with asm output.

When g++ inlines this (copied version of std::align from include/c++/memory),
it fails to optimize to just rounding up to the next power of 2 when
align=size=64 and space=1024, but ptr is variable.

(If __ptr is also constant, it's fine.)

#include 
#include 
inline void*
libalign(size_t __align, size_t __size, void*& __ptr, size_t& __space) noexcept
{
  const auto __intptr = reinterpret_cast(__ptr);
  const auto __aligned = (__intptr - 1u + __align) & -__align;
//if (__aligned < __size)   __builtin_unreachable();
  const auto __diff = __aligned - __intptr;
//if (__diff > __size)  __builtin_unreachable();
  if ((__size + __diff) > __space)
return (void*)123456; //nullptr;   // non-zero constant is obvious in the
asm
  else
{
  __space -= __diff;
  return __ptr = reinterpret_cast(__aligned);
}
}

void *libalign64(void *voidp) {
std::size_t len = 1024;
 //if (voidp+len < voidp) __builtin_unreachable();   // doesn't
help
voidp = 
  libalign(64, 64, voidp, len);
return voidp;
}

g++ -O3 -std=c++14  -Wall -Wextra  (trunk 8.0.0 20170906)

# x86-64.  Other targets do the same compare/cmov or branch
leaq63(%rdi), %rax
andq$-64, %rax
movq%rax, %rdx
subq%rdi, %rdx
addq$65, %rdx
cmpq$1025, %rdx
movl$123456, %edx
cmovnb  %rdx, %rax
ret


libalign64 gives exactly the same result as just rounding up to the next power
of 2 (including wrapping around to zero with addresses very close to the top). 
But gcc doesn't spot this, I think getting confused about what can happen with
unsigned wraparound.

char *roundup2(char *p) {
auto t = (uintptr_t)p;
t = (t+63) & -64;
return (char*)t;
}

leaq63(%rdi), %rax
andq$-64, %rax
ret

For easy testing, I made wrappers that call with a constant pointer, so I can
test that it really does wrap around at exactly the same place as roundup2(). 
(It does: libalign64(-64) = -64, libalign64(-64) = 0.)  So it can safely be
compiled to 2 instructions on targets where unsigned integer wraparound works
normally, without all that adding constants and comparing against constants.

static char* const test_constant = (char*)-63ULL;

char *test_roundup2() {
return roundup2(test_constant);
}
void *test_libalign() {
return libalign64(test_constant);
}


Uncommenting this line I added:
   if (__diff > __size)  __builtin_unreachable();

lets it compile to just two instructions, but that condition isn't really
always true.  __diff will be huge when __aligned wraps around.

clang, icc, and msvc also fail to make this optimization.  IDK if it's
particularly useful in real life for anything other than abusing std::align as
a simple round-up function.

[Bug target/81800] [8 regression] on aarch64 ilp32 lrint should not be inlined as two instructions

[qing.zhao at oracle dot com]

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

--- Comment #3 from Qing Zhao  ---
I can repeat this with the latest upstream gcc on aarch64 machine.

the inlining happens when -fno-math-errno is specified. 
and it should be only inlined when -fno-trapping-math is specified.

[Bug tree-optimization/80925] [8 Regression] vect peeling failures

[sje at gcc dot gnu.org]

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

--- Comment #22 from Steve Ellcey  ---
(In reply to Christophe Lyon from comment #21)

> I think this change caused regressions on armeb-none-linux-gnueabihf
> --with-cpu=cortex-a9 --with-fpu=neon-fp16 (works OK
> --with-fpu=vfpv3-d16-fp16)

Ranier Orth reported a failure on SPARC64 as well, here was my reply
to him.  I don't know if your problem is the same without seeing the
specific failure.

--

Looking at the checks at the end, I also see that SPARC does include
the 'Alignment' message and Aarch64 does not and that is handled by a
conditional check.

I think the fix is to check for 'vectorized 4 loops' when we support
unaligned vector instructions (vect_hw_misalign is true) and check for
'vectorized 3 loops' otherwise.  Does that sound reasonable to you?

I think the reason this worked before is that that loop got vectorized
due to being peeled and my change turned off the peeling and thus it
could not be vectorized on machines that do not support unaligned
vectorization.

[Bug bootstrap/82087] HEAD fails to bootstrap on x86_64-apple-darwin16.7.0

[d25fe0be at outlook dot com]

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

d25fe0be@  changed:

   What|Removed |Added

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

--- Comment #3 from d25fe0be@  ---
Seems to have been fixed. (Before or at r251800.)

[Bug objc++/61759] [ICE] [objc] reaching gcc_unreachable in objc_eh_runtime_type at objc/objc-next-runtime-abi-01.c

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Target|powerpc-unknown-darwin  |*-*-darwin
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-07
   Host|powerpc-unknown-darwin  |*-*-darwin
 Ever confirmed|0   |1
  Known to fail||8.0
  Build|powerpc-unknown-darwin  |*-*-darwin

--- Comment #8 from Eric Gallager  ---
(In reply to Eric Gallager from comment #7)
> (In reply to Douglas Mencken from comment #6)
> > Looks like I found the root of the issue ~
> > GCC ICEs when it meets C++ exception handling (try+catch)
> > 
> > $ cat main.mm
> > #include 
> > #include 
> > 
> > int main (void)
> > {
> > try {
> > throw 0;
> > } catch (int & e) {
> > std::cout << "caught" << std::endl;
> > }
> > 
> > NSString *name = @"GNUstep !";
> > NSAutoreleasePool *pool;
> > pool = [NSAutoreleasePool new];
> > [pool drain];
> > }
> > 
> > $ g++ main.mm -o test.out -framework Foundation -lobjc
> > main.mm: In function 'int main()':
> > main.mm:4:5: internal compiler error: in objc_eh_runtime_type, at
> > objc/objc-next-runtime-abi-01.c:2804
> >  int main (void)
> >  ^
> > libbacktrace could not find executable to open
> > Please submit a full bug report,
> 
> This is similar to bug 35756 but since you have a different testcase I'll
> leave this open as a separate bug. Anyways, I think I have bad headers on my
> system, because my compiler chokes in that part:
> 
> $ /usr/local/bin/g++ 61759_main.mm -o test.out -framework Foundation -lobjc
> In file included from
> /System/Library/Frameworks/Security.framework/Headers/Security.h:57:0,
>  from
> /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.
> framework/Headers/LSSharedFileList.h:32,
>  from
> /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.
> framework/Headers/LaunchServices.h:37,
>  from
> /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:41,
>  from
> /System/Library/Frameworks/ApplicationServices.framework/Headers/
> ApplicationServices.h:20,
>  from
> /System/Library/Frameworks/Foundation.framework/Headers/
> NSAppleEventDescriptor.h:8,
>  from
> /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:107,
>  from 61759_main.mm:1:
> /System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:102:46:
> error: shift expression ‘(1853123693 << 8)’ overflows [-fpermissive]
>  kSecAuthenticationTypeNTLM = AUTH_TYPE_FIX_ ('ntlm'),
>   ^
> /System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:102:46:
> error: enumerator value for ‘kSecAuthenticationTypeNTLM’ is not an integer
> constant
>  kSecAuthenticationTypeNTLM = AUTH_TYPE_FIX_ ('ntlm'),
>   ^
> /System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:103:46:
> error: shift expression ‘(1836281441 << 8)’ overflows [-fpermissive]
>  kSecAuthenticationTypeMSN  = AUTH_TYPE_FIX_ ('msna'),
>   ^
> /System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:103:46:
> error: enumerator value for ‘kSecAuthenticationTypeMSN’ is not an integer
> constant
>  kSecAuthenticationTypeMSN  = AUTH_TYPE_FIX_ ('msna'),
>   ^
> /System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:104:46:
> error: shift expression ‘(1685086561 << 8)’ overflows [-fpermissive]
>  kSecAuthenticationTypeDPA  = AUTH_TYPE_FIX_ ('dpaa'),
>   ^
> /System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:104:46:
> error: enumerator value for ‘kSecAuthenticationTypeDPA’ is not an integer
> constant
>  kSecAuthenticationTypeDPA  = AUTH_TYPE_FIX_ ('dpaa'),
>   ^
> /System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:105:46:
> error: shift expression ‘(1919967585 << 8)’ overflows [-fpermissive]
>  kSecAuthenticationTypeRPA  = AUTH_TYPE_FIX_ ('rpaa'),
>   ^
> /System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:105:46:
> error: enumerator value for ‘kSecAuthenticationTypeRPA’ is not an integer
> constant
>  kSecAuthenticationTypeRPA  = AUTH_TYPE_FIX_ ('rpaa'),
>   ^
> 

[Bug bootstrap/59447] --with-dwarf2 is not propagated correctly, will always create dwarf4 by default

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #1)
> This is a documentation bug - the installation manual should make clear 
> that "DWARF 2" in the description of this option means DWARF 2 or later, 
> as appropriate for the target, as opposed to (for example) STABS.

Confirmed, the documentation for --with-dwarf2 is still just:

--with-dwarf2

Specify that the compiler should use DWARF 2 debugging information as the
default.

[Bug objc++/57607] g++ cannot distinguish obj-c message call from c++11 lambda

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> The testcase breaks again with gcc8 though, this time causing an ICE:
> 
> $ /usr/local/bin/g++ -std=c++11 -framework CoreFoundation -lobjc test57607.mm
> In file included from /usr/local/include/c++/8.0.0/bits/ios_base.h:46:0,
>  from /usr/local/include/c++/8.0.0/ios:42,
>  from /usr/local/include/c++/8.0.0/ostream:38,
>  from /usr/local/include/c++/8.0.0/iostream:39,
>  from test57607.mm:2:
> /usr/local/include/c++/8.0.0/system_error:191:23: internal compiler error:
> Segmentation fault
>  explicit operator bool() const noexcept
>^~~~
> libbacktrace could not find executable to open
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> 
> 
> Attaching gdb gives the following backtrace:
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x3a138e4c
> 0x0010d744 in make_conv_op_name ()
> (gdb) bt
> #0  0x0010d744 in make_conv_op_name ()
> #1  0x00169ac7 in cp_parser_unqualified_id ()
> #2  0x00169e49 in cp_parser_id_expression ()
> #3  0x00169fb3 in cp_parser_parse_and_diagnose_invalid_type_name ()
> #4  0x0015e084 in cp_parser_member_declaration ()
> #5  0x0015ea24 in cp_parser_type_specifier ()
> #6  0x0016f480 in cp_parser_decl_specifier_seq ()
> #7  0x00174ab5 in cp_parser_simple_declaration ()
> #8  0x00175bdf in cp_parser_block_declaration ()
> #9  0x0017addc in cp_parser_declaration ()
> #10 0x0017b21e in cp_parser_declaration_seq_opt ()
> #11 0x0017b965 in cp_parser_namespace_definition ()
> #12 0x0017aeb9 in cp_parser_declaration ()
> #13 0x0017b21e in cp_parser_declaration_seq_opt ()
> #14 0x0017b576 in c_parse_file ()
> #15 0x00280a78 in c_common_parse_file ()
> #16 0x00bee0e5 in compile_file ()
> #17 0x01b02420 in toplev::main ()
> #18 0x01b03a34 in main ()
> 
> I'll have to rebuild my gcc with debug info to get a better backtrace. It
> might be an entirely different issue that's just triggered by the same
> testcase, though, so I'm leaving this bug as UNCONFIRMED for now.

This ICE seems to have disappeared on me; file compiles successfully for me
now, but the resulting executable crashes when run:

$ /usr/local/bin/g++ -std=gnu++11 -framework CoreFoundation -lobjc -g -Wall
-Wextra -pedantic -o 57607.exe test57607.mm
$ ./57607.exe && echo $?
Hello world!
Bus error
$

gdb shows the error comes from objc_msgSend:

.+ done
Hello world!

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x940e968c in objc_msgSend ()
(gdb) bt
#0  0x940e968c in objc_msgSend ()
#1  0x1e81 in main () at test57607.mm:10
#2  0x1dde in start ()
(gdb) quit
The program is running.  Exit anyway? (y or n) y

objc_msgSend comes from the system libobjc, so this is an issue with Apple's
system libraries for my (outdated) OS version, not gcc. So since this is no
longer gcc's issue and the original ICE is fixed, I can close this as FIXED.

[Bug bootstrap/80897] [8 regression] gnat bootstrap broken on SPARC64/Linux

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #11 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug bootstrap/80897] [8 regression] gnat bootstrap broken on SPARC64/Linux

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Sep  7 15:53:09 2017
New Revision: 251847

URL: https://gcc.gnu.org/viewcvs?rev=251847=gcc=rev
Log:
PR target/80897
* config/sparc/sparc.c (sparc_emit_set_symbolic_const64): Deal with too
large offsets.

Added:
trunk/gcc/testsuite/gnat.dg/opt67.adb
trunk/gcc/testsuite/gnat.dg/opt67_pkg.adb
trunk/gcc/testsuite/gnat.dg/opt67_pkg.ads
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.c
trunk/gcc/testsuite/ChangeLog

[Bug c/82134] warn_unused_result triggers on empty structs even when they are used

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
The problem with `if (0) { /* don't warn about stuff in here */ }` is that you
can jump into that block from elsewhere:

if (0)
  {
L:
// ...
  }

so it's not as easy as it might seem.

[Bug boehm-gc/57761] USE_PROC_FOR_LIBRARIES does not work correctly

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
gcc no longer carries its own copy of the boehm-gc sources; please send your
patch to the upstream boehm-gc project instead.

[Bug libstdc++/70548] gdb pretty printers hang and spin cpu in gdb session.

[smark at datto dot com]

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

--- Comment #4 from stu mark  ---
I left that more for Henrique Andrade.

If there's a problem with the pretty printer, and a lousy hack like this can
keep gdb from hanging, to me, it's worth it.


I don't know which pretty printer was having the problem, and it happens
randomly in various bits of code, and not consistently, so I can't really tell
which printer is hanging. If you have suggestions on how to figure that out,
I'll give it a go.

[Bug boehm-gc/64042] FAIL: boehm-gc.c/gctest.c -O2 execution test

[egallager at gcc dot gnu.org]

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

--- Comment #16 from Eric Gallager  ---
(In reply to Tom de Vries from comment #13)
> (In reply to Eric Gallager from comment #12)
> > (In reply to Tom de Vries from comment #11)
> > > Reported upstream here:
> > > https://lists.opendylan.org/pipermail/bdwgc/2015-January/006071.html
> > 
> > This link doesn't work for me; is there a better upstream bug link URL?
> 
> The archive seems to be down, and also gmane doesn't seem to work. I'll post
> the thread here.

OK, since there's no working link to an upstream bug report, I can't close this
as MOVED... gcc trunk no longer carries its own copy of the boehm-gc sources,
but since this bug is for the 5 branch, I'll wait until that branch is closed
to close this bug as WONTFIX.

[Bug libstdc++/70548] gdb pretty printers hang and spin cpu in gdb session.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-09-07
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
We can't try to fix the  pretty printers without knowing which printer is being
used, and on what code.

See https://gcc.gnu.org/bugs/

[Bug c/82134] warn_unused_result triggers on empty structs even when they are used

[zackw at panix dot com]

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

--- Comment #2 from Zack Weinberg  ---
The claim in the Stack Overflow post was that this was useful in a scenario
involving machine-generated code that couldn't return void for some external
reason, but they didn't go into any kind of detail.

It has always been my opinion that warnings in general should be made
optimization-independent, including early dead code optimizations like this,
with _possible_ carefully-defined-and-documented exceptions for `if (0) { /*
don't warn about stuff in here */ }` and similar.  But I realize that's a long
way from where GCC is or has ever been.

[Bug middle-end/82083] sanitizer detects signed integer overflow in tree-data-ref.c with -O3

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Good, then let's leave it..

[Bug libstdc++/70548] gdb pretty printers hang and spin cpu in gdb session.

[smark at datto dot com]

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

--- Comment #2 from stu mark  ---
this finally got so annoying I did something about it.

This is not the correct fix, but it seems to keep gdb from hanging and as all I
really want to do in life is debug my program, I don't care if it's not
perfect, I just care that I can continue to debug.

in varobj.c

line 778 or so  (this is gdb 7.12.1 I'm playing with here)

  /* We ask for one extra child, so that MI can report whether there
 are more children.  */
  for (; to < 0 || i < to + 1; ++i)
{ 
  if ( i > 100 ) // stu fix for hanging when to = -1
break;
  varobj_item *item;

"to" is -1 and that makes this loop spin forever

so I added the stop at 100 figuring 100 whatevers is enough for me.

[Bug ada/82127] [8 regression] gnat.dg/specs/constructor.ads FAILs

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
.

[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #15)
> Yeah, I have a patch that does this. The question is how to query the target
> if the vector sizes share the same register set. Like we wouldn't want to go
> to mmx register size.
> 
> Doing this would also allow to execute the adds for 512 to 128 bit reduction
> in parallel.

I wonder if we just shouldn't have a target hook that does all that (emits the
best reduction sequence given original vector mode and operation), which could
return NULL/false or something to be expanded by the generic code.  The
middle-end doesn't have information about costs of the various permutations,
preferences of vector types etc.

[Bug ada/82127] [8 regression] gnat.dg/specs/constructor.ads FAILs

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Sep  7 15:33:29 2017
New Revision: 251846

URL: https://gcc.gnu.org/viewcvs?rev=251846=gcc=rev
Log:
PR ada/82127
* gcc-interface/decl.c (copy_and_substitute_in_layout): Put the fields
in order of increasing position in more cases.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/decl.c

[Bug c++/70029] [8 Regression] ICE with C++11 and -flto

[jason at gcc dot gnu.org]

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

--- Comment #14 from Jason Merrill  ---
(In reply to Jason Merrill from comment #13)
> I believe r241831 fixed the actual problem that verify_type was catching. 
> This still fails because free_lang_data_in_type clears TYPE_LANG_FLAG_4 on
> 't' but not 'ct'.

No, that's not it.

The issue is still that build_ref_qualified_type creates a variant, and
build_type_attribute_qual_variant doesn't know how to recreate that, so it
returns a type that is its own main variant.  We'll run into the same issue
with exception specifications.  So it seems we need a langhook somewhere in
BTAQV or build_distinct_type_copy, to reproduce the language qualifiers and
variant relationship.

[Bug c/82134] warn_unused_result triggers on empty structs even when they are used

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I fail to see the usefulness of warn_unused_result attribute on functions that
return such types, what kind of problem is calling those without assigning that
to a var?  There are no data copied...
>From implementation POV, the problem is that the empty structure copies are
discarded during gimplification (in different spots, for C++ they are discarded
through cp-gimplify.c (cp_gimplify_expr) doing:
else if (simple_empty_class_p (TREE_TYPE (op0), op1))
  {
/* Remove any copies of empty classes.  Also drop volatile
   variables on the RHS to avoid infinite recursion from
   gimplify_expr trying to load the value.  */
if (TREE_SIDE_EFFECTS (op1))
  {
if (TREE_THIS_VOLATILE (op1)
&& (REFERENCE_CLASS_P (op1) || DECL_P (op1)))
  op1 = build_fold_addr_expr (op1);

gimplify_and_add (op1, pre_p);
  }
gimplify_expr (_OPERAND (*expr_p, 0), pre_p, post_p,
   is_gimple_lvalue, fb_lvalue);
*expr_p = TREE_OPERAND (*expr_p, 0);
  }
while for C, it is done through gimplify.c (gimplify_modify_expr) doing:
  /* For zero sized types only gimplify the left hand side and right hand
 side as statements and throw away the assignment.  Do this after
 gimplify_modify_expr_rhs so we handle TARGET_EXPRs of addressable
 types properly.  */
  if (zero_sized_type (TREE_TYPE (*from_p)) && !want_value)
{
  gimplify_stmt (from_p, pre_p);
  gimplify_stmt (to_p, pre_p);
  *expr_p = NULL_TREE;
  return GS_ALL_DONE;
}

and after that there is no way to differentiate if the call had a lhs or not.

Perhaps we could add a langhook and for zero_sized_type or if the langhook is
true (would use simple_empty_class_p for C++, otherwise false) just ignore the
warn_unused_result attribute or something similar; that would mean we wouldn't
warn in should_warn at least for C though (for C++ we would, because we turn it
into a TARGET_EXPR and warn as we voidify the call).

[Bug ipa/82107] [5/6/7/8 Regression] O2 optimisation on amd64 leads to error

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Huh, very nice example I must admit.

Following bad happens:

In FooImpl.cpp content of real_payload is inlined to payload function. Then ICF
does merge operation:

FooImpl::real_payload (struct FooImpl * const this, struct wstring & result1,
struct wstring & result2)
{
   [100.00%] [count: INV]:
  FooBase::payload (this_2(D), result1_3(D), result2_4(D)); [tail
call]
  return;
}

On the other hand in main.cpp a tail call is generated from original source
code:

FooBase::payload (struct FooBase * const this, struct wstring &
result1, struct wstring & result2)
{
   [100.00%] [count: INV]:
  FooImpl::real_payload (this_2(D), result1_3(D), result2_4(D)); [tail call]
  return;
}

And as both are COMDATs wrong combination of function is selected and one can
see the infinite loop:

0x400b80
<_ZN7FooImpl12real_payloadERNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEEES6_>
  jmpq   0x400a30
<_ZN7FooBaseI7FooImplE7payloadERNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEEES8_>
0x400a30
<_ZN7FooBaseI7FooImplE7payloadERNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEEES8_>
jmpq   0x400b80
<_ZN7FooImpl12real_payloadERNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEEES6_>_>
 

Well, we would need to somehow preserve the original order, probably based on
inlining decisions that were done.
Let me discuss that with Honza.

[Bug testsuite/82120] FAIL: gcc.dg/tree-ssa/pr81588.c

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
The best would be to add -mbranch-cost= support like many other targets have,
and have an effective target with the list of targets that do support it,
adjust all such testcases to use that.

[Bug testsuite/82120] FAIL: gcc.dg/tree-ssa/pr81588.c

[clyon at gcc dot gnu.org]

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

--- Comment #9 from Christophe Lyon  ---
Sure, I'm just reluctant to add yet another
check_effective_target_arm_cortex_a5 function in the already extremely long
list of arm-dedicated queries.

Maybe I can play with arm's -mprint-tune-info, which dumps tuning parameters in
the .s file:
for cortex-m7:
@logical_op_non_short_circuit:  [1,1]
for cortex-a9:
@logical_op_non_short_circuit:  [1,1]
for cortex-a5:
@logical_op_non_short_circuit:  [0,0]

and use that to write a check_effective_target_arm_short_circuit ?

[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de  ---
On September 7, 2017 1:53:47 PM GMT+02:00, "jakub at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80846
>
>--- Comment #14 from Jakub Jelinek  ---
>(In reply to Richard Biener from comment #11)
>> that's not using the unpacking strategy (sum adjacent elements) but
>still the
>> vector shift approach (add upper/lower halves).  That's sth that can
>be
>> changed independently.
>> 
>> Waiting for final vec_extract/init2 optab settling.
>
>That should be settled now.
>
>BTW, for reductions in PR80324 I've added for avx512fintrin.h
>__MM512_REDUCE_OP
>which for reductions from 512-bit vectors uses smaller and smaller
>vectors,
>perhaps that is something we should use for the reductions emitted by
>the
>vectorizer too (perhaps through a target hook that would emit gimple
>for the
>reduction)?

Yeah, I have a patch that does this. The question is how to query the target if
the vector sizes share the same register set. Like we wouldn't want to go to
mmx register size.

Doing this would also allow to execute the adds for 512 to 128 bit reduction in
parallel.

[Bug testsuite/82120] FAIL: gcc.dg/tree-ssa/pr81588.c

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Christophe Lyon from comment #7)
> I think it returns 0 in the testcase (optimizing for speed).
> 
> I've noticed that arm_cortex_a5_branch_cost() has the same implementation as
> arm_cortex_m7_branch_cost(), but according to Thomas, the behaviour is
> different, since he sees the test pass for m7.
> 
> Is it possible to write a dynamic gcc query rather than hardcode cpu names
> in logical_op_short_circuit ?

As:
...
 || [istarget visium-*-*]
 || [check_effective_target_arm_cortex_m] } {
shows, you can do there anything you want. Ideally it should be cached.

[Bug testsuite/82120] FAIL: gcc.dg/tree-ssa/pr81588.c

[clyon at gcc dot gnu.org]

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

--- Comment #7 from Christophe Lyon  ---
I think it returns 0 in the testcase (optimizing for speed).

I've noticed that arm_cortex_a5_branch_cost() has the same implementation as
arm_cortex_m7_branch_cost(), but according to Thomas, the behaviour is
different, since he sees the test pass for m7.

Is it possible to write a dynamic gcc query rather than hardcode cpu names in
logical_op_short_circuit ?

[Bug c/82134] New: warn_unused_result triggers on empty structs even when they are used

[zackw at panix dot com]

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

Bug ID: 82134
   Summary: warn_unused_result triggers on empty structs even when
they are used
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zackw at panix dot com
  Target Milestone: ---

If a function that returns an empty struct is tagged with attribute
warn_unused_result, any call will trigger the warning, even if the return value
is (nominally) used.  For instance

struct Empty {};

extern void use_empty(struct Empty);

__attribute__((warn_unused_result))
extern struct Empty make_empty(void);

void should_warn(void)
{
make_empty();
}

void shouldnt_warn_1(void)
{
use_empty(make_empty());
}

void shouldnt_warn_2(void)
{
struct Empty e = make_empty();
use_empty(e);
}

-->

test.c: In function ‘should_warn’:
test.c:10:5: warning: ignoring return value of ‘make_empty’, declared with
attribute warn_unused_result [-Wunused-result]
 make_empty();
 ^~~~
test.c: In function ‘shouldnt_warn_1’:
test.c:15:5: warning: ignoring return value of ‘make_empty’, declared with
attribute warn_unused_result [-Wunused-result]
 use_empty(make_empty());
 ^~~
test.c: In function ‘shouldnt_warn_2’:
test.c:20:22: warning: ignoring return value of ‘make_empty’, declared with
attribute warn_unused_result [-Wunused-result]
 struct Empty e = make_empty();
  ^~~~

with both GCC 6 and GCC 7.

(From here:
https://stackoverflow.com/questions/46096628/gcc-empty-structs-and-wunused-result)

[Bug c/82133] New: unroll-loops too aggressive

[nickpapior at gmail dot com]

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

Bug ID: 82133
   Summary: unroll-loops too aggressive
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickpapior at gmail dot com
  Target Milestone: ---

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/generic/gcc/7.2.0/libexec/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix /opt/generic/gcc/7.2.0
--with-gmp=/opt/generic/gcc/7.2.0 --with-mpfr=/opt/generic/gcc/7.2.0
--with-mpc=/opt/generic/gcc/7.2.0 --with-isl=/opt/generic/gcc/7.2.0
--enable-lto --enable-threads --with-quad --with-multilib-list=m64
--enable-languages=c,c++,fortran,objc,obj-c++,go
Thread model: posix
gcc version 7.2.0 (GCC) 

The following bug has been confirmed by other parts and runned using these
variants:

 - SuSE tumbleweed with system GCC 7.1.1, Atom core
 - Debian stretch with custom 7.1.0 and 7.2.0 builds (according to flags
above), Haswell core
 - Another distribution (see martin-frbg user in below link).

As several 7.X versions are found; assigned 7.0.


When using unroll-loops to compile OpenBLAS (0.2.20 and developer) it produces
seg-faults when running the tests.
It happens at these minimum compilation options:

  -O1 -funroll-loops -fipa-ra

As long as -funroll-loops isn't in the compilation flags everything works as
expected (even for much higher optimization levels: -O3
-fexpensive-optimizations -ftree-vectorize -fprefetch-loop-arrays
-march=native)

It only happens with compilation with optimization, so a backtrace is unusable
(I am not experienced enough to run gdb efficiently).

An invalid memory reference is triggered:

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


I have filed a bug-report with OpenBLAS too and they indicate that it is
because GCC unrolls a loop one to many times.
For the discussion see here: https://github.com/xianyi/OpenBLAS/issues/1292


The bug can be reproduced by using this small script (in the OpenBLAS
directory):
###
#!/bin/bash

function run_all {
echo "CFLAGS = $CFLAGS"
echo "FCFLAGS = $FCFLAGS"
make clean > /dev/null
make COMMON_OPT="$CFLAGS" FCOMMON_OPT="$FCFLAGS" BINARY=64 SANITY_CHECK=1
MAX_STACK_ALLOC=2048 NUM_THREADS=48 USE_THREAD=0 libs netlib shared 2>
${1}_compilation.out > ${1}_compilation.out
make COMMON_OPT="$CFLAGS" FCOMMON_OPT="$FCFLAGS" BINARY=64 SANITY_CHECK=1
MAX_STACK_ALLOC=2048 NUM_THREADS=48 USE_THREAD=0 tests 2> $1.out > $1.out
}
which gcc
sleep 1

unset FCFLAGS
unset CFLAGS
export CFLAGS="-O1 -funroll-loops -fipa-ra"
export FCFLAGS="$CFLAGS"
run_all minimum
###

[Bug target/82132] New: FAIL: gcc.dg/vect/vect-tail-nomask-1.c (test for excess errors) due to missing posix_memalign

[egallager at gcc dot gnu.org]

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

Bug ID: 82132
   Summary: FAIL: gcc.dg/vect/vect-tail-nomask-1.c (test for
excess errors) due to missing posix_memalign
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
CC: hjl at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-apple-darwin9.8.0
Target: i386-apple-darwin9.8.0
 Build: i386-apple-darwin9.8.0

gcc.dg/vect/vect-tail-nomask-1.c FAILs with:

FAIL: gcc.dg/vect/vect-tail-nomask-1.c (test for excess errors)
Excess errors:
Undefined symbols:
  "_posix_memalign", referenced from:
  _run_test in ccH1tfXl.o
  _run_test in ccH1tfXl.o
  _run_test in ccH1tfXl.o
  _posix_memalign$non_lazy_ptr in ccH1tfXl.o
ld: symbol(s) not found

WARNING: gcc.dg/vect/vect-tail-nomask-1.c compilation failed to produce
executable

This is because the posix_memalign function hadn't been added yet in Darwin 9.
Instead of looking for an external posix_memalign, the testcase should use
__builtin_posix_memalign. Related to the lack of documentation for the builtin
noted in bug 65244 comment 9.

[Bug target/81833] [7/8 Regression] PowerPC: VSX: Miscompiles ffmpeg's scalarproduct_int16_vsx at -O1

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
Yes, I have backports prepared for 5, 6, and 7.  Waiting a short time before
applying those.

Thanks!
Bill

[Bug libgomp/82124] FAIL: libgomp.c++/pr69393.C (test for excess errors)

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Richard Biener from comment #3)
> I think this is a dup, the testcase uses -flto.
> 
> *** This bug has been marked as a duplicate of bug 82005 ***

Oh OK, I'm guessing a lot of the other new FAILs are probably also duplicates
then, so I won't open new bugs for all of them after all then.

[Bug go/82131] FAIL: TestCgoCallbackGC in gotools testsuite; segfaults in morestack.S:529

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu,
   ||powerpc64le-unknown-linux-g
   ||nu
Version|unknown |8.0

--- Comment #1 from Uroš Bizjak  ---
Also seen on powerpc64le-unknown-linux-gnu [1].

[1] https://gcc.gnu.org/ml/gcc-testresults/2017-09/msg00524.html

[Bug go/82131] New: FAIL: TestCgoCallbackGC in gotools testsuite; segfaults in morestack.S:529

[ubizjak at gmail dot com]

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

Bug ID: 82131
   Summary: FAIL: TestCgoCallbackGC in gotools testsuite;
segfaults in morestack.S:529
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ubizjak at gmail dot com
CC: cmang at google dot com
  Target Milestone: ---

The testcase fails on x86_64-linux-gnu split-stack target.

Running the testcase manually under the debugger:

$gdb --args ./testprogcgo CgoCallbackGC

(gdb) r
Starting program:
/home/uros/git/gcc/libgo/go/runtime/testdata/testprogcgo/testprogcgo
CgoCallbackGC
warning: no loadable sections found in added symbol-file system-supplied DSO at
0x2aaab000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x2d51d940 (LWP 1741)]
[New Thread 0x2f5c6940 (LWP 1742)]
[New Thread 0x2f9da940 (LWP 1744)]
[New Thread 0x2f7d0940 (LWP 1743)]
[New Thread 0x2aaac9a6b940 (LWP 1745)]
[New Thread 0x2aaac9c75940 (LWP 1746)]
...
[New Thread 0x2aab347a9940 (LWP 1944)]
[New Thread 0x2aab34c8b940 (LWP 1945)]
[New Thread 0x2aab34e97940 (LWP 1946)]
[New Thread 0x2aab354a6940 (LWP 1947)]
[New Thread 0x2aab356b0940 (LWP 1948)]
[New Thread 0x2aab37906940 (LWP 1949)]
[Thread 0x2aab0050e940 (LWP 1849) exited]
[Thread 0x2aaae5289940 (LWP 1784) exited]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2aab01168940 (LWP 1851)]
__morestack () at ../../../git/gcc/libgcc/config/i386/morestack.S:529
529 call__morestack_unblock_signals

(gdb) bt
#0  __morestack () at ../../../git/gcc/libgcc/config/i386/morestack.S:529
#1  0x2ba3e73e in dwarf_lookup_pc (state=state@entry=0x2d91f000,
ddata=ddata@entry=0x2f12fd10, pc=, 
pc@entry=46912512497780, callback=callback@entry=0x2b4e1aa0 ,
error_callback=error_callback@entry=0x2b4e1d20 , 
data=data@entry=0x2aab42847740, found=) at
../../../git/gcc/libbacktrace/dwarf.c:2836
#2  0x2ba3fbbf in dwarf_fileline (state=0x2d91f000,
pc=46912512497780, callback=0x2b4e1aa0 , 
error_callback=0x2b4e1d20 , data=0x2aab42847740) at
../../../git/gcc/libbacktrace/dwarf.c:2896
#3  0x2ba40cc6 in unwind (context=,
vdata=0x2aab42847700) at ../../../git/gcc/libbacktrace/backtrace.c:91
#4  0x2c495499 in _Unwind_Backtrace (trace=trace@entry=0x2ba40c40
, trace_argument=trace_argument@entry=0x2aab42847700)
at ../../../git/gcc/libgcc/unwind.inc:295
#5  0x2ba40d39 in backtrace_full (state=0x2d91f000,
skip=skip@entry=0, callback=callback@entry=0x2b4e1aa0 , 
error_callback=error_callback@entry=0x2b4e1d20 ,
data=data@entry=0x2aab42847740)
at ../../../git/gcc/libbacktrace/backtrace.c:127
#6  0x2b4e1dd5 in runtime_callers (skip=skip@entry=4, locbuf=, m=, keep_thunks=keep_thunks@entry=false)
at ../../../git/gcc/libgo/runtime/go-callers.c:184
#7  0x2b940071 in runtime.callers (skip=skip@entry=4, locbuf=...) at
../../../git/gcc/libgo/go/runtime/traceback_gccgo.go:63
#8  0x2b96e4c4 in runtime.mProf_Malloc (size=16, p=) at
../../../git/gcc/libgo/go/runtime/mprof.go:245
#9  runtime.profilealloc (mp=0xc4203fc000, size=16, x=) at
../../../git/gcc/libgo/go/runtime/malloc.go:873
#10 runtime.mallocgc (size=, typ=,
needzero=) at ../../../git/gcc/libgo/go/runtime/malloc.go:795
#11 0x2ba49875 in __morestack () at
../../../git/gcc/libgcc/config/i386/morestack.S:544
#12 0x2b97014f in runtime.newobject (typ=) at
../../../git/gcc/libgo/go/runtime/malloc.go:850
#13 0x00406fb6 in main.grow1 (x=0xc42010a8a0, sum=0xc4202e0ce8) at
/home/uros/git/gcc/libgo/go/runtime/testdata/testprogcgo/callback.go:66
#14 0x00406fe1 in main.grow1 (x=0xc42010a8a0, sum=0xc4202e0ce0) at
/home/uros/git/gcc/libgo/go/runtime/testdata/testprogcgo/callback.go:67
#15 0x00406fe1 in main.grow1 (x=0xc42010a8a0, sum=0xc4202e0cd8) at
/home/uros/git/gcc/libgo/go/runtime/testdata/testprogcgo/callback.go:67
...
#63 0x00406fe1 in main.grow1 (x=0xc42010a8a0, sum=0xc4202e0b58) at
/home/uros/git/gcc/libgo/go/runtime/testdata/testprogcgo/callback.go:67
#64 0x00406fe1 in main.grow1 (x=0xc42010a8a0, sum=0xc4202e0b50) at
/home/uros/git/gcc/libgo/go/runtime/testdata/testprogcgo/callback.go:67
#65 0x2ba3ca20 in ?? () at ../../../git/gcc/libbacktrace/dwarf.c:925
from /home/uros/local/lib64/libgo.so.11
#66 0x2aab42846000 in ?? ()

(gdb) disass
   ...
   0x2ba4982c <+42>:callq  0x2ba48890 <__generic_morestack>
   0x2ba49831 <+47>:mov-0x8(%rbp),%r10
   0x2ba49835 <+51>:mov%rax,%rsp
   0x2ba49838 <+54>:sub%r10,%rax
   0x2ba4983b <+57>:add$0x600,%rax
   0x2ba49841 <+63>:mov%rax,%fs:0x70
=> 

[Bug middle-end/81698] expand_case uses wrong edge as default edge

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug go/81970] carchive gotools tests fail

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #2 from Uroš Bizjak  ---
Fixed by [1].

[1] https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01747.html

[Bug target/81979] [8 Regression] Assembler messages: Error: can't resolve `.got2' {.got2 section} - `.LCF0' {.text.unlikely section}

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Yes.  While powerpc{,64}* is primary target and regressions there are relevant
for releases, powerpcspe* is not.

[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #11)
> that's not using the unpacking strategy (sum adjacent elements) but still the
> vector shift approach (add upper/lower halves).  That's sth that can be
> changed independently.
> 
> Waiting for final vec_extract/init2 optab settling.

That should be settled now.

BTW, for reductions in PR80324 I've added for avx512fintrin.h __MM512_REDUCE_OP
which for reductions from 512-bit vectors uses smaller and smaller vectors,
perhaps that is something we should use for the reductions emitted by the
vectorizer too (perhaps through a target hook that would emit gimple for the
reduction)?

[Bug target/81979] [8 Regression] Assembler messages: Error: can't resolve `.got2' {.got2 section} - `.LCF0' {.text.unlikely section}

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||andrewjenner at gcc dot 
gnu.org,
   ||charlet at gcc dot gnu.org

--- Comment #6 from Arseny Solokha  ---
Should I file a new PR asking to port the fix to powerpcspe, then?

[Bug target/81979] [8 Regression] Assembler messages: Error: can't resolve `.got2' {.got2 section} - `.LCF0' {.text.unlikely section}

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug target/81833] [7/8 Regression] PowerPC: VSX: Miscompiles ffmpeg's scalarproduct_int16_vsx at -O1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
So fixed on the trunk so far?  Any plans for 7.x backport?

[Bug middle-end/82123] [7/8 regression] spurious -Wformat-overflow warning for converted vars

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This is the typical case of value range info being more precise during vrp pass
(where we have ASSERT_EXPRs) rather than elsewhere (where we don't have them
and pin_3 here is set before the condition).  Supposedly the planed on demand
value range stuff could help there, but I have no idea for ETA on that.

[Bug c++/82125] Suboptimal error message for range-based for

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Yes, we should have a custom diagnostic for range-based 'for' that fails to
compile.

[Bug target/81979] [8 Regression] Assembler messages: Error: can't resolve `.got2' {.got2 section} - `.LCF0' {.text.unlikely section}

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep  7 11:20:40 2017
New Revision: 251843

URL: https://gcc.gnu.org/viewcvs?rev=251843=gcc=rev
Log:
PR target/81979
* output.h (switch_to_other_text_partition): New declaration.
* varasm.c (switch_to_other_text_partition): New function.
* config/rs6000/rs6000.c (uses_TOC): Return 2 if
NOTE_INSN_SWITCH_TEXT_SECTIONS is seen before finding load_toc_* insn.
(rs6000_elf_declare_function_name): If uses_TOC returned 2, switch
to the other text partition before emitting LCL label and switch back
after emitting the word after it.

* gcc.dg/pr81979.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr81979.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/output.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug tree-optimization/82128] [8 Regression] ICE on valid code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-09-07
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine then.

[Bug tree-optimization/82129] [8 Regression] ICE in compute_antic, at tree-ssa-pre.c:2447

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/82129] [8 Regression] ICE in compute_antic, at tree-ssa-pre.c:2447

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-07
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r249063.

[Bug preprocessor/82130] New: stringification (#) in traditional mode

[janus at gcc dot gnu.org]

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

Bug ID: 82130
   Summary: stringification (#) in traditional mode
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

I noticed that cpp does not seem to support stringification in traditional
mode.

Simple Fortran test:


#define _ASSERT_(expr)  if (.not. (expr)) print *, #expr
program test
logical :: check = .false.
_ASSERT_(check)
end


cpp in standard mode does the expected thing, namely translate the _ASSERT_
line into:

if (.not. (check)) print *, "check"

(which is valid Fortran code). But with -traditional I get:

if (.not. (check)) print *, #check

That's a shame because it makes stringification unusable with gfortran. Is is
feasible to add support for stringification in traditional mode?

[Bug ada/82127] [8 regression] gnat.dg/specs/constructor.ads FAILs

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
Fixing.

[Bug ada/82127] [8 regression] gnat.dg/specs/constructor.ads FAILs

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-07
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
Yes, an infinite recursion.

[Bug tree-optimization/82129] New: [8 Regression] ICE in compute_antic, at tree-ssa-pre.c:2447

[asolokha at gmx dot com]

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

Bug ID: 82129
   Summary: [8 Regression] ICE in compute_antic, at
tree-ssa-pre.c:2447
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20170903 snapshot (r251628) ICEs when compiling the following
snippet w/ -O2, -O3, or -Ofast:

int pj;

void
g4 (unsigned long int *bc, unsigned long int *h5)
{
  if (pj != 0)
{
  int ib = 0;

  while (bc != 0)
{
 m6:
  for (pj = 0; pj < 2; ++pj)
pj = 0;

  while (pj != 0)
{
  for (;;)
{
}

  while (ib != 0)
{
  unsigned long int tv = *bc;
  unsigned long int n7;

  *bc = 1;
  while (*bc != 0)
{
}

 ut:
  if (pj == 0)
n7 = *h5 > 0;
  else
{
  *h5 = tv;
  n7 = *h5;
}
  ib += n7;
}
}
}

  goto ut;
}

  goto m6;
}

% gcc-8.0.0-alpha20170903 -O2 -c vbgefb2z.c 
during GIMPLE pass: pre
vbgefb2z.c: In function 'g4':
vbgefb2z.c:4:1: internal compiler error: in compute_antic, at
tree-ssa-pre.c:2447
 g4 (unsigned long int *bc, unsigned long int *h5)
 ^~

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[marxin at gcc dot gnu.org]

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

--- Comment #26 from Martin Liška  ---
Sorry for the inconvenience, I'll work on that with Honza right after Cauldron
this weekend.

[Bug c++/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail

[marxin at gcc dot gnu.org]

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

--- Comment #38 from Martin Liška  ---
So downloading the package and testing that with problematic 6.3 does not
reproduce. Can you please verify you have really GCC 6.4? If so, would it be
possible to create a virtual machine or a Docker image which I can replay and
thus reproduce?

[Bug c++/82067] G++ has an internal compiler error in possible_polymorphic_call_targets, at ipa-devirt.c:1557

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Sorry I meant --verbose (not --save-temps) :)

[Bug tree-optimization/82128] [8 Regression] ICE on valid code

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |8.0

[Bug tree-optimization/82128] New: [8 Regression] ICE on valid code

[marxin at gcc dot gnu.org]

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

Bug ID: 82128
   Summary: [8 Regression] ICE on valid code
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

After Richi's commit r251650 we ICE on:

$ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/torture/pr65626.C -O3
-fno-tree-forwprop
during GIMPLE pass: fre
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/torture/pr65626.C: In member
function ‘void B::m_fn3(const A&, const int&, const C&, int&) const’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/torture/pr65626.C:19:1:
internal compiler error: in VN_INFO, at tree-ssa-sccvn.c:387
 }
 ^
0xf6f52b VN_INFO(tree_node*)
../../gcc/tree-ssa-sccvn.c:387
0xf47c35 eliminate_avail
../../gcc/tree-ssa-pre.c:4104
0xf4a0b7 eliminate_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-pre.c:4604
0x14e0c7a dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:291
0xf4923b eliminate
../../gcc/tree-ssa-pre.c:4831
0xf4930e execute
../../gcc/tree-ssa-pre.c:5277

[Bug ada/82127] [8 regression] gnat.dg/specs/constructor.ads FAILs

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
This is the failure on ia64:

Program received signal SIGSEGV, Segmentation fault.
wi::fits_to_tree_p > (
x=, 
type=) at ../../gcc/tree.h:5263
5263wi::fits_to_tree_p (const T , const_tree type)
(gdb) bt
#0  wi::fits_to_tree_p > (
x=, 
type=) at ../../gcc/tree.h:5263
#1  0x42133190 in force_fit_type (
type=, 
cst=, 
overflowable=, 
overflowed=) at ../../gcc/tree.c:1348
(gdb) x/i $pc
=> 0x421419c0

>(generic_wide_int const&, tree_node const*)>:  
[MMI]   alloc r39=ar.pfs,15,10,0

That looks like a stack overflow.

[Bug ada/82127] [8 regression] gnat.dg/specs/constructor.ads FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug ada/82126] [8 regression] gnat.dg/alignment3.adb FAILs

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
.

[Bug ada/82126] [8 regression] gnat.dg/alignment3.adb FAILs

[ebotcazou at gcc dot gnu.org]

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

--- Comment #1 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Sep  7 09:27:31 2017
New Revision: 251834

URL: https://gcc.gnu.org/viewcvs?rev=251834=gcc=rev
Log:
PR ada/82126
* gnat.dg/alignment3.adb: Add pragma No_Component_Reordering.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gnat.dg/alignment3.adb

[Bug ada/82127] New: [8 regression] gnat.dg/specs/constructor.ads FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 82127
   Summary: [8 regression] gnat.dg/specs/constructor.ads FAILs
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.12, ia64-suse-linux-gnu

Between 20170905 (r251718) and 20170906 (r251809),
gnat.dg/specs/constructor.ads
started to FAIL

FAIL: gnat.dg/specs/constructor.ads (internal compiler error)
FAIL: gnat.dg/specs/constructor.ads (test for excess errors)

Excess errors:
xgcc: internal compiler error: Segmentation Fault signal terminated program
gnat1
I'm seeing for 64-bit sparc only, but a similar failure occurs on IA-64, too,
which may or may not be related.

On SPARC, I have

$ gnat1 -quiet
-fRTS=/var/gcc/regression/trunk/11.4-gcc/build/sparc-sun-solaris2.11/sparcv9/libada
-m64 -mptr64 -mstack-bias -mno-v8plus -mcpu=v9
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gnat.dg/specs/constructor.ads -o
constructor.s

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
wi::divmod_internal (quotient=0x0, remainder_len=0x0, remainder=0x0, 
dividend_val=0x0, dividend_len=0, dividend_prec=0, 
divisor_val=, divisor_len=, 
divisor_prec=, sgn=, oflow=)
at /vol/gcc/src/hg/trunk/local/gcc/wide-int.cc:1728
1728   dividend_prec);

There is no further stacktrace.

1: x/i $pc
=> 0x12289fc :st  %g3, [ %fp + -436 ]
(gdb) p/x $g3
$1 = 0x4
(gdb) p/x $fp
$2 = 0x0

  Rainer

[Bug target/80781] Feature request: build option to use libc++ instead of libstdc++ for increased usability on Mac

[rjvbertin at gmail dot com]

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

--- Comment #9 from René J.V. Bertin  ---
redi at gcc dot gnu.org wrote on 20170517::08:56:33 re: "[Bug target/80781]
Feature request: build option to use libc++ instead of libstdc++ for increased
usability on Mac"

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

>> Meaning "that G++ will one day have this kind of support for libc++"? Is
>> there a timeline or something?
>
>No. Somebody has to do the work. It will get into GCC if somebody does the
>work, but not before then.

What's the most efficient way (recipe) to end up with a build dir in which one
can do incremental builds (= regular development)? The build script I've been
using until now doesn't allow this reliably, forcing me to go through the whole
3-pass build each time. With efficient I here mean both in time and in terms of
disk footprint.

I'd expect that one ought to be able to rebuild GCC x.y.z from its own sources
in a single pass because it's already proven to be able to do that, so is it
possible to create a clean 1-pass build directory, configure and build it to
develop smallish modifications to the driver like we're discussing here?

[Bug ada/82126] [8 regression] gnat.dg/alignment3.adb FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug ada/82126] New: [8 regression] gnat.dg/alignment3.adb FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 82126
   Summary: [8 regression] gnat.dg/alignment3.adb FAILs
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.12, ia64-suse-linux-gnu

Between 20170905 (r251718) and 20170906 (r251809), the gnat.dg/alignment3.adb
test began to FAIL

FAIL: gnat.dg/alignment3.adb (test for excess errors)

Excess errors:
alignment3.adb:30:49: warning: source alignment (1) < alignment of "Natural"
(4)

I'm seeing it on both 32 and 64-bit SPARC, according to gcc-testresults, the
test
also FAILs on IA-64.

  Rainer

[Bug testsuite/82120] FAIL: gcc.dg/tree-ssa/pr81588.c

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Doesn't cortex-a5 also force BRANCH_COST of 1?  If yes, you should fix up
logical_op_short_circuit tcl function.  If not, then I have no idea why that
happens.

[Bug testsuite/82120] FAIL: gcc.dg/tree-ssa/pr81588.c

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #5 from Christophe Lyon  ---
(In reply to Thomas Preud'homme from comment #3)
> I've tested it for a variety of Arm Cortex-M and Cortex-A cores and it
> either PASS or is marked as UNSUPPORTED so looks good to me, thanks.
> 

In my testing, Jakub's patch (r251806) indeed made the test UNSUPPORTED for
arm-none-eabi/--with-cpu=cortex-m3.

However, for arm-none-linux-gnueabihf --with-cpu=cortex-a5
--with-fpu=vfpv3-d16-fp16, I still have:
FAIL: gcc.dg/tree-ssa/pr81588.c scan-tree-dump-times reassoc1 "Optimizing range
test [^\n\r]* and comparison" 1

[Bug libgomp/82124] FAIL: libgomp.c++/pr69393.C (test for excess errors)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
I think this is a dup, the testcase uses -flto.

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

[Bug target/82005] [8 regression] early lto debug creates invalid assembly on Darwin

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #14 from Richard Biener  ---
*** Bug 82124 has been marked as a duplicate of this bug. ***

[Bug middle-end/82123] [7/8 regression] spurious -Wformat-overflow warning for converted vars

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |7.3
Summary|[7 regression] spurious |[7/8 regression] spurious
   |-Wformat-overflow warning   |-Wformat-overflow warning
   |for converted vars  |for converted vars
  Known to fail||7.1.1

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

[doko at gcc dot gnu.org]

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

--- Comment #19 from Matthias Klose  ---
Author: doko
Date: Thu Sep  7 07:17:17 2017
New Revision: 251829

URL: https://gcc.gnu.org/viewcvs?rev=251829=gcc=rev
Log:
2017-09-07  Matthias Klose  

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-5-branch/libsanitizer/ChangeLog
branches/gcc-5-branch/libsanitizer/sanitizer_common/sanitizer_linux.cc
branches/gcc-5-branch/libsanitizer/sanitizer_common/sanitizer_linux.h
   
branches/gcc-5-branch/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
branches/gcc-5-branch/libsanitizer/tsan/tsan_platform_linux.cc

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

[doko at gcc dot gnu.org]

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

--- Comment #18 from Matthias Klose  ---
Author: doko
Date: Thu Sep  7 07:15:24 2017
New Revision: 251828

URL: https://gcc.gnu.org/viewcvs?rev=251828=gcc=rev
Log:
2017-09-07  Matthias Klose  

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-6-branch/libsanitizer/ChangeLog
branches/gcc-6-branch/libsanitizer/sanitizer_common/sanitizer_linux.cc
branches/gcc-6-branch/libsanitizer/sanitizer_common/sanitizer_linux.h
   
branches/gcc-6-branch/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
branches/gcc-6-branch/libsanitizer/tsan/tsan_platform_linux.cc