[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-10
 CC||rguenth at gcc dot gnu.org
  Component|rtl-optimization|tree-optimization
Summary|missed optimisation |missed range optimisation
   |opportunity for derefences  |opportunity for derefences
   |where index must be 0   |where index must be 0 or
   ||otherwise constrained
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
There are still debuglto sections in the primary object file:

  3 .gnu.debuglto_.debug_info 0094     
026c  2**2
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA, EXCLUDE
  4 .gnu.debuglto_.debug_abbrev 002c     
0300  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA, EXCLUDE
  5 .gnu.debuglto_.debug_str      
  2**2
  ALLOC, LOAD, READONLY, DATA, EXCLUDE

[Bug c/85320] New: Segmentation fault when building XKAAPI

[jules at penuchot dot com]

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

Bug ID: 85320
   Summary: Segmentation fault when building XKAAPI
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jules at penuchot dot com
  Target Milestone: ---

I get a segmentation fault when I build XKAAPI ver. 3.1.1rc01 with GCC 7.2.0 on
Ubuntu 17.04 on a Dell XPS 13 (i7 6560U, 8GB RAM)

Here's the link to XKAAPI:
http://kaapi.gforge.inria.fr/

The link to the specific version:
https://gforge.inria.fr/frs/download.php/zip/10051/xkaapi-3.1.1rc01.zip

And there's the error message:

In file included from kaapi++:51:0,
 from ka_error.cpp:48:
kaapi++.h: In static member function ‘static const kaapi_format_t*
ka::WrapperFormat::get_c_format()’:
kaapi++.h:279:27: internal compiler error: Segmentation fault
 return format.Format::get_c_format();
   ^~~~

Just after these two lines:

/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I.
-I../..  -I../../src -I.   -Wall -g -O2  -std=c++0x -pedantic  -MT
libkaapi___la-ka_error.lo -MD -MP -MF .deps/libkaapi___la-ka_error.Tpo -c -o
libkaapi___la-ka_error.lo `test -f 'ka_error.cpp' || echo './'`ka_error.cpp

libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I../../src -I. -Wall -g -O2
-std=c++0x -pedantic -MT libkaapi___la-ka_error.lo -MD -MP -MF
.deps/libkaapi___la-ka_error.Tpo -c ka_error.cpp  -fPIC -DPIC -o
.libs/libkaapi___la-ka_error.o

[Bug fortran/85314] gcc/fortran/resolve.c:9222: unreachable code ?

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-10
 CC||kargl at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Revision r254241 has replaced

  if (ts->type == BT_DERIVED)

with

  if (ts->type == BT_DERIVED || ts->type == BT_CLASS)

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
So I guess for darwin we're confused by lto-wrapper.c:debug_objcopy using

  simple_object_read *inobj = simple_object_start_read (infd, inoff,
"__GNU_LTO",
, );
  if (!inobj)
return NULL;

  off_t off, len;
  if (simple_object_find_section (inobj, ".gnu.debuglto_.debug_info",
  , , , ) != 1)

which won't find the darwin early debug sections anyway and the effect of
the (still correct!) patch is to disable references to the early debug
section in the IL.

So we in additional to that require a target hook that can be queried
from dwarf2out_early_finish () to disable the output of the sections.
Or somehow query the simple-object capability there.

[Bug libstdc++/85319] New: std::char_traits::length does not always function in constexpr context

[v at vsamko dot com]

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

Bug ID: 85319
   Summary: std::char_traits::length does not always
function in constexpr context
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v at vsamko dot com
  Target Milestone: ---

This fails to compile with "error: non-constant condition for static assertion

 static_assert(std::char_traits::length(cstr) == 2);"

```
#include 
static constexpr char cstr[3] = {'1', '2', '\0'};

constexpr int foobar() {
static_assert(std::char_traits::length(cstr) == 2);
return 0;
}

int main() {}
```


But this compiles fine:
```
#include 
static constexpr char cstr[3] = {'1', '2', '\0'};

constexpr int foobar() {
return 0;
}

int main() { static_assert(std::char_traits::length(cstr) == 2); }
```

As well as this:
```
#include 
static constexpr char cstr[3] = {'1', '2', '\0'};

int foobar() {
static_assert(std::char_traits::length(cstr) == 2); 
return 0;
}

int main() { }
```

[Bug target/85173] ICE in in extract_insn, at recog.c:2304 for -fstack-clash-protection on ARM

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Fixed.

[Bug c++/78715] [concepts] Access specifiers ignored after concept declaration

[vopl at bk dot ru]

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

vopl at bk dot ru changed:

   What|Removed |Added

 CC||vopl at bk dot ru

--- Comment #2 from vopl at bk dot ru ---
affected versions at now:
6.1, 6.2, 6.3, 6.4, 7.1, 7.2, 7.3, 8.0.1-20180408

one more reproduce:

template
concept bool SomeConcept = true;

template 
void breaker(SomeConcept);

class SomeClass {
int privateMember;
};

int main() {
return SomeClass().privateMember;
}

[Bug tree-optimization/85286] [8 Regression] ICE in exact_div, at poly-int.h:2139

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Tue Apr 10 10:28:33 2018
New Revision: 259268

URL: https://gcc.gnu.org/viewcvs?rev=259268=gcc=rev
Log:
Add missing cases to vect_get_smallest_scalar_type (PR 85286)

In this PR we used WIDEN_SUM_EXPR to vectorise:

  short i, y;
  int sum;
  [...]
  for (i = x; i > 0; i--)
sum += y;

with 4 ints and 8 shorts per vector.  The problem was that we set
the VF based only on the ints, then calculated the number of vector
copies based on the shorts, giving 4/8.  Previously that led to
ncopies==0, but after r249897 we pick it up as an ICE.

In this particular case we could vectorise the reduction by setting
ncopies based on the output type rather than the input type, but it
doesn't seem worth adding a special "optimisation" for such a
pathological case.  I think it's really an instance of the more general
problem that we can't vectorise using combinations of (say) 64-bit and
128-bit vectors on targets that support both.

2018-04-10  Richard Sandiford  

gcc/
PR tree-optimization/85286
* tree-vect-data-refs.c (vect_get_smallest_scalar_type):

gcc/testsuite/
PR tree-optimization/85286
* gcc.dg/vect/pr85286.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr85286.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c

[Bug c++/85312] trunk/gcc/cp/parser.c:12041: poor error checking ?

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|x86-*-solaris2  |*-*-solaris2.11

--- Comment #76 from Rainer Orth  ---
Affects Solaris 11 only, but on both sparc and x86.

[Bug target/85173] ICE in in extract_insn, at recog.c:2304 for -fstack-clash-protection on ARM

[ktkachov at gcc dot gnu.org]

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

--- Comment #9 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Apr 10 09:58:57 2018
New Revision: 259266

URL: https://gcc.gnu.org/viewcvs?rev=259266=gcc=rev
Log:
[explow] PR target/85173: validize memory before passing it on to target
probe_stack

In this PR the expansion code emits an invalid memory address for the stack
probe, which the backend fails to recognise.
The address is created explicitly in anti_adjust_stack_and_probe_stack_clash in
explow.c and passed down to gen_probe_stack
without any validation in emit_stack_probe.

This patch fixes the ICE by calling validize_mem on the memory location before
passing it down to the target.
Jakub pointed out that we also want to create valid addresses for the
probe_stack_address case, so this patch
creates an expand operand and legitimizes it before passing it down to the
probe_stack_address expander.

This patch passes bootstrap and testing on arm-none-linux-gnueabihf and
aarch64-none-linux-gnu
and ppc64le-redhat-linux on gcc112 in the compile farm.

PR target/85173
* explow.c (emit_stack_probe): Call validize_mem on memory location
before passing it to gen_probe_stack.  Create address operand and
legitimize it for the probe_stack_address case.

* gcc.target/arm/pr85173.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr85173.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/explow.c
trunk/gcc/testsuite/ChangeLog

[Bug target/85075] powerpc: ICE in iszero testcase

[tuliom at linux dot ibm.com]

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

--- Comment #4 from Tulio Magno Quites Machado Filho  ---
(In reply to Ulrich Weigand from comment #3)
> Maybe I'm confused, but: How does this even build?

It does not. There is an ICE before the build error message appears.

> _Float128 is a C-only extension, this type is not supposed to be available
> at all in C++ mode as far as I know.

Replace _Float128 with __float128 and the ICE will continue there.

[Bug target/84490] [8 regression] 436.cactusADM regressed by 6-8% percent with -Ofast on Zen and Haswell, compared to gcc 7.2

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Actually r253993 was just the changelog part, r253975 was the actual change.

So I'm doing r254012 vs r254011 instead.

[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||meta-bug,
   ||missed-optimization
   Severity|normal  |enhancement

[Bug target/85317] New: missing constant propagation on _mm(256)_movemask_*

[kretz at kde dot org]

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

Bug ID: 85317
   Summary: missing constant propagation on _mm(256)_movemask_*
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---

The following test case shows that the movemask intrinsics are are a barrier
for constant propagation. All of these functions should have a trivial constant
return value.

#include 

// return 0:
int i0() { return _mm_movemask_epi8( __m128i()); }
int s0() { return _mm_movemask_ps  ( __m128 ()); }
int d0() { return _mm_movemask_pd  ( __m128d()); }
int I0() { return _mm256_movemask_epi8( __m256i()); }
int S0() { return _mm256_movemask_ps  ( __m256 ()); }
int D0() { return _mm256_movemask_pd  ( __m256d()); }

int x2 () { return _mm_movemask_pd ((__m128d)~__m128i()); } // return 0x3
int x4 () { return _mm_movemask_ps ((__m128 )~__m128i()); } // return 0xf
int x4_() { return _mm256_movemask_pd  ((__m256d)~__m256i()); } // return 0xf
int x8 () { return _mm256_movemask_ps  ((__m256 )~__m256i()); } // return 0xff
int x16() { return _mm_movemask_epi8   (~__m128i()); } // return 0x
int x32() { return _mm256_movemask_epi8(~__m256i()); } // return 0x

Clang supports the optimization at -O1: https://godbolt.org/g/e6CVmR

[Bug c/85318] New: -Wc90-c99-compat does not warn about for loop initial declarations

[ad...@tho-otto.de]

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

Bug ID: 85318
   Summary: -Wc90-c99-compat does not warn about for loop initial
declarations
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ad...@tho-otto.de
  Target Milestone: ---

When compiling code that uses for loop initial declarations with
-Wc90-c99-compat, no diagnostic is issued.

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
This doesn't seem to work:

(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) [answered Y; input not from terminal]
Starting program:
c:\home\botcazou\anod-wave\x86_64-windows\gcc-gcc-head\install\libexec\gcc\x86_64-pc-mingw32\8.0.1\cc1.exe
-quiet -v -iprefix
c:homebotcazouanod-wavex86_64-windowsgcc-gcc-headinstallbin../lib/gcc/x86_64-pc-mingw32/8.0.1/
t.c -quiet -dumpbase t.c "-mtune=generic" "-march=x86-64" -auxbase t -g
-version -flto -o C:tmpcc6RiDxZ.s
[New Thread 16284.0x1968]

Breakpoint 1, 0x00b4b4b0 in i386_pe_asm_lto_start() ()
(gdb) bt
#0  0x00b4b4b0 in i386_pe_asm_lto_start() ()
#1  0x005318bc in symbol_table::compile() [clone .part.74] ()
#2  0x005b in symbol_table::finalize_compilation_unit() ()
#3  0x0086b125 in compile_file() ()
#4  0x011a4ad3 in toplev::main(int, char**) ()
#5  0x011c5743 in main ()

$ gcc -o t t.c -flto -g 
lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not
implemented: Invalid argument

compilation terminated.
c:/home/botcazou/anod-wave/x86_64-windows/gcc-gcc-head/install/bin/../libexec/gcc/x86_64-pc-mingw32/8.0.1/ld.exe:
error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status

[Bug fortran/85313] gcc/fortran/openmp.c: 2 * confused logic ?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug fortran/85313] gcc/fortran/openmp.c: 2 * confused logic ?

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-10
 CC||tschwinge at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
The first block has been added at revision r136433 and the second one at
r219682.

[Bug sanitizer/84428] ==7122==AddressSanitizer CHECK failed: ../../../sanitizer/asan/asan_interceptors.cc:384 "((__interception::real___cxa_throw)) != (0)" (0x0, 0x0)

[ribasushi at leporine dot io]

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

--- Comment #23 from Peter Rabbitson  ---
Could you please link the upstream issue you are referring to?

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #5 from Eric Botcazou  ---
> Let's make sure we "fix" this.

I'm testing the Darwin-ish approach...

[Bug c++/78715] [concepts] Access specifiers ignored after concept declaration

[vopl at bk dot ru]

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

--- Comment #3 from vopl at bk dot ru ---
probably the same

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67225
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80962

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
Created attachment 43893
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43893=edit
Darwin-ish tentative fix

[Bug sanitizer/84428] ==7122==AddressSanitizer CHECK failed: ../../../sanitizer/asan/asan_interceptors.cc:384 "((__interception::real___cxa_throw)) != (0)" (0x0, 0x0)

[marxin at gcc dot gnu.org]

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

--- Comment #24 from Martin Liška  ---
(In reply to Peter Rabbitson from comment #23)
> Could you please link the upstream issue you are referring to?

It's written in URL of this bug, take a look at top of the page.

[Bug fortran/85307] Consistent handling of out-of-bounds access

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-10
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
> At the very least, the warnings about the parameter array should
> be hard errors, and possibly others as well.

Agreed!

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
(In reply to Eric Botcazou from comment #7)
> This doesn't seem to work:
> 
> (gdb) run
> The program being debugged has been started already.
> Start it from the beginning? (y or n) [answered Y; input not from terminal]
> Starting program:
> c:\home\botcazou\anod-wave\x86_64-windows\gcc-gcc-
> head\install\libexec\gcc\x86_64-pc-mingw32\8.0.1\cc1.exe -quiet -v -iprefix
> c:homebotcazouanod-wavex86_64-windowsgcc-gcc-headinstallbin../lib/gcc/x86_64-
> pc-mingw32/8.0.1/ t.c -quiet -dumpbase t.c "-mtune=generic" "-march=x86-64"
> -auxbase t -g -version -flto -o C:tmpcc6RiDxZ.s
> [New Thread 16284.0x1968]
> 
> Breakpoint 1, 0x00b4b4b0 in i386_pe_asm_lto_start() ()
> (gdb) bt
> #0  0x00b4b4b0 in i386_pe_asm_lto_start() ()
> #1  0x005318bc in symbol_table::compile() [clone .part.74] ()
> #2  0x005b in symbol_table::finalize_compilation_unit() ()
> #3  0x0086b125 in compile_file() ()
> #4  0x011a4ad3 in toplev::main(int, char**) ()
> #5  0x011c5743 in main ()
> 
> $ gcc -o t t.c -flto -g 
> lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not
> implemented: Invalid argument
> 
> compilation terminated.
> c:/home/botcazou/anod-wave/x86_64-windows/gcc-gcc-head/install/bin/../
> libexec/gcc/x86_64-pc-mingw32/8.0.1/ld.exe: error: lto-wrapper failed
> collect2.exe: error: ld returned 1 exit status

can you inspect the object file and see whether there's a
.gnu.debuglto_.debug_info section?  Or I guess more easily break in
dwarf2out_early_finish and see whether/why debug_info_level isn't properly
unset.

Ah, quite naturally this doesn't work as the early_finish hook is called
very much earlier...  I wonder why this works on darwin and if it has
additional bad side-effects there (disabling debug for the non-LTO path?)

[Bug target/84490] [8 regression] 436.cactusADM regressed by 6-8% percent with -Ofast on Zen and Haswell, compared to gcc 7.2

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
> Actually r253993 was just the changelog part, r253975 was the actual change.
> 
> So I'm doing r254012 vs r254011 instead.

Base = r254011, Peak = r254012

  Estimated   Estimated
Base Base   BasePeak Peak   Peak
Benchmarks  Ref.   Run Time Ratio   Ref.   Run Time Ratio
436.cactusADM   11950185   64.6 *   11950233   51.4 S
436.cactusADM   11950185   64.6 S   11950230   51.9 S
436.cactusADM   11950185   64.6 S   11950232   51.5 *

so confirmed.  Unsurprisingly:

 53.66%  cactusADM_peak.  cactusADM_peak.amd64-m64-gcc42-nn  [.]
bench_staggeredleapfrog2_  
 43.53%  cactusADM_base.  cactusADM_base.amd64-m64-gcc42-nn  [.]
bench_staggeredleapfrog2_ 

and the difference is that for the fast version we peel for alignment.  And
we're probably lucky in that we end up aligning all stores given they are

  do k = 2,nz-1
...
 do j=2,ny-1
do i=2,nx-1
...
   ADM_kxx_stag(i,j,k) = ADM_kxx_stag_p(i,j,k)+
 &  dkdt_dkxxdt*dt
...
   ADM_kxy_stag(i,j,k) = ADM_kxy_stag_p(i,j,k)+
 &  dkdt_dkxydt*dt
...
   ADM_kxz_stag(i,j,k) = ADM_kxz_stag_p(i,j,k)+
 &  dkdt_dkxzdt*dt
...
   ADM_kyy_stag(i,j,k) = ADM_kyy_stag_p(i,j,k)+
 &  dkdt_dkyydt*dt
...
   ADM_kyz_stag(i,j,k) = ADM_kyz_stag_p(i,j,k)+
 &  dkdt_dkyzdt*dt
...
   ADM_kzz_stag(i,j,k) = ADM_kzz_stag_p(i,j,k)+
 &  dkdt_dkzzdt*dt
end do
 end do
  end do

all arrays have the same shape (but that fact isn't exposed in the IL)
and assuming same alignment of the incoming pointers we could have
"guessed" we are actually aligning more than one store.

Both variants spill _a lot_ (but hopefully to aligned stack slots),
so we are most probably store-bound here (without actually verifying).

Disabling peeling for alignment on r254011 results in

436.cactusADM   11950207   57.7 *

so that's only half-way.  Disabling peeling for alignment on r254012 does
nothing (as expected).  So there's more than just peeling for alignment
here.

[Bug target/85075] powerpc: ICE in iszero testcase

[uweigand at gcc dot gnu.org]

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

--- Comment #3 from Ulrich Weigand  ---
Maybe I'm confused, but: How does this even build?

_Float128 is a C-only extension, this type is not supposed to be available at
all in C++ mode as far as I know.

[Bug c++/85312] trunk/gcc/cp/parser.c:12041: poor error checking ?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-10
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
This changed with r258803.  Yes, the error messages should be removed now.

[Bug tree-optimization/85286] [8 Regression] ICE in exact_div, at poly-int.h:2139

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Patch applied.

[Bug target/85295] ICE in extract_constrain_insn, at recog.c:2205

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed|2018-04-09 00:00:00 |2018-04-10
   Assignee|unassigned at gcc dot gnu.org  |krebbel at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Andreas Krebbel  ---
(In reply to Jakub Jelinek from comment #1)
> Shouldn't we just remove -mno-lra support for s390*?
> I mean, -mlra is the default on s390* already since GCC 4.9?, so the testing
> period must be over already.

If this can be fixed easily I would prefer to keep -mno-lra. It sometimes helps
when debugging lra problems. I'll try to have a look.

[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Note for
int x;

...
  *( + (a + b))
if x is common we need to take -funconstrained-commons into account, similarly
for vars that end with flexible array members or similar arrays.

[Bug tree-optimization/85316] New: [meta-bug] VRP range propagation missed cases

[rguenth at gcc dot gnu.org]

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

Bug ID: 85316
   Summary: [meta-bug] VRP range propagation missed cases
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

bug tracking all missed value range propagation issues (as opposed to PR18373
tracking the need for such a pass)

[Bug libgomp/85129] [openacc] Document GOMP_OPENACC_DIM

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-10
 Ever confirmed|0   |1

--- Comment #3 from Thomas Schwinge  ---
(In reply to Tom de Vries from comment #2)
> GOMP_OPENACC_DIM seems to be the odd one here, and we should document
> the non-standard behaviour that it supports being set in main using setenv.

Amongst other things, in
 I
wondered whether "GOMP_OPENACC_DIM parsing conceptually belongs into generic
libgomp code, instead of the nvptx plugin.  (But [...] currently, the nvptx
plugin is the only one supporting/using it.)".

So, I'm not sure we should really document now and thus set the expectation
that 'setenv("GOMP_OPENACC_DIM")' will continue to work as it does now.

[Bug target/85323] SSE/AVX/AVX512 shift by 0 not optimized away

[kretz at kde dot org]

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

--- Comment #1 from Matthias Kretz  ---
Created attachment 43898
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43898=edit
idea for a partial solution

Constant propagation works using the built in shift operators. At least for the
shifts taking a "const int" shift argument, this is a possible fix. However,
the patched intrinsics now accept non-immediate shift arguments, which modifies
the interface (in an unsafe way).

[Bug fortran/85313] gcc/fortran/openmp.c: 2 * confused logic ?

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 10 14:04:37 2018
New Revision: 259275

URL: https://gcc.gnu.org/viewcvs?rev=259275=gcc=rev
Log:
PR fortran/85313
* openmp.c (resolve_omp_do): Remove bogus if (j < i) break;.
(resolve_oacc_nested_loops): Likewise.  Formatting fix.

* gfortran.dg/gomp/pr85313.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr85313.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/65821] [6/7/8 regression] incorrect debug line # info for main

[jason at gcc dot gnu.org]

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

--- Comment #13 from Jason Merrill  ---
Author: jason
Date: Tue Apr 10 14:24:00 2018
New Revision: 259278

URL: https://gcc.gnu.org/viewcvs?rev=259278=gcc=rev
Log:
PR debug/65821 - wrong location for main().

* call.c (clear_location_r): New.
(convert_default_arg): Use it.
* tree.c (bot_manip): Remove builtin_LINE/FILE handling.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/default-arg1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/tree.c

[Bug debug/65821] [6/7 regression] incorrect debug line # info for main

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[6/7/8 regression]  |[6/7 regression] incorrect
   |incorrect debug line # info |debug line # info for main
   |for main|

--- Comment #14 from Jason Merrill  ---
Fixed for GCC 8.  I'm reluctant to backport this sort of change in behavior.

[Bug c++/85285] [6/7/8 Regression] ICE with flexible array in union

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue Apr 10 14:23:54 2018
New Revision: 259277

URL: https://gcc.gnu.org/viewcvs?rev=259277=gcc=rev
Log:
PR c++/85285 - ICE with flexible array after substitution.

* pt.c (instantiate_class_template_1): Check for flexible array in
union.

Added:
trunk/gcc/testsuite/g++.dg/ext/flexary30.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug bootstrap/85322] [8 Regression] profiledbootstrap failured

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Jakub Jelinek  ---
Please retry with r259274, I think this should be already fixed.

[Bug target/85324] New: missing constant propagation on SSE/AVX conversion intrinsics

[kretz at kde dot org]

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

Bug ID: 85324
   Summary: missing constant propagation on SSE/AVX conversion
intrinsics
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---

The following test case shows that constant propagation through conversion
intrinsics does not work:

#include 

template  using V [[gnu::vector_size(16)]] = T;

// missed optimization:
auto a1() { return 1 + (V<  int>)_mm_cvttps_epi32(_mm_set1_ps(1.f)); }
auto b1() { return 1 + (V< long>)_mm_cvttps_epi64(_mm_set1_ps(1.f)); }
auto c1() { return 1 + (V<  int>)_mm_cvttpd_epi32(_mm_set1_pd(1.)); }
auto d1() { return 1 + (V< long>)_mm_cvttpd_epi64(_mm_set1_pd(1.)); }
auto e1() { return 1 + (V)_mm_cvtepi32_epi16(_mm_set1_epi32(1)); }

The resulting asm is (`-O3 -march=skylake-avx512 -std=c++17`):
a1():
  vcvttps2dq .LC0(%rip), %xmm0
  vpaddd %xmm0, %xmm0, %xmm0
  ret
b1():
  vcvttps2qq .LC0(%rip), %xmm0
  vpaddq %xmm0, %xmm0, %xmm0
  ret
c1():
  vmovdqa64 .LC1(%rip), %xmm0
  vcvttpd2dqx .LC5(%rip), %xmm1
  vpaddd %xmm0, %xmm1, %xmm0
  ret
d1():
  vcvttpd2qq .LC5(%rip), %xmm0
  vpaddq %xmm0, %xmm0, %xmm0
  ret
e1():
  vmovdqa64 .LC7(%rip), %xmm1
  vmovdqa64 .LC1(%rip), %xmm0
  vpmovdw %xmm0, %xmm0
  vpaddw %xmm1, %xmm0, %xmm0
  ret

It should be a single load of a constant in each function. (A wrapper using
__builtin_constant_p can work around it; cf. https://godbolt.org/g/8dta7B)

[Bug ipa/85051] [6/7/8 Regression] ICE: in edge_badness, at ipa-inline.c:1035 with flattening recursive calls

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
This time it's probably not a round off:

(gdb) p callee_info->time
$1 = {m_sig = 1174405118, m_exp = -25}
(gdb) p callee_info->time.to_double()
$2 = 34.99940395355
(gdb) p edge_time.to_double()
$3 = 54.9988079071

[Bug target/85321] Missing documentation and option misc for ppc64le

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Target|powerpc64le |powerpc*-*-*
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org

[Bug target/85323] New: SSE/AVX/AVX512 shift by 0 not optimized away

[kretz at kde dot org]

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

Bug ID: 85323
   Summary: SSE/AVX/AVX512 shift by 0 not optimized away
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---

In the following test case, all three functions should compile to just `ret`:

#include 

__m128i f(__m128i x) {
x = _mm_sll_epi64(x, __m128i());
x = _mm_sll_epi32(x, __m128i());
x = _mm_sll_epi16(x, __m128i());
x = _mm_srl_epi64(x, __m128i());
x = _mm_srl_epi32(x, __m128i());
x = _mm_srl_epi16(x, __m128i());
x = _mm_sra_epi64(x, __m128i());
x = _mm_sra_epi32(x, __m128i());
x = _mm_sra_epi16(x, __m128i());
x = _mm_slli_epi64(x, 0);
x = _mm_slli_epi32(x, 0);
x = _mm_slli_epi16(x, 0);
x = _mm_srli_epi64(x, 0);
x = _mm_srli_epi32(x, 0);
x = _mm_srli_epi16(x, 0);
x = _mm_srai_epi64(x, 0);
x = _mm_srai_epi32(x, 0);
x = _mm_srai_epi16(x, 0);
return x;
}

__m256i f(__m256i x) {
x = _mm256_sll_epi64(x, __m128i());
x = _mm256_sll_epi32(x, __m128i());
x = _mm256_sll_epi16(x, __m128i());
x = _mm256_srl_epi64(x, __m128i());
x = _mm256_srl_epi32(x, __m128i());
x = _mm256_srl_epi16(x, __m128i());
x = _mm256_sra_epi64(x, __m128i());
x = _mm256_sra_epi32(x, __m128i());
x = _mm256_sra_epi16(x, __m128i());
x = _mm256_slli_epi64(x, 0);
x = _mm256_slli_epi32(x, 0);
x = _mm256_slli_epi16(x, 0);
x = _mm256_srli_epi64(x, 0);
x = _mm256_srli_epi32(x, 0);
x = _mm256_srli_epi16(x, 0);
x = _mm256_srai_epi64(x, 0);
x = _mm256_srai_epi32(x, 0);
x = _mm256_srai_epi16(x, 0);
return x;
}

__m512i f(__m512i x) {
x = _mm512_sll_epi64(x, __m128i());
x = _mm512_sll_epi32(x, __m128i());
x = _mm512_sll_epi16(x, __m128i());
x = _mm512_srl_epi64(x, __m128i());
x = _mm512_srl_epi32(x, __m128i());
x = _mm512_srl_epi16(x, __m128i());
x = _mm512_sra_epi64(x, __m128i());
x = _mm512_sra_epi32(x, __m128i());
x = _mm512_sra_epi16(x, __m128i());
x = _mm512_slli_epi64(x, 0);
x = _mm512_slli_epi32(x, 0);
x = _mm512_slli_epi16(x, 0);
x = _mm512_srli_epi64(x, 0);
x = _mm512_srli_epi32(x, 0);
x = _mm512_srli_epi16(x, 0);
x = _mm512_srai_epi64(x, 0);
x = _mm512_srai_epi32(x, 0);
x = _mm512_srai_epi16(x, 0);
return x;
}

[Bug target/84748] [6/7 Regression] wrong code with u128 at aarch64 at -O and and above

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Apr 10 13:05:24 2018
New Revision: 259271

URL: https://gcc.gnu.org/viewcvs?rev=259271=gcc=rev
Log:
[AArch64] PR target/84748: Mark *compare_cstore_insn as clobbering CC reg

Backport from mainline
2018-03-08  Kyrylo Tkachov  

PR target/84748
* config/aarch64/aarch64.md (*compare_cstore_insn): Mark pattern
as clobbering CC_REGNUM.

* gcc.c-torture/execute/pr84748.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.c-torture/execute/pr84748.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/aarch64/aarch64.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/58479] [6/7/8 Regression] slow var-tracking on x86_64-linux at -O1 (and above) with -g, but checking disabled

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Even with LVUs if I try the #c0 testcase with outer 3 loops commented out (so
only 8x8 unrolling) and with a single dimension array rather than 3 dimensional
one, i.e.:
int d, e, f;

int
main ()
{
  for (d = 0; d < 8; d++)
for (e = 0; e < 8; e++)
  {
int t[9] = { f, f, f, f, f, f, f, f, f};
  }
  return 0;
}

we still don't emit any location info for t, even when it is in *.final dump:
(note 735 734 807 2 pr58479-4.c:12 NOTE_INSN_BEGIN_STMT)
(note 807 735 808 2 (var_location t$0 (mem/c:SI (symbol_ref:DI ("f") [flags
0x2] ) [1 f+0 S4 A32])) NOTE_INSN_VAR_LOCATION)
(note 808 807 809 2 (var_location t$1 (mem/c:SI (symbol_ref:DI ("f") [flags
0x2] ) [1 f+0 S4 A32])) NOTE_INSN_VAR_LOCATION)
(note 809 808 810 2 (var_location t$2 (mem/c:SI (symbol_ref:DI ("f") [flags
0x2] ) [1 f+0 S4 A32])) NOTE_INSN_VAR_LOCATION)
(note 810 809 811 2 (var_location t$3 (mem/c:SI (symbol_ref:DI ("f") [flags
0x2] ) [1 f+0 S4 A32])) NOTE_INSN_VAR_LOCATION)
(note 811 810 812 2 (var_location t$4 (mem/c:SI (symbol_ref:DI ("f") [flags
0x2] ) [1 f+0 S4 A32])) NOTE_INSN_VAR_LOCATION)
(note 812 811 813 2 (var_location t$5 (mem/c:SI (symbol_ref:DI ("f") [flags
0x2] ) [1 f+0 S4 A32])) NOTE_INSN_VAR_LOCATION)
(note 813 812 814 2 (var_location t$6 (mem/c:SI (symbol_ref:DI ("f") [flags
0x2] ) [1 f+0 S4 A32])) NOTE_INSN_VAR_LOCATION)
(note 814 813 736 2 (var_location t$7 (mem/c:SI (symbol_ref:DI ("f") [flags
0x2] ) [1 f+0 S4 A32])) NOTE_INSN_VAR_LOCATION)

So unless that changes, not really sure if it is actually worth preserving the
debug stmts at all.  I guess we don't do that because there is no real
instruction that is in the scope where the variable is defined and the
NOTE_INSN_BEGIN_STMTs don't really count (but shouldn't they?).

Alex, can you please have a look?

[Bug target/85323] SSE/AVX/AVX512 shift by 0 not optimized away

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-10
 CC||hjl.tools at gmail dot com,
   ||itsimbal at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||jkoval at gcc dot gnu.org,
   ||kyukhin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
The builtins have different behavior from the C shifts on vectors, where shift
counts < 0 or >= element bitsize are just undefined.

What the i386 backend could do (and should do) is extend ix86_fold_builtin
and/or ix86_gimple_fold_builtin to optimize these builtins.

For the shifts in particular, if the shift count (treated as unsigned) is equal
to the element size or larger, return a zero vector, and if it is 0, return the
first operand, or if first argument is VECTOR_CST and second argument is
INTEGER_CST, compute it into VECTOR_CST.  Similarly for VECTOR_CST second
operand, handle the VECTOR_CST, VECTOR_CST operands, or when all elts of the
latter one are equal, or all are >= element size.  Many other MD builtins
should be folded too.

[Bug c++/85285] [6/7/8 Regression] ICE with flexible array in union

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed for GCC 8.

[Bug c++/85279] [6/7 Regression] Broken diagnostic for decltype

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue Apr 10 14:29:52 2018
New Revision: 259280

URL: https://gcc.gnu.org/viewcvs?rev=259280=gcc=rev
Log:
PR c++/85279 - dump_expr doesn't understand decltype.

* error.c (dump_expr): Handle DECLTYPE_TYPE.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/decltype67.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/error.c

[Bug c++/85262] [6/7/8 Regression] Trouble with constructor and -fpermissive

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed for GCC 8.

[Bug target/85321] Missing documentation and option misc for ppc64le

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-10
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
(In reply to Martin Liška from comment #0)
> -mblock-compare-inline-limit - option not documented in manual
> -mblock-compare-inline-loop-limit - likewise
> -mstring-compare-inline-limit - not documented

Aaron is looking into this.

> -mcall-* - possible values are not listed in --help=target

Those are only handled in specs, and different per sub-target.

> -mfpu= - likewise

This will be removed in GCC 9.

> -mlong-double- - likewise

  -mlong-double-   Specify size of long double (64 or 128 bits).

Is there something nicer we can do here?

> -msdata= - likewise

Ack.

> -mtls-size= - possible values are not listed in --help=target

Ack.

> -mtraceback= - likewise + documentation entry is missing

  -mtraceback=Select full, part, or no traceback table.

Suggestions for rephrasing?  Ack for doc.

[Bug c++/85110] Missing underlines for some bad arguments

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Tue Apr 10 14:37:09 2018
New Revision: 259282

URL: https://gcc.gnu.org/viewcvs?rev=259282=gcc=rev
Log:
Show pertinent parameter (PR c++/85110)

gcc/cp/ChangeLog:
PR c++/85110
* call.c (get_fndecl_argument_location): Make non-static.
* cp-tree.h (get_fndecl_argument_location): New decl.
* typeck.c (convert_for_assignment): When complaining due to
conversions for an argument, show the location of the parameter
within the decl.

gcc/testsuite/ChangeLog:
PR c++/85110
* g++.dg/cpp1z/direct-enum-init1.C: Update for the cases
where we now show the pertinent parameter.
* g++.dg/diagnostic/aka2.C: Likewise.
* g++.dg/diagnostic/param-type-mismatch-2.C: Likewise.


Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp1z/direct-enum-init1.C
trunk/gcc/testsuite/g++.dg/diagnostic/aka2.C
trunk/gcc/testsuite/g++.dg/diagnostic/param-type-mismatch-2.C

[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
A simpler test case that shows the same optimization opportunity is:

  int f (int i)
  {
extern int x;
int y;
return  + i == 
  }

A test case that both Clang and GCC get wrong is below.  (This will be
discussed at the next WG14 meeting -- see
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n.htm#q23-can-one-do-comparison-between-pointers-to-objects-of-compatible-types-with-different-provenances-that-are-not-strictly-within-their-original-allocations)

  int g (int i)
  {
int x, y, z;

int *p =  + i;
int *q = 

return p == q;
  }

[Bug c++/24314] Extra "template<>" in partial specialization is compiled successfuly.

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #8 from Jason Merrill  ---
Fixed by patch for bug 85264.

[Bug ipa/85051] [6/7/8 Regression] ICE: in edge_badness, at ipa-inline.c:1035 with flattening recursive calls

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Honza, could you please have a look once you are done with the P1s?

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[redi at gcc dot gnu.org]

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

--- Comment #36 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #35)
> I have opened a new bug for the ABI regression.

That's PR 85222 and is now fixed on trunk, so comment 32 works again.

[Bug target/85321] New: Missing documentation and option misc for ppc64le

[marxin at gcc dot gnu.org]

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

Bug ID: 85321
   Summary: Missing documentation and option misc for ppc64le
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---

I've noticed following:

-mblock-compare-inline-limit - option not documented in manual
-mblock-compare-inline-loop-limit - likewise
-mcall-* - possible values are not listed in --help=target
-mfpu= - likewise
-mlong-double- - likewise
-msdata= - likewise
-mstring-compare-inline-limit - not documented
-mtls-size= - possible values are not listed in --help=target
-mtraceback= - likewise + documentation entry is missing

[Bug target/84748] wrong code with u128 at aarch64 at -O and and above

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|8.0 |6.5
Summary|[6/7 Regression] wrong code |wrong code with u128 at
   |with u128 at aarch64 at -O  |aarch64 at -O and and above
   |and and above   |

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Fixed on all active branches.

[Bug lto/85248] [6/7 Regression] Miscompilation when using error function that returns

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
Author: marxin
Date: Tue Apr 10 13:52:23 2018
New Revision: 259274

URL: https://gcc.gnu.org/viewcvs?rev=259274=gcc=rev
Log:
Fix obvious error in handling of error attribute (PR lto/85248).

2018-04-10  Martin Liska  

PR lto/85248
* lto-symtab.c (lto_symtab_merge_p): Do not check for
TREE_VALUES of error attributes.

Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-symtab.c

[Bug c++/85312] trunk/gcc/cp/parser.c:12041: poor error checking ?

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 10 14:28:54 2018
New Revision: 259279

URL: https://gcc.gnu.org/viewcvs?rev=259279=gcc=rev
Log:
PR c++/85312 - P0962 cleanup
* parser.c (cp_parser_perform_range_for_lookup): Remove unreachable
diagnostics.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c

[Bug tree-optimization/81184] [8 regression] gcc.dg/pr21643.c and gcc.dg/tree-ssa/phi-opt-11.c fail starting with r249450

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu.org

--- Comment #9 from Andreas Krebbel  ---
Is this really fixed for Power64. At least on s390 I still these testcases
failing.
I had a look into phi-opt-11.c.

No IF statements remain although LOGICAL_OP_NON_SHORT_CIRCUIT is not
defined on S/390 and hence defaults to true when using
-mbranch-cost=2.

The testcase appears to expect 2 IFs to remain for function
h. However, these get removed phiopt1.

This code turns the TRUTH_ANDIF_EXPR condition into a TRUTH_AND_EXPR:

fold-const.c:8178

  if (LOGICAL_OP_NON_SHORT_CIRCUIT
  && !flag_sanitize_coverage
  && (code == TRUTH_AND_EXPR
  || code == TRUTH_ANDIF_EXPR
  || code == TRUTH_OR_EXPR
  || code == TRUTH_ORIF_EXPR))
{
  enum tree_code ncode, icode;

  ncode = (code == TRUTH_ANDIF_EXPR || code == TRUTH_AND_EXPR)
  ? TRUTH_AND_EXPR : TRUTH_OR_EXPR;
  icode = ncode == TRUTH_AND_EXPR ? TRUTH_ANDIF_EXPR : TRUTH_ORIF_EXPR;
...

  /* Transform (A AND-IF B) into (A AND B), or (A OR-IF B)
 into (A OR B).
 For sequence point consistancy, we need to check for trapping,
 and side-effects.  */
  else if (code == icode && simple_operand_p_2 (arg0)
   && simple_operand_p_2 (arg1))
return fold_build2_loc (loc, ncode, type, arg0, arg1);


This prevents the gimplifier from splitting the condition into two
separate IF statements. Instead the truth value gets computed:

004t.gimple

h (int a, int b, int c, int d)
{
  int D.2246;

  _1 = a == d;
  _2 = b > c;
  _3 = _1 & _2;
  if (_3 != 0) goto ; else goto ;
  :
  D.2246 = d;
  // predicted unlikely by early return (on trees) predictor.
  return D.2246;
  :
  D.2246 = a;
  return D.2246;
}

which eventually gets optimized in phiop1 to:

Removing basic block 3
;; basic block 3, loop depth 0
;;  pred:   2
;;  succ:   4


COND_EXPR in block 2 and PHI in block 4 converted to straightline code.
Merging blocks 2 and 4
fix_loop_structure: fixing up loops for function
h (int a, int b, int c, int d)
{
  _Bool _1;
  _Bool _2;
  _Bool _3;

   [local count: 1073741825]:
  _1 = a_5(D) == d_6(D);
  _2 = b_7(D) > c_8(D);
  _3 = _1 & _2;
  return a_5(D);
}

No IFs.

[Bug target/84490] [8 regression] 436.cactusADM regressed by 6-8% percent with -Ofast on Zen and Haswell, compared to gcc 7.2

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Created attachment 43896
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43896=edit
r254011 with peeling disabled

The other differences look like RA/scheduling in the end the stack frame in the
new rev. is 32 bytes larger (up from $4800 to $4832).  Disabling the 2nd
scheduling pass doesn't have any nice effects btw.

All the spills in the code certainly makes for bad code so I'm not sure that
trying to fix things by re-introducing the peeling for alignment somehow
makes most sense...

Looking for an opportunity to distribute the loop might make more sense,
eventually more explicitely "spilling" shared intermediate results to
memory in distribution.  The source is quite unwieldly and dependences
are not obvious here.

[Bug target/85255] [8 Regression] wrong code with -O2 -fno-tree-fre -mavx512f

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 10 12:37:36 2018
New Revision: 259269

URL: https://gcc.gnu.org/viewcvs?rev=259269=gcc=rev
Log:
PR target/85177
PR target/85255
* config/i386/sse.md
(_vinsert_mask): Fix
computation of the VEC_MERGE selector from mask.
(_vinsert_1):
Fix decoding of the VEC_MERGE selector into mask.

* gcc.target/i386/avx512f-pr85177.c: New test.
* gcc.target/i386/avx512f-pr85255.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr85177.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr85255.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug target/85177] [8 Regression] wrong code with -O -fno-tree-ccp -fno-tree-sra -mavx512f

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/85177] [8 Regression] wrong code with -O -fno-tree-ccp -fno-tree-sra -mavx512f

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 10 12:37:36 2018
New Revision: 259269

URL: https://gcc.gnu.org/viewcvs?rev=259269=gcc=rev
Log:
PR target/85177
PR target/85255
* config/i386/sse.md
(_vinsert_mask): Fix
computation of the VEC_MERGE selector from mask.
(_vinsert_1):
Fix decoding of the VEC_MERGE selector into mask.

* gcc.target/i386/avx512f-pr85177.c: New test.
* gcc.target/i386/avx512f-pr85255.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr85177.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr85255.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug target/85204] [nvptx] infinite loop generated

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openacc
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-10
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug bootstrap/85322] New: [8 Regression] profiledbootstrap failured

[hjl.tools at gmail dot com]

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

Bug ID: 85322
   Summary: [8 Regression] profiledbootstrap failured
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On x86-64, r259265 failed to profiledbootstrap:

lto1: internal compiler error: Segmentation fault
0xe8226b crash_signal
../../src-trunk/gcc/toplev.c:325
0x7eccdc tree_check(tree_node*, char const*, int, char const*, tree_code)
../../src-trunk/gcc/tree.h:3134
0x81ab27 lto_symtab_merge_p
../../src-trunk/gcc/lto/lto-symtab.c:610
0x81ad47 lto_symtab_merge_decls_2
../../src-trunk/gcc/lto/lto-symtab.c:664
0x81b8e8 lto_symtab_merge_decls_1
../../src-trunk/gcc/lto/lto-symtab.c:867
0x81b9b0 lto_symtab_merge_decls()
../../src-trunk/gcc/lto/lto-symtab.c:890
0x7ff519 read_cgraph_and_symbols
../../src-trunk/gcc/lto/lto.c:2935
0x80020e lto_main()
../../src-trunk/gcc/lto/lto.c:3356
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error:
/export/gnu/import/git/gcc-test-profiled/bld/./prev-gcc/xg++ returned 1 exit
status
compilation terminated.
/usr/local/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[6]: *** [Makefile:2869: build/genhooks] Error 1
make[6]: *** Waiting for unfinished jobs
../../src-trunk/gcc/fortran/gfortran.texi:2701: warning: @ref node name should
not contain `:'
rm fsf-funding.pod gcov.pod gpl.pod cpp.pod gfdl.pod gfortran.pod gcc.pod
gcov-dump.pod gcov-tool.pod
make[6]: Leaving directory '/export/gnu/import/git/gcc-test-profiled/bld/gcc'
make[5]: *** [Makefile:4779: all-stageprofile-gcc] Error 2
make[5]: Leaving directory '/export/gnu/import/git/gcc-test-profiled/bld'
make[4]: *** [Makefile:24115: stageprofile-bubble] Error 2
make[4]: Leaving directory '/export/gnu/import/git/gcc-test-profiled/bld'
make[3]: *** [Makefile:24369: profiledbootstrap] Error 2

when configured with

 --with-build-config=bootstrap-lto --disable-werror

[Bug c++/24314] Extra "template<>" in partial specialization is compiled successfuly.

[paolo at gcc dot gnu.org]

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

--- Comment #9 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Apr 10 13:40:35 2018
New Revision: 259273

URL: https://gcc.gnu.org/viewcvs?rev=259273=gcc=rev
Log:
2018-04-10  Paolo Carlini  

PR c++/24314
* g++.dg/parse/template29.C: New.

Added:
trunk/gcc/testsuite/g++.dg/parse/template29.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/85313] gcc/fortran/openmp.c: 2 * confused logic ?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/85080] [8 regression] gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c fails starting with r248678

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
I'll see if I can make time to look at this one soon.  I suspect the new
peeling costs check from Robin just made this test invalid.

[Bug target/84748] [6/7 Regression] wrong code with u128 at aarch64 at -O and and above

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Apr 10 12:59:08 2018
New Revision: 259270

URL: https://gcc.gnu.org/viewcvs?rev=259270=gcc=rev
Log:
[AArch64] PR target/84748: Mark *compare_cstore_insn as clobbering CC reg

Backport from mainline
2018-03-08  Kyrylo Tkachov  

PR target/84748
* config/aarch64/aarch64.md (*compare_cstore_insn): Mark pattern
as clobbering CC_REGNUM.

* gcc.c-torture/execute/pr84748.c: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/execute/pr84748.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/aarch64/aarch64.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/85110] Missing underlines for some bad arguments

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #6 from David Malcolm  ---
Fixed as of r259282.

[Bug target/84490] [8 regression] 436.cactusADM regressed by 6-8% percent with -Ofast on Zen and Haswell, compared to gcc 7.2

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Created attachment 43897
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43897=edit
r254012 with peeling disabled

[Bug c/85320] Segmentation fault when building XKAAPI

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Please attach the preprocessed source, see http://gcc.gnu.org/bugs for details.

[Bug testsuite/85190] [8 Regression] gcc.dg/vect/pr81196.c FAILs

[amker at gcc dot gnu.org]

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

--- Comment #8 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Apr 10 13:11:40 2018
New Revision: 259272

URL: https://gcc.gnu.org/viewcvs?rev=259272=gcc=rev
Log:
gcc/testsuite
PR testsuite/85190
* gcc.dg/vect/pr81196.c: Adjust pointer for aligned access.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr81196.c

[Bug c++/85312] trunk/gcc/cp/parser.c:12041: poor error checking ?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug ipa/85103] [8 Regression] Performance regressions on SPEC with r257582

[pthaugen at gcc dot gnu.org]

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

--- Comment #5 from Pat Haugen  ---
A little more detail. 48t.fnsplit splits mainGtU() into 2 functions:

mainGtU(): which contains a few early exit tests and then a call to
mainGtU.part.0()

mainGtU.part.0(): contains the remainder of mainGtU(), including the loop


Following is then the behavior in 79i.inline:

r257581: The 3 mainGtU() calls are inlined into their caller mainSimpleSort(),
and the mainGtU.part.0() calls remain.

r257582: mainGtU.part.0() is inlined back into mainGtU(), the first mainGtU()
call in mainSimpleSort() is inlined but the remaining 2 mainGtU() calls remain.

[Bug rtl-optimization/85300] [6/7 Regression] ICE in exact_int_to_float_conversion_p, at simplify-rtx.c:895

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE in   |[6/7 Regression] ICE in
   |exact_int_to_float_conversi |exact_int_to_float_conversi
   |on_p, at simplify-rtx.c:895 |on_p, at simplify-rtx.c:895

--- Comment #8 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/85325] New: ICE on class template partial specialization for c++17

[jpelletier at jumptrading dot com]

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

Bug ID: 85325
   Summary: ICE on class template partial specialization for c++17
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpelletier at jumptrading dot com
  Target Milestone: ---

Created attachment 43899
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43899=edit
sample code

The attached code results in an ICE when compiled with --std=c++17, but works
fine for --std=c++14. Also changing U to just a typename compiles fine for
both.

output:

% g++ --std=c++17 test.cpp 12:05:25
test.cpp:8:44: internal compiler error: Segmentation fault
 struct X
^~
0xaa68af crash_signal
../../gcc/toplev.c:337
0x5dc5bd tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:13479
0x5db06a unify
../../gcc/cp/pt.c:20586
0x5da608 unify
../../gcc/cp/pt.c:20764
0x5db747 coerce_template_template_parms
../../gcc/cp/pt.c:7162
0x5e9eea convert_template_argument
../../gcc/cp/pt.c:7566
0x5eb1dc coerce_template_parms
../../gcc/cp/pt.c:8128
0x5eda60 lookup_template_class_1
../../gcc/cp/pt.c:8664
0x5eda60 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:9009
0x68399d finish_template_type(tree_node*, tree_node*, int)
../../gcc/cp/semantics.c:3151
0x632c54 cp_parser_template_id
../../gcc/cp/parser.c:15495
0x632d9f cp_parser_class_name
../../gcc/cp/parser.c:21953
0x642726 cp_parser_qualifying_entity
../../gcc/cp/parser.c:6286
0x642726 cp_parser_nested_name_specifier_opt
../../gcc/cp/parser.c:5972
0x638675 cp_parser_class_head
../../gcc/cp/parser.c:22440
0x638675 cp_parser_class_specifier_1
../../gcc/cp/parser.c:22037
0x639c91 cp_parser_class_specifier
../../gcc/cp/parser.c:22350
0x639c91 cp_parser_type_specifier
../../gcc/cp/parser.c:16423
0x6489ea cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:13330
0x636f3b cp_parser_single_declaration
../../gcc/cp/parser.c:26629
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug ipa/85103] [8 Regression] Performance regressions on SPEC with r257582

[pthaugen at gcc dot gnu.org]

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

--- Comment #7 from Pat Haugen  ---
Created attachment 43901
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43901=edit
inline dump

Prior attachment was r257581 dump. This is r257582 dump.

[Bug c/85320] Segmentation fault when building XKAAPI

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-04-10
 Ever confirmed|0   |1

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

[Bug c++/85311] const& aggregate parameter with empty default brace initializer results in undefined references to std containers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Already reported and already fixed.

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

[Bug c++/82336] [6 Regression] GCC requires but does not emit defaulted constructors in certain cases

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||vis...@royal-caliber.com

--- Comment #8 from Jonathan Wakely  ---
*** Bug 85311 has been marked as a duplicate of this bug. ***

[Bug libstdc++/85222] [7/8 Regression] ABI breakage of __throw_ios_failure by r244498

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely  ---
Author: redi
Date: Tue Apr 10 14:36:09 2018
New Revision: 259281

URL: https://gcc.gnu.org/viewcvs?rev=259281=gcc=rev
Log:
PR libstdc++/85222 allow catching iostream errors as gcc4-compatible
ios::failure

Define a new exception type derived from std::ios::failure[abi:cxx11]
which also aggregates an object of the gcc4-compatible ios::failure
type. Make __throw_ios_failure throw this new type for iostream errors
that raise exceptions. Provide custom type info for the new type so that
it can be caught by handlers for the gcc4-compatible ios::failure type
as well as handlers for ios::failure[abi:cxx11] and its bases.

PR libstdc++/85222
* src/c++11/Makefile.am [ENABLE_DUAL_ABI]: Add special rules for
cxx11-ios_failure.cc to rewrite type info for __ios_failure.
* src/c++11/Makefile.in: Regenerate.
* src/c++11/cxx11-ios_failure.cc (__ios_failure, __iosfail_type_info):
New types.
[_GLIBCXX_USE_DUAL_ABI] (__throw_ios_failure): Define here.
* src/c++11/ios.cc (__throw_ios_failure): Remove definition.
* src/c++98/ios_failure.cc (__construct_ios_failure)
(__destroy_ios_failure, is_ios_failure_handler): New functions.
[!_GLIBCXX_USE_DUAL_ABI] (__throw_ios_failure): Define here.
* testsuite/27_io/ios_base/failure/dual_abi.cc: New.
* testsuite/27_io/basic_ios/copyfmt/char/1.cc: Revert changes to
handler types, to always catch std::ios_base::failure.
* testsuite/27_io/basic_ios/exceptions/char/1.cc: Likewise.
* testsuite/27_io/basic_istream/extractors_arithmetic/char/
exceptions_failbit.cc: Likewise.
* testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/
exceptions_failbit.cc: Likewise.
* testsuite/27_io/basic_istream/extractors_other/char/
exceptions_null.cc: Likewise.
* testsuite/27_io/basic_istream/extractors_other/wchar_t/
exceptions_null.cc: Likewise.
* testsuite/27_io/basic_istream/sentry/char/12297.cc: Likewise.
* testsuite/27_io/basic_istream/sentry/wchar_t/12297.cc: Likewise.
* testsuite/27_io/basic_ostream/inserters_other/char/
exceptions_null.cc: Likewise.
* testsuite/27_io/basic_ostream/inserters_other/wchar_t/
exceptions_null.cc: Likewise.
* testsuite/27_io/ios_base/storage/2.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/27_io/ios_base/failure/dual_abi.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/Makefile.am
trunk/libstdc++-v3/src/c++11/Makefile.in
trunk/libstdc++-v3/src/c++11/cxx11-ios_failure.cc
trunk/libstdc++-v3/src/c++11/ios.cc
trunk/libstdc++-v3/src/c++98/ios_failure.cc
trunk/libstdc++-v3/testsuite/27_io/basic_ios/copyfmt/char/1.cc
trunk/libstdc++-v3/testsuite/27_io/basic_ios/exceptions/char/1.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/exceptions_failbit.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/exceptions_failbit.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/char/exceptions_null.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/wchar_t/exceptions_null.cc
trunk/libstdc++-v3/testsuite/27_io/basic_istream/sentry/char/12297.cc
trunk/libstdc++-v3/testsuite/27_io/basic_istream/sentry/wchar_t/12297.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/exceptions_null.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/wchar_t/exceptions_null.cc
trunk/libstdc++-v3/testsuite/27_io/ios_base/storage/2.cc

[Bug rtl-optimization/85300] [6/7/8 Regression] ICE in exact_int_to_float_conversion_p, at simplify-rtx.c:895

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 10 15:31:57 2018
New Revision: 259285

URL: https://gcc.gnu.org/viewcvs?rev=259285=gcc=rev
Log:
PR rtl-optimization/85300
* combine.c (subst): Handle subst of CONST_SCALAR_INT_P new_rtx also
into FLOAT and UNSIGNED_FLOAT like ZERO_EXTEND, return a CLOBBER if
simplify_unary_operation fails.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr85300.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/85314] gcc/fortran/resolve.c:9222: unreachable code ?

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P4  |P5
   Severity|normal  |enhancement

[Bug ipa/85103] [8 Regression] Performance regressions on SPEC with r257582

[pthaugen at gcc dot gnu.org]

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

--- Comment #6 from Pat Haugen  ---
Created attachment 43900
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43900=edit
inline dump

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
> So we in additional to that require a target hook that can be queried
> from dwarf2out_early_finish () to disable the output of the sections.
> Or somehow query the simple-object capability there.

Can't we just put a single kludge in the middle-end, for example based on
TARGET_PECOFF which is already used for a kludge in varasm.c?

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[chefmax at gcc dot gnu.org]

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

chefmax at gcc dot gnu.org changed:

   What|Removed |Added

 CC||chefmax at gcc dot gnu.org

--- Comment #5 from chefmax at gcc dot gnu.org ---
Hi Dmitry,

> I thought that maybe code first deallocates the alloca memory on stack, and 
> only then unpoisons it. But no, it first unpoisons and then restores rsp.

Actually when handling __builtin_stack_restore for alloca, GCC indeed first 
 deallocates the alloca memory on stack, and only then unpoisons it. Take a
look on disasm around shash_update_unaligned crypto/shash.c:104:

  8301cc1d: 48 8b 65 b8 mov-0x48(%rbp),%rsp
  8301cc21: 48 8b 7d b0 mov-0x50(%rbp),%rdi
  8301cc25: 48 89 e6mov%rsp,%rsi
  8301cc28: e8 f3 b0 b0 fe  callq  81b27d20
<__asan_allocas_unpoison>

This is also reflected in GCC source code:

/* Insert __asan_allocas_unpoison (top, bottom) call after
 __builtin_stack_restore (new_sp) call.
 The pseudocode of this routine should look like this:
   __builtin_stack_restore (new_sp);
   top = last_alloca_addr;
   bot = new_sp;
   __asan_allocas_unpoison (top, bot);
   last_alloca_addr = new_sp;

That's why the issue happens only when interrupt happens inside
__asan_allocas_unpoison call.

So, this looks like an implementation flaw inside GCC, sorry about that :(.
Perhaps we just need to insert all unpoisoning stuff before
__builtin_stack_restore call to resolve the issue.

[Bug c++/70808] Spurious -Wzero-as-null-pointer-constant for nullptr_t

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  ---
In fact, there is sort-of an inconsistency in build_zero_init_1 which explains
the inconsistency in the original testcase:

  else if (TYPE_PTR_OR_PTRMEM_P (type))
init = fold (convert (type, nullptr_node));
  else if (SCALAR_TYPE_P (type))
init = fold (convert (type, integer_zero_node));

thus std::nullptr_t is handled as a generic scalar, whereas int* is not.
Changing the above as in the below makes sense to me and would have the effect
of suppressing the warning for both the testcases here.

Index: init.c
===
--- init.c  (revision 259287)
+++ init.c  (working copy)
@@ -180,7 +180,7 @@ build_zero_init_1 (tree type, tree nelts, bool sta
items with static storage duration that are not otherwise
initialized are initialized to zero.  */
 ;
-  else if (TYPE_PTR_OR_PTRMEM_P (type))
+  else if (TYPE_PTR_OR_PTRMEM_P (type) || NULLPTR_TYPE_P (type))
 init = fold (convert (type, nullptr_node));
   else if (SCALAR_TYPE_P (type))
 init = fold (convert (type, integer_zero_node));

[Bug target/85329] New: [8 Regression] ICE in add_to_same_comdat_group, at symtab.c:460

[doko at gcc dot gnu.org]

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

Bug ID: 85329
   Summary: [8 Regression] ICE in add_to_same_comdat_group, at
symtab.c:460
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with r259224 on the trunk, x86 architectures, building the i2pd package:

$ cat Crypto.ii
class b {
public:
  __attribute__((target("aes"))) b() {}
  __attribute__((target("default"))) b() {}
};
class c {
  b d;
};
void fn1() { c a; }
__attribute__((target_clones("sse", "default"))) void e() {}

$ g++ -std=c++11 -c -O0 -fPIE -Wall Crypto.ii 
during IPA pass: targetclone
Crypto.ii:10:60: internal compiler error: in add_to_same_comdat_group, at
symtab.c:460
 __attribute__((target_clones("sse", "default"))) void e() {}
^
0x59d301 symtab_node::add_to_same_comdat_group(symtab_node*)
../../src/gcc/symtab.c:460
0x12bbbc8 create_dispatcher_calls
../../src/gcc/multiple_target.c:157
0x12bbbc8 ipa_target_clone
../../src/gcc/multiple_target.c:437
0x12bbbc8 execute
../../src/gcc/multiple_target.c:466
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug target/85328] accessing ymm16 with non-avx512 instruction form

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-10
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r250759.  Debugging.

[Bug testsuite/85326] New: `make check` fails with `--disable-bootstrap` and `--enable-languages=c`

[edersondisouza at hotmail dot com]

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

Bug ID: 85326
   Summary: `make check` fails with `--disable-bootstrap` and
`--enable-languages=c`
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: edersondisouza at hotmail dot com
  Target Milestone: ---

When building gcc from git tree (rev 03d52952b8ed93b676222f957c1a27a24cf3ef71),
`make check` fails if bootstrap is disabled and C is the only language enabled.

Compiled gcc -v output:

~/gcc-build-no-bootstrap$ gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=gcc/xgcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c --disable-bootstrap
--
libdir=/opt/gcc/lib --prefix=/opt/gcc --libexecdir=/opt/gcc/libexec
Thread model: posix
gcc version 8.0.1 20180409 (experimental) (GCC) 

A bit more that one hundred tests fail, all with same message:

C++ compiler not installed on this system.

A more detailed excerpt:

Executing on host: /home/edesouza/gcc-build-no-bootstrap/gcc/xgcc
-B/home/edesouza/gcc-build-no-bootstrap/gcc/
/home/edesouza/gcc/gcc/testsuite/gcc.target/i386/mpx/chkp-thunk-comdat-1.cc 
-B/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/ 
-B/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/mpxrt 
-L/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
 -B/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/ 
-B/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/mpxwrap 
-L/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs
  -B/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/ 
-B/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/mpxrt 
-L/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
 -B/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/ 
-B/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/mpxwrap 
-L/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs
 -fno-diagnostics-show-caret -fdiagnostics-color=never-O1  -O2
-fcheck-pointer-bounds -mmpx -S -o chkp-thunk-comdat-1.s(timeout = 300)
spawn -ignore SIGHUP /home/edesouza/gcc-build-no-bootstrap/gcc/xgcc
-B/home/edesouza/gcc-build-no-bootstrap/gcc/
/home/edesouza/gcc/gcc/testsuite/gcc.target/i386/mpx/chkp-thunk-comdat-1.cc
-B/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/
-B/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/mpxrt
-L/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
-B/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/
-B/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/mpxwrap
-L/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs
-B/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/
-B/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/mpxrt
-L/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
-B/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/
-B/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/mpxwrap
-L/home/edesouza/gcc-build-no-bootstrap/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs
-fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -O2
-fcheck-pointer-bounds -mmpx -S -o chkp-thunk-comdat-1.s
xgcc: error:
/home/edesouza/gcc/gcc/testsuite/gcc.target/i386/mpx/chkp-thunk-comdat-1.cc:
C++ compiler not installed on this system
compiler exited with status 1
FAIL: gcc.target/i386/mpx/chkp-thunk-comdat-1.cc   -O1  (test for excess
errors)
Excess errors:
xgcc: error:
/home/edesouza/gcc/gcc/testsuite/gcc.target/i386/mpx/chkp-thunk-comdat-1.cc:
C++ compiler not installed on this system 

It appears that some tests, even depending on C++, are run and end up failing.
Note that when using bootstrap, tests execute fine [one unrelated test fail on
both], apparently due to the fact that gcc still build the C++ compiler despite
the `--enable-languages=c` flag.

If there's anything else I can provide to help, please let me know.

[Bug c++/70808] Spurious -Wzero-as-null-pointer-constant for nullptr_t

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #6 from Paolo Carlini  ---
Mine.

[Bug target/85328] New: accessing ymm16 with non-avx512 instruction form

[zsojka at seznam dot cz]

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

Bug ID: 85328
   Summary: accessing ymm16 with non-avx512 instruction form
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 43902
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43902=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O3 -fno-caller-saves -mavx512f testcase.c
/tmp/ccNXhuu3.s: Assembler messages:
/tmp/ccNXhuu3.s:418: Error: unsupported instruction `vpand'

The failing instruction is:
...
vpand   %ymm16, %ymm1, %ymm1
...

I tried both most recent GNU as and NASM (both from most recent GIT), but
neither accept this form. Accessing ymm >= 16 is allowed only with the
EVEX-prefixed VPANDD or VPANDQ.

I am really not an expert in AVX512 instruction encoding, but gcc seems to be
wrong here according to the assemblers I tested and Intel's SDM vol.2:
only vpandd/vpandq are using the EVEX prefix, and you can use ymm >= 16 only
with the EVEX prefix.

(this can be generalized to other instructions, such as vpor, and maybe to
other registers, such as xmm/zmm)

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-259207-checking-yes-rtl-df-extra-nobootstrap-pr85177-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-259207-checking-yes-rtl-df-extra-nobootstrap-pr85177-amd64
Thread model: posix
gcc version 8.0.1 20180407 (experimental) (GCC)

[Bug target/85321] Missing documentation and option misc for ppc64le

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Author: segher
Date: Tue Apr 10 18:54:08 2018
New Revision: 259296

URL: https://gcc.gnu.org/viewcvs?rev=259296=gcc=rev
Log:
rs6000: Improve --help=target (PR85321)

This updates the help text for some options to mention the allowed
values for -mXX=XX.


PR target/85321
* config/rs6000/rs6000.opt (mtraceback=): Show the allowed values in
the help text.
(mlong-double-): Ditto.
* config/rs6000/sysv4.opt (msdata=): Ditto.
(mtls-size=): Ditto.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.opt
trunk/gcc/config/rs6000/sysv4.opt

[Bug other/85327] [8 regression] experimental/source_location/1.cc began failing with r259278

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #1 from Jason Merrill  ---
Fixed by r259291.

[Bug other/85327] New: [8 regression] experimental/source_location/1.cc began failing with r259278

[seurer at gcc dot gnu.org]

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

Bug ID: 85327
   Summary: [8 regression] experimental/source_location/1.cc began
failing with r259278
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/./gcc/xg++ -shared-libgcc
-B/home/seurer/gcc/build/gcc-test2/./gcc -nostdinc++
-L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/install/gcc-test2/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/install/gcc-test2/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/install/gcc-test2/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/install/gcc-test2/powerpc64le-unknown-linux-gnu/sys-include
-B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util
/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/experimental/source_location/1.cc
-include bits/stdc++.h -fno-diagnostics-show-caret -fdiagnostics-color=never
./libtestc++.a -Wl,--gc-sections
-L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/filesystem/.libs
-lm -o ./1.exe
PASS: experimental/source_location/1.cc (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64
Execution timeout is: 300
spawn [open ...]
/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/experimental/source_location/1.cc:59:
void test02(): Assertion 's1.loc.line() == 46' failed.
FAIL: experimental/source_location/1.cc execution test


struct S {
  string_view func;
  source_location loc = source_location::current();

  S(source_location loc = source_location::current())
  : func(__FUNCTION__), loc(loc) // values of loc will be from call-site
  {} // line 

  S(int)
  : func(__FUNCTION__) // values of loc should be hereaboutsline 46
  {}
};
. . .
  S s1(1);
  VERIFY( s1.loc.line() == 46 ); // line 59

[Bug testsuite/85326] `make check` fails with `--disable-bootstrap` and `--enable-languages=c`

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jgreenhalgh at gcc dot gnu.org,
   ||krebbel at gcc dot gnu.org,
   ||ktkachov at gcc dot gnu.org,
   ||ramana at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
gcc.target/arm/pr56184.C
gcc.target/arm/pr59985.C
gcc.target/arm/pr67989.C
gcc.target/arm/pr54300.C
gcc.target/arm/pr55073.C
gcc.target/s390/pr77822-1.C
gcc.target/x86_64/abi/ms-sysv/gen.cc
gcc.target/i386/mpx/chkp-thunk-comdat-1.cc
gcc.target/i386/mpx/pr66048.cc
gcc.target/i386/mpx/chkp-thunk-comdat-2.cc
gcc.target/i386/mpx/pr65531.cc
gcc.target/powerpc/undef-bool-1.C
gcc.target/aarch64/pr60675.C
gcc.target/aarch64/pr81414.C
gcc.target/aarch64/simd/pr67896.C
gcc.target/aarch64/sve/const_pred_2.C
gcc.target/aarch64/sve/vcond_1.C
gcc.target/aarch64/sve/const_pred_4.C
gcc.target/aarch64/sve/vcond_1_run.C
gcc.target/aarch64/sve/const_pred_1.C
gcc.target/aarch64/sve/tls_2.C
gcc.target/aarch64/sve/const_pred_3.C
gcc.target/aarch64/pr81422.C

tests are broken this way.  I think ms-sysv/gen.cc is probably ok, as it just a
generator and built with $HOSTCXX rather than target g++.  mpx is deprecated
and going to be removed in GCC 9, so there is no point trying to deal with it.
arm, s390, aarch64 and powerpc should fix their testsuite.