[Bug c++/82069] [8 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||jamrial at gmail dot com

--- Comment #5 from Markus Trippelsdorf  ---
*** Bug 82080 has been marked as a duplicate of this bug. ***

[Bug c++/82080] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #5 from Markus Trippelsdorf  ---
dup.

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

[Bug c++/82069] [8 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||darpeer at hotmail dot com

--- Comment #4 from Markus Trippelsdorf  ---
*** Bug 82198 has been marked as a duplicate of this bug. ***

[Bug c++/82198] clang compile fails with g++ 8

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Markus Trippelsdorf  ---
dup.

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

[Bug c++/82198] New: clang compile fails with g++ 8

[darpeer at hotmail dot com]

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

Bug ID: 82198
   Summary: clang compile fails with g++ 8
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: darpeer at hotmail dot com
  Target Milestone: ---

cd /extra/darse/llvm-svn/objects/tools/lld/ELF &&
/home/darse/ubuntu-17.04/bin/g++  -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-I/extra/darse/llvm-svn/objects/tools/lld/ELF
-I/extra/darse/llvm-svn/llvm/tools/lld/ELF
-I/extra/darse/llvm-svn/llvm/tools/lld/include
-I/extra/darse/llvm-svn/objects/tools/lld/include -I/usr/include/libxml2
-I/extra/darse/llvm-svn/objects/include -I/extra/darse/llvm-svn/llvm/include 
-fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wno-missing-field-initializers -pedantic -Wno-long-long
-Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment
-ffunction-sections -fdata-sections -O3 -DNDEBUG-fno-exceptions -fno-rtti
-o CMakeFiles/lldELF.dir/MapFile.cpp.o -c
/extra/darse/llvm-svn/llvm/tools/lld/ELF/MapFile.cpp
/extra/darse/llvm-svn/llvm/tools/lld/ELF/MapFile.cpp: In lambda function:
/extra/darse/llvm-svn/llvm/tools/lld/ELF/MapFile.cpp:99:33: internal compiler
error: Segmentation fault
 OS << indent(2) << toString(*Syms[I]);
0xf4b50f crash_signal
../../../src/gcc/gcc/toplev.c:341
0x946e32 hash_table, tree_node*>
>::hash_entry, xcallocator>::find_slot_with_hash(tree_node* const&, unsigned
int, insert_option)
../../../src/gcc/gcc/hash-table.h:878
0x946ffc hash_map, tree_node*>
>::put(tree_node* const&, tree_node* const&)
../../../src/gcc/gcc/hash-map.h:136
0xa47b29 register_local_specialization(tree_node*, tree_node*)
../../../src/gcc/gcc/cp/pt.c:1898
0xa47b29 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../../src/gcc/gcc/cp/pt.c:18142
0xa45aae tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../../src/gcc/gcc/cp/pt.c:17900
0xa45ee5 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../../src/gcc/gcc/cp/pt.c:17522
0xa46bd5 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../../src/gcc/gcc/cp/pt.c:17059
0xa46bd5 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../../src/gcc/gcc/cp/pt.c:17059
0xa4605d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../../src/gcc/gcc/cp/pt.c:17538
0x9444eb fold_non_dependent_expr(tree_node*)
../../../src/gcc/gcc/cp/constexpr.c:4955
0xa393b1 build_non_dependent_expr(tree_node*)
../../../src/gcc/gcc/cp/pt.c:24944
0xabd582 build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
../../../src/gcc/gcc/cp/typeck.c:3954
0xa00fde cp_parser_binary_expression
../../../src/gcc/gcc/cp/parser.c:9271
0xa016a4 cp_parser_assignment_expression
../../../src/gcc/gcc/cp/parser.c:9404
0xa03d48 cp_parser_expression
../../../src/gcc/gcc/cp/parser.c:9573
0xa042e8 cp_parser_expression_statement
../../../src/gcc/gcc/cp/parser.c:11071
0xa0a9c3 cp_parser_statement
../../../src/gcc/gcc/cp/parser.c:10887
0xa0ba70 cp_parser_statement_seq_opt
../../../src/gcc/gcc/cp/parser.c:11214
0xa0c26e cp_parser_lambda_body
../../../src/gcc/gcc/cp/parser.c:10624
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/82197] Default flags enabled by GCC at -O3 by default appear to be out of sync with the GCC documentation

[lookatyouhacker at gmail dot com]

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

--- Comment #2 from Shane Peelar  ---
Oops, you're right!  That didn't even occur to me that the link I was using was
GCC trunk--I assumed it was the latest release.  Thanks!  We can close this.

[Bug tree-optimization/82197] Default flags enabled by GCC at -O3 by default appear to be out of sync with the GCC documentation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Is the trunk gcc documentation. 

If you are using 6.4.0 or 7.2.0 each have their own documentation. That is on
the website too.

[Bug web/82197] New: Default flags enabled by GCC at -O3 by default appear to be out of sync with the GCC documentation

[lookatyouhacker at gmail dot com]

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

Bug ID: 82197
   Summary: Default flags enabled by GCC at -O3 by default appear
to be out of sync with the GCC documentation
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lookatyouhacker at gmail dot com
  Target Milestone: ---

The GCC online docs at this URL list the various optimization options GCC
offers:

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Notably, it says that O3 optimization should enable -ftree-loop-distribution. 
However, my build of GCC 7.2.0 disables it with -O3 by default:

>gcc -c -Q -O3 --help=optimizers | grep distribut   
>   
>   
>  Tue 12 Sep 2017 09:37:44 AM EDT
  -ftree-loop-distribute-patterns   [enabled]
  -ftree-loop-distribution  [disabled]

I tracked down the problem to the GCC source code in gcc/opts.c, line 528:

/* -O3 optimizations.  */
{ OPT_LEVELS_3_PLUS, OPT_ftree_loop_distribute_patterns, NULL, 1 },
{ OPT_LEVELS_3_PLUS, OPT_fpredictive_commoning, NULL, 1 },
{ OPT_LEVELS_3_PLUS, OPT_fsplit_paths, NULL, 1 },
/* Inlining of functions reducing size is a good idea with -Os
   regardless of them being declared inline.  */
{ OPT_LEVELS_3_PLUS_AND_SIZE, OPT_finline_functions, NULL, 1 },
{ OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_finline_functions_called_once, NULL, 1
},
{ OPT_LEVELS_3_PLUS, OPT_fsplit_loops, NULL, 1 },
{ OPT_LEVELS_3_PLUS, OPT_funswitch_loops, NULL, 1 },
{ OPT_LEVELS_3_PLUS, OPT_fgcse_after_reload, NULL, 1 },
{ OPT_LEVELS_3_PLUS, OPT_ftree_loop_vectorize, NULL, 1 },
{ OPT_LEVELS_3_PLUS, OPT_ftree_slp_vectorize, NULL, 1 },
{ OPT_LEVELS_3_PLUS, OPT_fvect_cost_model_, NULL, VECT_COST_MODEL_DYNAMIC
},
{ OPT_LEVELS_3_PLUS, OPT_fipa_cp_clone, NULL, 1 },
{ OPT_LEVELS_3_PLUS, OPT_ftree_partial_pre, NULL, 1 },
{ OPT_LEVELS_3_PLUS, OPT_fpeel_loops, NULL, 1 },

In here, it looks like there's no mention of OPT_ftree_loop_distribution.  I
was wondering if this omission was intentional?  It seems that either the
online docs should be updated to reflect this, or the code should be amended to
enable -ftree-loop-distribution with -O3.  I can submit a patch to fix this if
it should in fact be in there.

Some discussion about this was had in this thread:
https://github.com/InBetweenNames/gentooLTO/issues/3

One user confirmed this goes at least as far back as 6.4.0.

Thoughts/suggestions?

Thank you,
Shane Peelar

[Bug target/82196] New: -mcall-ms2sysv-xlogues stubs sometimes use wrong MOV instruction

[daniel.santos at pobox dot com]

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

Bug ID: 82196
   Summary: -mcall-ms2sysv-xlogues stubs sometimes use wrong MOV
instruction
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.santos at pobox dot com
  Target Milestone: ---
Target: x86_64-*-*

The test for rather we use movaps or vmovaps is in
libgcc/config/i386/i386-asm.h and tests the cpp macros __SSE2__ and __AVX__,
which is an error.  This results in at least one situation where movaps is used
when vmovaps is available on the build target.  I would presume that the
alternative condition can exist which would result in a bad opcode.

[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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #9 from Bill Schmidt  ---
Now fixed everywhere.

[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 #8 from Bill Schmidt  ---
Author: wschmidt
Date: Tue Sep 12 21:07:30 2017
New Revision: 252044

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

2017-09-12  Bill Schmidt  

Backport from mainline
2017-09-05  Bill Schmidt  

PR target/81833
* config/rs6000/altivec.md (altivec_vsum2sws): Convert from a
define_insn to a define_expand.
(altivec_vsum2sws_direct): New define_insn.
(altivec_vsumsws): Convert from a define_insn to a define_expand.

[gcc/testsuite]

2017-09-12  Bill Schmidt  

Backport from mainline
2017-09-05  Bill Schmidt  

PR target/81833
* gcc.target/powerpc/pr81833-1.c: New file.
* gcc.target/powerpc/pr81833-2.c: New file.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/pr81833-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/pr81833-2.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/altivec.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[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 #7 from Bill Schmidt  ---
Author: wschmidt
Date: Tue Sep 12 21:03:42 2017
New Revision: 252043

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

2017-09-12  Bill Schmidt  

Backport from mainline
2017-09-05  Bill Schmidt  

PR target/81833
* config/rs6000/altivec.md (altivec_vsum2sws): Convert from a
define_insn to a define_expand.
(altivec_vsum2sws_direct): New define_insn.
(altivec_vsumsws): Convert from a define_insn to a define_expand.

[gcc/testsuite]

2017-09-12  Bill Schmidt  

Backport from mainline
2017-09-05  Bill Schmidt  

PR target/81833
* gcc.target/powerpc/pr81833-1.c: New file.
* gcc.target/powerpc/pr81833-2.c: New file.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr81833-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr81833-2.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/altivec.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[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 #6 from Bill Schmidt  ---
Author: wschmidt
Date: Tue Sep 12 21:02:13 2017
New Revision: 252042

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

2017-09-12  Bill Schmidt  

Backport from mainline
2017-09-05  Bill Schmidt  

PR target/81833
* config/rs6000/altivec.md (altivec_vsum2sws): Convert from a
define_insn to a define_expand.
(altivec_vsum2sws_direct): New define_insn.
(altivec_vsumsws): Convert from a define_insn to a define_expand.

[gcc/testsuite]

2017-09-12  Bill Schmidt  

Backport from mainline
2017-09-05  Bill Schmidt  

PR target/81833
* gcc.target/powerpc/pr81833-1.c: New file.
* gcc.target/powerpc/pr81833-2.c: New file.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr81833-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr81833-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/altivec.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/82195] New: Undemangleable lambda

[nathan at gcc dot gnu.org]

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

Bug ID: 82195
   Summary: Undemangleable lambda
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42162
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42162=edit
generates undemanglable symbol

the attached program generates a call to the symbol
_Z4FrobIZZ3FoovENKUlT_E_clIiEEvS0_EUlvE_Evv
(there is a warning about that instantiation, but it is not the problem).

The demangler cannot demangle it.  The recent recursion protection kicks in to
prevent infinite recursion.

[Bug libgomp/82194] Mapping array section (e.g. [0:N-1]) using omp target map crashes at runtime

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
Summary|[OpenMP 4.5] Mapping array  |Mapping array section (e.g.
   |section (e.g. [0:N-1])  |[0:N-1]) using omp target
   |using omp target map|map crashes at runtime
   |crashes at runtime  |

--- Comment #1 from Jakub Jelinek  ---
That testcase is invalid in OpenMP 4.0/4.5.
  int a1d[N];
#pragma omp target data map(from: a1d[1:])
#pragma omp target map(tofrom: isHost)
  {
use (a1d[someidx]);
  }
In target data you map 999 elements from a1d[1] to a1d[999], but because there
is no map clause for a1d on the target construct and a1d is referenced in the
construct, there is implicit map(tofrom: a1d) on the target construct.  Because
a1d is already partially mapped, that is then unspecified behavior.

This is going to change in OpenMP 5.0, where the implicit data mapping on
target construct will work differently from explicit data mapping, if there
will be a partial mapping, will just increment counter for that and not invoke
UB.  But OpenMP 5.0 isn't done yet and GCC 8 will not support it either.

To be OpenMP 4.0/4.5 compliant you need to write
#pragma omp target data map(from: a1d[1:])
#pragma omp target map(tofrom: isHost) map(alloc: a1d[1:]) // or from: etc., it
doesn't matter, because it is already mapped;
// or of course you can remove the target data and put map(from: a1d[1:])
directly on the target region, it doesn't buy you anything in this case.

[Bug libgomp/82194] New: Mapping array section (e.g. [0:N-1]) using omp target map crashes at runtime

[josem at udel dot edu]

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

Bug ID: 82194
   Summary: Mapping array section (e.g. [0:N-1]) using omp target
map crashes at runtime
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: josem at udel dot edu
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42161
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42161=edit
Reproducible for array_segment bug

Hello GCC community, 

--- SUMARY:

This bug affects OpenMP 4.5 implementation. It occurs when trying to map an
array section by using the [lower-bound:length] subscript expressions.

--- MORE INFORMATION:

According to the OpenMP 4.5 standard, section 2.4, page 44, it is possible to
map an array section containing a subset of the original elements of the array.
However, I am getting a runtime error when trying to do so. Attached you will
find an example code that crashes when trying to use map(from: a1d[1:]) which
should map the array from element 1 to N.

Output error is: 
libgomp: Trying to map into device [0x3fc66a6c..0x3fc67a0c) object when
[0x3fc66a70..0x3fc67a0c) is already mapped

Other options that fail as well with the same error (different memory regions)
are: 
> #pragma omp target data map(from: a1d[1:N-1]) 
> #pragma omp target data map(from: a1d[0:N-1])
> #pragma omp target data map(from: a1d[0:N/5])

Backtrace information: 
#0  0x3fffb7d2847c in write () from /lib64/libc.so.6
#1  0x3fffb7ca7274 in _IO_new_file_write () from /lib64/libc.so.6
#2  0x3fffb7ca7da8 in __GI__IO_file_xsputn () from /lib64/libc.so.6
#3  0x3fffb7c76c50 in buffered_vfprintf () from /lib64/libc.so.6
#4  0x3fffb7c77170 in vfprintf@@GLIBC_2.17 () from /lib64/libc.so.6
#5  0x3fffb7e4bb2c in gomp_verror (fmt=0x3fffb7e78d98 "Trying to map into
device [%p..%p) object when [%p..%p) is already mapped", list=0x3fffc198
"\374\305\377\377\377?")
at ../../../gcc/libgomp/error.c:62
#6  0x3fffb7e4bbe8 in gomp_vfatal (fmt=, list=0x3fffc198
"\374\305\377\377\377?") at ../../../gcc/libgomp/error.c:79
#7  0x3fffb7e4bc38 in gomp_fatal (fmt=) at
../../../gcc/libgomp/error.c:89
#8  0x3fffb7e63dd0 in gomp_map_vars_existing (devicep=0x3fffb7e698f4
, oldn=0x10514a70, newn=, newn=, kind=, tgt_var=0x10514c00)
at ../../../gcc/libgomp/target.c:234
#9  0x3fffb7e67450 in gomp_map_vars_existing (newn=0x3fffc288,
newn=0x3fffc288, kind=, tgt_var=0x10514c00, oldn=0x10514a70,
devicep=)
at ../../../gcc/libgomp/target.c:234
#10 gomp_map_vars (devicep=0x100cb500, mapnum=2, hostaddrs=0x3fffc5e8,
devaddrs=0x0, sizes=0x10080020 <.omp_data_sizes.8.3210>, kinds=0x10080030
<.omp_data_kinds.9.3211>, short_mapkind=true,
pragma_kind=GOMP_MAP_VARS_TARGET) at ../../../gcc/libgomp/target.c:725
#11 0x3fffb7e698f4 in GOMP_target_ext (device=,
fn=0x1bcc , mapnum=2, hostaddrs=0x3fffc5e8,
sizes=0x10080020 <.omp_data_sizes.8.3210>,
kinds=0x10080030 <.omp_data_kinds.9.3211>, flags=,
depend=, args=0x3fffc5c8) at
../../../gcc/libgomp/target.c:2029
#12 0x19b8 in fail_on_map ()
#13 0x1b34 in main ()

--- COMPILATION COMMAND: 

> gcc -std=c99 -fopenmp -foffload="-lm" -lm array_segment_map.c -o 
> array_segment_map.c.o

--- MACHINE INFORMATION

I tested this in a 64 bit system. 
> gcc --version
gcc (GCC) 7.1.1 20170718
- OS: Red Hat Enterprise Linux Server 7.3 - CentOS release 7
- PROCESSOR: POWER8NVL ppc64le
- TARGET DEVICE: NVIDIA Tesla P100 GPU

[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 #3 from Peter Cordes  ---
(In reply to Richard Biener from comment #2)
> And it gets worse because of the splitting
> which isn't exposed to the vectorizer.

Split loads/stores can be a useful shuffling strategy even on Haswell/Skylake
(which don't normally benefit from split loads/stores for contiguous but
unaligned).   vinsertf128 from memory only requires a load uop + blend uop
which can run on any of the three vector ALU ports.  (The register-source
version is a shuffle, though.)  vextractf128 is a pure store with no ALU, but
the store-address and store-data uops can't micro-fuse.  If store-port
throughput isn't a problem but shuffle throughput is, it could be a win.

Unaligned overlapping loads are another interesting way to replace shuffles in
some cases.

> not sure what ends up messing things up here (I guess AVX256 doesn't have
> full width extract even/odd and interleave high/low ...).

 Yep, replied to that in detail at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82137#c2

> Looks like with -mprefer-avx128 we never try the larger vector size (Oops?).
> At least we figure vectorization isn't profitable.

 AVX actually makes the SSE2 vectorization strategy a lot better (saves a lot
of movdqa reg,reg copies), and it implies that the CPU has efficient unaligned
vector load/store.  So probably the best choice for -mavx -mprefer-avx128 is to
vectorize like SSE2, but with unaligned loads/stores.

256b lane-crossing shuffles are extra expensive with -mtune=znver1 and
-mtune=bdver* (which enable -mprefer-avx128), so it's a good thing that
-mprefer-avx128 doesn't enable the current AVX1/2 256b vectorization strategy. 
(Which is horrible in this case anyway: bug 82137).

With a good 256b vectorization strategy, it might be a win for Ryzen (which,
unlike Bulldozer-family, has better total uop throughput when running 2-uop
instructions like AVX 256b according to Agner Fog, so -mprefer-avx128 isn't
always appropriate for Ryzen.)

> So all this probably boils down to costs of permutes not being modeled.

That would certainly explain gcc's behaviour in a lot of cases.  It often seems
pretty shuffle-happy, even though shuffles are a very limited execution
resource.  (Especially with unrolling so front-end bottlenecks don't hide the
shuffle bottlenecks.)

[Bug bootstrap/81315] powerpc64 vs building lang/gcc7-devel (on FreeBSD head): xgcc gets segmentation fault

[markmigm at gmail dot com]

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

--- Comment #2 from Mark Millard  ---
(In reply to Martin Liška from comment #1)
> Any chance to reproduce with a cross compiler on Linux?

I assume that amd64 as a host is implicit in this
request.

It is less clear if the target is intended as a
powerpc64 linux vs. powerpc64 freebsd.

I do not have a linux environment set up for amd64
in order to install a such cross compiler (either case)
and then to have that in turn process class_type_info.ii
(from the attachment). I'm less familiar with Linux.
It would take a while for me to set up such.

It may be better for someone that runs an amd64 linux
normally to install whatever cross compiler is intended.
(Or build and install if required.)

If I'm to do this it would be better for me to have
explicit instructions about what cross compiler to
install (in, say, ubuntu) -- or steps to build and
install what is desired if no re-built installer is
around. Either way instructions about how to run
the test may be appropriate as well if there is
anything special about how to best run it.

[Bug c++/70621] [6/7 Regression] ICE on invalid code at -O1 and above on x86_64-linux-gnu in record_reference, at cgraphbuild.c:64

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE on   |[6/7 Regression] ICE on
   |invalid code at -O1 and |invalid code at -O1 and
   |above on x86_64-linux-gnu   |above on x86_64-linux-gnu
   |in record_reference, at |in record_reference, at
   |cgraphbuild.c:64|cgraphbuild.c:64

--- Comment #14 from Paolo Carlini  ---
Fixed in trunk so far.

[Bug c++/70621] [6/7/8 Regression] ICE on invalid code at -O1 and above on x86_64-linux-gnu in record_reference, at cgraphbuild.c:64

[paolo at gcc dot gnu.org]

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

--- Comment #13 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Sep 12 19:45:37 2017
New Revision: 252040

URL: https://gcc.gnu.org/viewcvs?rev=252040=gcc=rev
Log:
/cp
2017-09-12  Paolo Carlini  

PR c++/70621
* decl.c (start_decl): Early return error_mark_node if duplicate_decls
returns it; avoid misleading error message.

/testsuite
2017-09-12  Paolo Carlini  

PR c++/70621
* g++.dg/torture/pr70621.C: New.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr70621.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/82193] incorrectly rejects int x; struct { decltype(x) x; } f = {x};

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
[basic.scope.class] p2:

"A name N used in a class S shall refer to the same declaration in its context
and when re-evaluated in the completed scope of S. No diagnostic is required
for a violation of this rule."

So the code is ill-formed, no diagnostic required.

GCC is allowed to reject it. The other compilers fail to diagnose it (which is
also conforming).

[Bug tree-optimization/69249] Array-boundary offending code is silently discarded without warnings

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

 CC||arnd at linaro dot org

--- Comment #3 from Arnd Bergmann  ---
I see the same behavior on incorrect code (off-by-one bug accessing beyond the
array, in my case with a negative index) on Linux kernel code: The following
snippet produces a warning with all versions up to 4.7, but not with 4.8 or
later (latest tried: gcc-8.0.0):

8<
#define MEDIA_BUS_FMT_YUYV8_2X8 0x2008
#define MEDIA_BUS_FMT_YVYU8_2X8 0x2009
#define MEDIA_BUS_FMT_UYVY8_2X8 0x2006
#define MEDIA_BUS_FMT_VYUY8_2X8 0x2007

static const unsigned int camif_mbus_formats[4] = {
MEDIA_BUS_FMT_YUYV8_2X8,
MEDIA_BUS_FMT_YVYU8_2X8,
MEDIA_BUS_FMT_UYVY8_2X8,
MEDIA_BUS_FMT_VYUY8_2X8,
};

int __camif_subdev_try_format(unsigned int code)
{
int i = sizeof(camif_mbus_formats) / sizeof(camif_mbus_formats[0]);

while (i-- >= 0)
if (camif_mbus_formats[i] == code)
break;

return i;
}

[Bug c++/82193] incorrectly rejects int x; struct { decltype(x) x; } f = {x};

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Marc Mutz from comment #2)
> Basically: because the other two compilers compile it.

Again so ...

[Bug c++/82193] incorrectly rejects int x; struct { decltype(x) x; } f = {x};

[marc.mutz at kdab dot com]

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

--- Comment #2 from Marc Mutz  ---
Basically: because the other two compilers compile it.

[Bug c++/82193] incorrectly rejects int x; struct { decltype(x) x; } f = {x};

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Why do you think this is a bug in GCC?

The "changes meaning of" is a diagnostic which is not required by C++.  That is
the C++ language says this is invalid code but a diagnostic is not required.

[Bug tree-optimization/82192] [5/6/7/8 Regression] gcc produces incorrect code with -O2 and bit-field

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #6)
> emit instead a left shift by -12 and right shift by 19 instead of left shift
> by 31.

Instead of right shift by 31 obviously.

[Bug tree-optimization/82192] [5/6/7/8 Regression] gcc produces incorrect code with -O2 and bit-field

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
So, the shift count is computed in the end in QImode and we have essentially
(unsigned char)(((unsigned char) a) | 0xf7) + 0x28) as the shift count.
The only two results of that, whatever a is, are 0x1f or 0x27, and perhaps
something in the combiner or simplify-rtx during combine figures out that from
those two only 0x1f is valid shift count, but then something decides to emit
instead a left shift by -12 and right shift by 19 instead of left shift by 31.
Will need to step through in detail tomorrow.

[Bug tree-optimization/82137] 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

--- Comment #2 from Peter Cordes  ---
(In reply to Richard Biener from comment #1)
> Interesting idea.  It's probably a bit hard to make the vectorizer do this
> though given it's current structure and the fact that it would have to
> cost the extra ops against the saved suffling (the extra cost of the ops
> would depent on availability of spare execution resources for example).

 Shuffles take execution resources just like anything else (except for
load+broadcast (vbroadcastss or movddup, or even movshdup) which is done as
part of a load uop in Ryzen and Intel CPUs).

On Haswell and later Intel, there's only one shuffle port, but multiple ports
for almost everything else (especially on Skylake).  Shuffles are very often
the bottleneck if you're not careful, or shuffle + something else that also
only runs on port 5 (Intel).

Shuffle instructions also of course take front-end throughput resources, and
that's another common bottleneck in code with a mix of ops for different ports
(e.g. loads, stores, ALU, integer loop overhead.)  Without loop unrolling,
front-end or memory bandwidth are the most likely bottlenecks for
load+ALU+store loops.  (Latency is often a bottleneck for reduction loops,
because gcc is bad at unrolling with multiple accumulators last I looked.)

A cost model that includes the front-end, and the limited throughput of of
shuffles, would be a *very* good thing to have.  Especially when using shuffles
that take multiple instructions because of limited flexibility in the
instruction set.


> In general the interleaving strategy looks like a bit of a dead end with
> AVX.

And in bug 82136 you said:
> (I guess AVX256 doesn't have full width extract even/odd
> and interleave high/low ...)

That's correct.  AVX1 / AVX2 have very few 2-input lane-crossing shuffles. 
(Most of the 2-input shuffles work in two separate 128b lanes, like 2 separate
128b instructions glued together).

I think the only ones that exist are vperm2i/f128 which shuffle with 128b
granularity.


> (and possibly worse on AVX512).

Actually it's much better on AVX512.  It mostly drops the in-lane limitations
of AVX1/AVX2.  It has powerful 2-input lane-crossing shuffles like vpermt2d /
ps or vperm2tq / pd that can do the shuffles gcc wants with one instruction
each, using a shuffle control constant in another vector.

Clang and gcc both use them with `-march=skylake-avx512`:
https://godbolt.org/g/SzwxNA.  (Actually, gcc uses vpermi2pd instead of
vpermt2pd, costing it an extra 2 vmovdapd instead of clobbering the load result
or add results with the 2nd shuffle.  Clang gets it right; see the clang tab on
that godbolt link.)

It's back down to 4 shuffles per 2 loads / 2 stores / add+mul, same as in the
128b case with unpckl/hpd.  I.e. 2 shuffles per vector of results, but it saves
a mul+add vs. the shuffle/blend AVX1 strategy.  It also "tricks" gcc into
unrolling and doing 2 vectors per loop iteration, reducing loop overhead for
the non-PGO default of not unrolling.

KNL has lower throughput for vpermt2pd (one per 2c vs. 1c for vpermilps), but
it's still only 1 uop.  Since Knight's Landing bottlenecks almost completely on
front-end decode (2 instructions per clock), it takes about 8 clocks to issue
the loop, which matches the time for 4 two-input shuffles.  If out-of-order
execution + hyperthreading can hide the latency, it should be fine.

Skylake-avx512 (aka SKX) doesn't care about 2 or 3 input shuffles vs. 1 input
(same throughput for vpermilpd vs. vpermt2pd
https://github.com/InstLatx64/InstLatx64/blob/master/GenuineIntel0050654_SkylakeX_InstLatX64.txt).
 Lane-crossing shuffles have higher latency, but the shuffle isn't part of a
loop-carried dependency.

SKX shuts down port 1 shut down while 512b uops are in flight, so the
shuffle+blend strategy with duplicated work would probably bottleneck on ALU
throughput and still only manage one vector per 2 clocks.  clang's output (what
gcc should emit for its current strategy) is 15 front-end uops, or 3.75 cycles
for the front-end, so gcc will bottleneck just barely on shuffle throughput,
assuming vmulpd and vaddpd never get scheduled onto port5 and steal a cycle
from a shuffle.  (Should be rare, because there's much less pressure on port0).

[Bug c++/82193] New: incorrectly rejects int x; struct { decltype(x) x; } f = {x};

[marc.mutz at kdab dot com]

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

Bug ID: 82193
   Summary: incorrectly rejects int x; struct { decltype(x) x; } f
= {x};
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

This code:

  void fun() {
constexpr int x = 42;

constexpr struct {
decltype(x) x;

constexpr auto operator()(int a) const { return a * x; }
} f = {x};
static_assert(f(0) == 0);
static_assert(f(2) == 2*42);
  }

(trying to show how a compiler might expand a lambda [x](int a){return a*x;}),
fails to compile on all GCCs I tested, incl. trunk as installed on godbold,
with the following incomprehensible error message:

6 : :6:21: error: declaration of 'const int fun()x'
[-fpermissive]
 decltype(x) x;
 ^
3 : :3:19: error: changes meaning of 'x' from 'constexpr const int x'
[-fpermissive]
 constexpr int x = 42;
   ^


Clang 4 and MSVC 2017 both compile this code just fine:
https://godbolt.org/g/4L6ULo

The problem is not the constexpr. I only added those to be able to execute the
function call operator without having to run the executable.

[Bug fortran/82173] [meta-bug] Parameterized derived type errors

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas  ---
Author: pault
Date: Tue Sep 12 18:06:52 2017
New Revision: 252039

URL: https://gcc.gnu.org/viewcvs?rev=252039=gcc=rev
Log:
2017-09-12  Paul Thomas  

PR fortran/82173
PR fortran/82168
* decl.c (variable_decl): Check pdt template components for
appearance of KIND/LEN components in the type parameter name
list, that components corresponding to type parameters have
either KIND or LEN attributes and that KIND or LEN components
are scalar. Copy the initializer to the parameter value.
(gfc_get_pdt_instance): Add a label 'error_return' and follow
it with repeated code, while replacing this code with a jump.
Check if a parameter appears as a component in the template.
Make sure that the parameter expressions are integer. Validate
KIND expressions.
(gfc_match_decl_type_spec): Search for pdt_types in the parent
namespace since they are instantiated in the template ns.
* expr.c (gfc_extract_int): Use a KIND parameter if it
appears as a component expression.
(gfc_check_init_expr): Allow expressions with the pdt_kind
attribute.
*primary.c (gfc_match_actual_arglist): Make sure that the first
keyword argument is recognised when 'pdt' is set.


2017-09-12  Paul Thomas  

PR fortran/82173
* gfortran.dg/pdt_4.f03 : Remove the 'is being used before it
is defined' error.
* gfortran.dg/pdt_6.f03 : New test.
* gfortran.dg/pdt_7.f03 : New test.
* gfortran.dg/pdt_8.f03 : New test.

PR fortran/82168
* gfortran.dg/pdt_9.f03 : New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pdt_6.f03
trunk/gcc/testsuite/gfortran.dg/pdt_7.f03
trunk/gcc/testsuite/gfortran.dg/pdt_8.f03
trunk/gcc/testsuite/gfortran.dg/pdt_9.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pdt_4.f03

[Bug fortran/82168] Parameterized Derived Types, problems with default type parameters

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Tue Sep 12 18:06:52 2017
New Revision: 252039

URL: https://gcc.gnu.org/viewcvs?rev=252039=gcc=rev
Log:
2017-09-12  Paul Thomas  

PR fortran/82173
PR fortran/82168
* decl.c (variable_decl): Check pdt template components for
appearance of KIND/LEN components in the type parameter name
list, that components corresponding to type parameters have
either KIND or LEN attributes and that KIND or LEN components
are scalar. Copy the initializer to the parameter value.
(gfc_get_pdt_instance): Add a label 'error_return' and follow
it with repeated code, while replacing this code with a jump.
Check if a parameter appears as a component in the template.
Make sure that the parameter expressions are integer. Validate
KIND expressions.
(gfc_match_decl_type_spec): Search for pdt_types in the parent
namespace since they are instantiated in the template ns.
* expr.c (gfc_extract_int): Use a KIND parameter if it
appears as a component expression.
(gfc_check_init_expr): Allow expressions with the pdt_kind
attribute.
*primary.c (gfc_match_actual_arglist): Make sure that the first
keyword argument is recognised when 'pdt' is set.


2017-09-12  Paul Thomas  

PR fortran/82173
* gfortran.dg/pdt_4.f03 : Remove the 'is being used before it
is defined' error.
* gfortran.dg/pdt_6.f03 : New test.
* gfortran.dg/pdt_7.f03 : New test.
* gfortran.dg/pdt_8.f03 : New test.

PR fortran/82168
* gfortran.dg/pdt_9.f03 : New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pdt_6.f03
trunk/gcc/testsuite/gfortran.dg/pdt_7.f03
trunk/gcc/testsuite/gfortran.dg/pdt_8.f03
trunk/gcc/testsuite/gfortran.dg/pdt_9.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pdt_4.f03

[Bug tree-optimization/82192] [5/6/7/8 Regression] gcc produces incorrect code with -O2 and bit-field

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-09-12
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|gcc produces incorrect code |[5/6/7/8 Regression] gcc
   |with -O2 and bit-field  |produces incorrect code
   ||with -O2 and bit-field
 Ever confirmed|0   |1

--- Comment #5 from Jakub Jelinek  ---
Simplified testcase:
unsigned long long int a = 0x95dd3d896f7422e2ULL;
struct S { unsigned int m : 13; } b;

__attribute__((noinline, noclone)) void
foo (void)
{
  b.m = ((unsigned)a) >> (0x644eee9667723bf7LL | a & ~0xdee27af8U) -
0x644eee9667763bd8LL;
}

int
main ()
{
  if (__INT_MAX__ != 0x7fffULL)
return 0;
  foo ();
  if (b.m != 0)
__builtin_abort ();
  return 0;
}

Started with r191928 I believe (optimized dump is identical, r191925 works,
r191931 doesn't).  I'll have a look tomorrow.

[Bug target/82112] internal compiler error: in fold_convert_loc, at fold-const.c:2262

[noloader at gmail dot com]

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

--- Comment #4 from Jeffrey Walton  ---
Thank you very much Jakub.

[Bug target/82185] ICE: Segmentation fault in expand_binop gcc/optabs.c:1137

[jcmvbkbc at gcc dot gnu.org]

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

--- Comment #5 from jcmvbkbc at gcc dot gnu.org ---
(In reply to Martin Liška from comment #2)
> Can't reproduce with x86_64-linux-gnu cross compiler:
> 
> ../configure --enable-languages=c,c++ --disable-multilib
> --disable-libsanitizer --prefix=/home/marxin/bin/gcc --disable-bootstrap
> --target=xtensa-linux-gnu
> 
> Can you help me how to reproduce?

Sorry, my configure line for gcc that was failing was:

../gcc/configure --prefix=`pwd`/root --target=xtensa-buildroot-linux-uclibc
--disable-shared --disable-libssp --disable-libisl --enable-languages=c
CFLAGS='-O0 -g3' CXXFLAGS='-O0 -g3'

And the exact gcc version was f8c733e861ce8ca30013c364b062c4aef5c1f78a or
r251982 in the SVN. The rest I believe is in the bug report.

[Bug c/80942] -Woverlength-strings should no longer be implied by -Wpedantic

[vincent-gcc at vinc17 dot net]

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

--- Comment #6 from Vincent Lefèvre  ---
(In reply to jos...@codesourcery.com from comment #5)
> > --- Comment #4 from Vincent Lefèvre  ---
> > This is not what is documented:
> > 
> > Issue all the warnings demanded by strict ISO C and ISO C++; reject
> > all programs that use forbidden extensions, and some other programs
> > that do not follow ISO C and ISO C++.  For ISO C, follows the
> > version of the ISO C standard specified by any -std option used.
> 
> I consider this to be within the "some other programs".  The question, I 
> suppose, is whether implementation limits should be moved out of the scope 
> of -Wpedantic.

I would not say that this is within the "some other programs". I mean that a
program that has string constants shorter than the implementation limit follows
ISO C, even when these strings are longer than the minimum limit allowed by ISO
C. It is just not strictly conforming (like almost all programs).

[Bug other/81096] [8 regression] test case ttest in libbacktrace fails starting with its introduction in r249111

[sje at gcc dot gnu.org]

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

--- Comment #6 from Steve Ellcey  ---
Author: sje
Date: Tue Sep 12 17:00:00 2017
New Revision: 252038

URL: https://gcc.gnu.org/viewcvs?rev=252038=gcc=rev
Log:
2017-09-12  Steve Ellcey  

PR other/81096
* Makefile.am (ttest_CFLAGS): Add $(AM_CFLAGS)
* Makefile.in: Regenerate.

Modified:
trunk/libbacktrace/ChangeLog
trunk/libbacktrace/Makefile.am

[Bug sanitizer/82116] "nested bug in the same thread" when a bug is found while reporting another one

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
URL||https://github.com/google/s
   ||anitizers/issues/858
 CC||egallager at gcc dot gnu.org
 Resolution|--- |MOVED

--- Comment #3 from Eric Gallager  ---
(In reply to Dmitry Vyukov from comment #2)
> Filed upstream bug:
> https://github.com/google/sanitizers/issues/858
> We can close this (or leave to track fix backport).

"MOVED" seems like the right resolution in that case.

[Bug tree-optimization/82192] gcc produces incorrect code with -O2 and bit-field

[vsevolod.livinskij at frtk dot ru]

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

--- Comment #4 from Vsevolod Livinskiy  ---
(In reply to jos...@codesourcery.com from comment #3)
> On Tue, 12 Sep 2017, vsevolod.livinskij at frtk dot ru wrote:
> 
> > struct struct_t {
> > unsigned int memb : 13;
> > };
> > 
> > extern struct_t b;
> 
> > printf("%llu\n", b.memb);
> 
> unsigned int : 13 (promoted to int - I think C++ promotes 
> narrower-than-int bit-fields to int, though for C++ the bit-field width is 
> not considered part of the type) is not valid for printf %llu.  You need 
> to explicitly cast to unsigned long long.

printf("%llu\n", (unsigned long long int)b.memb)
doesn't eliminate the error

[Bug driver/81498] Support creating static PIE

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 8.

[Bug other/81096] [8 regression] test case ttest in libbacktrace fails starting with its introduction in r249111

[sje at gcc dot gnu.org]

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

--- Comment #5 from Steve Ellcey  ---
Author: sje
Date: Tue Sep 12 16:33:31 2017
New Revision: 252035

URL: https://gcc.gnu.org/viewcvs?rev=252035=gcc=rev
Log:
2017-09-12  Steve Ellcey  

PR other/81096
* libbacktrace/Makefile.in
(HAVE_PTHREAD_TRUE@@NATIVE_TRUE@ttest_CFLAGS): Add $(AM_CFLAGS)

Modified:
trunk/libbacktrace/ChangeLog
trunk/libbacktrace/Makefile.in

[Bug target/81325] -fcompare-debug failure on ppc64le

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug driver/81498] Support creating static PIE

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Sep 12 16:30:28 2017
New Revision: 252034

URL: https://gcc.gnu.org/viewcvs?rev=252034=gcc=rev
Log:
Add -static-pie to GCC driver to create static PIE

This patch adds -static-pie to GCC driver to create static PIE.  A static
position independent executable (PIE) is similar to static executable,
but can be loaded at any address without a dynamic linker.  All linker
input files must be compiled with -fpie or -fPIE and linker must support
--no-dynamic-linker to avoid linking with dynamic linker.  "-z text" is
also needed to prevent dynamic relocations in read-only segments.

PR driver/81498
* common.opt (-static-pie): New alias.
(shared): Negate static-pie.
(-no-pie): Update help text.
(-pie): Likewise.
(static-pie): New option.
* config/gnu-user.h (GNU_USER_TARGET_STARTFILE_SPEC): Add
-static-pie support.
(GNU_USER_TARGET_ENDFILE_SPEC): Likewise.
(LINK_EH_SPEC): Likewise.
(LINK_GCC_C_SEQUENCE_SPEC): Likewise.
* config/i386/gnu-user.h (GNU_USER_TARGET_LINK_SPEC): Likewise.
* config/i386/gnu-user64.h (GNU_USER_TARGET_LINK_SPEC): Likewise.
* gcc.c (LINK_COMMAND_SPEC): Likewise.
(init_gcc_specs): Likewise.
(init_spec): Likewise.
(display_help): Update help message for -pie.
* doc/invoke.texi: Update -pie, -no-pie and -static.  Document
-static-pie.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt
trunk/gcc/config/gnu-user.h
trunk/gcc/config/i386/gnu-user.h
trunk/gcc/config/i386/gnu-user64.h
trunk/gcc/doc/invoke.texi
trunk/gcc/gcc.c

[Bug libstdc++/70483] string_view::compare and coparision operators are not constexpr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
And now for 7.3 as well.

[Bug libstdc++/70483] string_view::compare and coparision operators are not constexpr

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Tue Sep 12 16:27:09 2017
New Revision: 252031

URL: https://gcc.gnu.org/viewcvs?rev=252031=gcc=rev
Log:
PR libstdc++/70483 make std::string_view fully constexpr

Backport from mainline
2017-09-11  Jonathan Wakely  

PR libstdc++/70483
* include/bits/string_view.tcc (basic_string_view::find)
(basic_string_view::rfind, basic_string_view::find_first_of)
(basic_string_view::find_last_of, basic_string_view::find_first_not_of)
(basic_string_view::find_last_not_of): Add constexpr specifier.
* include/std/string_view (basic_string_view::operator=)
(basic_string_view::rbegin, basic_string_view::rend)
(basic_string_view::crbegin, basic_string_view::crend)
(basic_string_view::remove_prefix, basic_string_view::remove_suffix)
(basic_string_view::swap, basic_string_view::compare)
(basic_string_view::find, basic_string_view::rfind)
(basic_string_view::find_first_of, basic_string_view::find_last_of)
(basic_string_view::find_first_not_of)
(basic_string_view::find_last_not_of, basic_string_view::_M_check)
(basic_string_view::_M_limit, operator==, operator!=, operator<)
(operator>, operator<=, operator>=): Likewise.
* testsuite/21_strings/basic_string_view/modifiers/remove_prefix/
char/1.cc: Repeat tests in constexpr context.
* testsuite/21_strings/basic_string_view/modifiers/remove_prefix/
wchar_t/1.cc: Likewise.
* testsuite/21_strings/basic_string_view/modifiers/remove_suffix/
char/1.cc: Likewise.
* testsuite/21_strings/basic_string_view/modifiers/remove_suffix/
wchar_t/1.cc: Likewise.
* testsuite/21_strings/basic_string_view/operations/find/char/1.cc:
Likewise.
* testsuite/21_strings/basic_string_view/operations/find/char/2.cc:
Likewise.
* testsuite/21_strings/basic_string_view/operations/find/char/3.cc:
Likewise.
* testsuite/21_strings/basic_string_view/operations/find/wchar_t/1.cc:
Likewise.
* testsuite/21_strings/basic_string_view/operations/find/wchar_t/2.cc:
Likewise.
* testsuite/21_strings/basic_string_view/operations/find/wchar_t/3.cc:
Likewise.
* testsuite/21_strings/basic_string_view/operators/char/2.cc:
Likewise.
* testsuite/21_strings/basic_string_view/operators/wchar_t/2.cc:
Likewise.
* testsuite/21_strings/basic_string_view/range_access/char/1.cc: Test
cbegin, cend, rbegin, rend, crbegin and crend.
* testsuite/21_strings/basic_string_view/range_access/wchar_t/1.cc:
Likewise.
* testsuite/21_strings/basic_string_view/operations/compare/char/1.cc:
Remove trailing whitespace.
* testsuite/21_strings/basic_string_view/operations/compare/wchar_t/
1.cc: Likewise.
* testsuite/21_strings/basic_string_view/modifiers/swap/char/1.cc:
New.
* testsuite/21_strings/basic_string_view/modifiers/swap/wchar_t/1.cc:
New.
* testsuite/21_strings/basic_string_view/operations/compare/char/2.cc:
New.
* testsuite/21_strings/basic_string_view/operations/compare/wchar_t/
2.cc: New.

Added:
   
branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string_view/modifiers/swap/
   
branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string_view/modifiers/swap/char/
   
branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string_view/modifiers/swap/char/1.cc
  - copied, changed from r252030,
branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string_view/range_access/char/1.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string_view/modifiers/swap/wchar_t/
   
branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string_view/modifiers/swap/wchar_t/1.cc
  - copied, changed from r252030,
branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string_view/range_access/wchar_t/1.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string_view/operations/compare/char/2.cc
  - copied, changed from r252030,
branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string_view/range_access/char/1.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string_view/operations/compare/char/70483.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string_view/operations/compare/wchar_t/2.cc
  - copied, changed from r252030,
branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string_view/range_access/char/1.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/string_view.tcc
branches/gcc-7-branch/libstdc++-v3/include/std/string_view
   

[Bug libstdc++/70483] string_view::compare and coparision operators are not constexpr

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Tue Sep 12 16:27:14 2017
New Revision: 252032

URL: https://gcc.gnu.org/viewcvs?rev=252032=gcc=rev
Log:
PR libstdc++/70483 make std::experimental::string_view fully constexpr

Backport from mainline
2017-09-12  Jonathan Wakely  

PR libstdc++/70483
* include/experimental/bits/string_view.tcc (basic_string_view::find)
(basic_string_view::rfind, basic_string_view::find_first_of)
(basic_string_view::find_last_of, basic_string_view::find_first_not_of)
(basic_string_view::find_last_not_of): Add constexpr specifier.
* include/experimental/string_view (basic_string_view::remove_prefix)
(basic_string_view::remove_suffix, basic_string_view::swap)
(basic_string_view::compare, basic_string_view::find)
(basic_string_view::rfind, basic_string_view::find_first_of)
(basic_string_view::find_last_of, basic_string_view::find_first_not_of)
(basic_string_view::find_last_not_of, operator==, operator!=)
(operator<, operator>, operator<=, operator>=): Likewise.
* testsuite/experimental/string_view/operations/compare/char/70483.cc:
New.

Added:
   
branches/gcc-7-branch/libstdc++-v3/testsuite/experimental/string_view/operations/compare/char/70483.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
   
branches/gcc-7-branch/libstdc++-v3/include/experimental/bits/string_view.tcc
branches/gcc-7-branch/libstdc++-v3/include/experimental/string_view

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely  ---
Author: redi
Date: Tue Sep 12 16:27:01 2017
New Revision: 252030

URL: https://gcc.gnu.org/viewcvs?rev=252030=gcc=rev
Log:
Finish implementing P0426R1 "Constexpr for std::char_traits" for C++17

As discussed in PR c++/80265 ("__builtin_{memcmp,memchr,strlen} are
not usable in constexpr functions"), use __builtin_constant_p to tell
whether we can defer to a constexpr algorithm.

I used __always_inline__ just to be thorough.  It isn't really really
necessary as far as I could determine.

Changes like these:

 if (__n == 0)
   return 0;
 -  return wmemcmp(__s1, __s2, __n);
 +  else
 +return wmemcmp(__s1, __s2, __n);

are necessary otherwise G++ complains that we're calling a
non-constexpr function, which looks like a a manifestation of PR67026
to me.

libstdc++-v3:
2017-06-12  Pedro Alves  

* doc/xml/manual/status_cxx2017.xml: Update C++17 constexpr
char_traits status.
* doc/html/*: Regenerate.

* include/bits/char_traits.h (_GLIBCXX_ALWAYS_INLINE): Define if
not already defined.
(__cpp_lib_constexpr_char_traits): Uncomment.
(__constant_string_p, __constant_char_array_p): New.
(std::char_traits, std::char_traits): Add
_GLIBCXX17_CONSTEXPR on compare, length and find and use
__constant_string_p, __constant_char_array_p and
__builtin_constant_p to defer to __gnu_cxx::char_traits at compile
time.

* testsuite/21_strings/char_traits/requirements/
constexpr_functions_c++17.cc: Uncomment
__cpp_lib_constexpr_char_traits tests.  Uncomment
test_compare, test_length, test_find,
test_compare, test_length and test_find
static_assert tests.

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/doc/html/manual/status.html
branches/gcc-7-branch/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
branches/gcc-7-branch/libstdc++-v3/include/bits/char_traits.h
   
branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/char_traits/requirements/constexpr_functions_c++17.cc

[Bug libstdc++/80704] Error while invoking `string_view::string_view(const char*)` in a `constexpr` context

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|8.0 |7.3

--- Comment #2 from Jonathan Wakely  ---
Now also fixed for 7.3

[Bug target/81422] [aarch64] internal compiler error: in update_equiv_regs, at ira.c:3425

[qing.zhao at oracle dot com]

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

Qing Zhao  changed:

   What|Removed |Added

 CC||qing.zhao at oracle dot com

--- Comment #2 from Qing Zhao  ---
I can repeat this bug on aarch64 machine with the latest gcc.
I am taking a deeper study on this one now. let me know if you are currently
working on the fix of this one.

[Bug tree-optimization/82192] gcc produces incorrect code with -O2 and bit-field

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
On Tue, 12 Sep 2017, vsevolod.livinskij at frtk dot ru wrote:

> struct struct_t {
> unsigned int memb : 13;
> };
> 
> extern struct_t b;

> printf("%llu\n", b.memb);

unsigned int : 13 (promoted to int - I think C++ promotes 
narrower-than-int bit-fields to int, though for C++ the bit-field width is 
not considered part of the type) is not valid for printf %llu.  You need 
to explicitly cast to unsigned long long.

[Bug c/80942] -Woverlength-strings should no longer be implied by -Wpedantic

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
On Tue, 12 Sep 2017, vincent-gcc at vinc17 dot net wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80942
> 
> --- Comment #4 from Vincent Lefèvre  ---
> (In reply to jos...@codesourcery.com from comment #2)
> > The documentation explicitly says -Wpedantic includes some warnings about 
> > things outside of ISO C, beyond those that violate syntax rules or 
> > constraints.
> 
> This is not what is documented:
> 
> Issue all the warnings demanded by strict ISO C and ISO C++; reject
> all programs that use forbidden extensions, and some other programs
> that do not follow ISO C and ISO C++.  For ISO C, follows the
> version of the ISO C standard specified by any -std option used.

I consider this to be within the "some other programs".  The question, I 
suppose, is whether implementation limits should be moved out of the scope 
of -Wpedantic.

[Bug tree-optimization/82192] gcc produces incorrect code with -O2 and bit-field

[vsevolod.livinskij at frtk dot ru]

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

--- Comment #2 from Vsevolod Livinskiy  ---
(In reply to Andrew Pinski from comment #1)
> Does -fsantize=undefined show anything?
> 
> I am suspecting you have undefined behavior with respect to the shift.

Test doesn't contain undefined behavior, and sanitizer verifies it.
(7227976781724269559 | a & ~3739384568U) gives 7227976781724531703, and
(7227976781724269559 | a & ~3739384568U) - 7227976781724531672 gives 31, 
so shift is OK.

[Bug target/80204] macosx-version-min wrong for macOS Sierra 10.12.3

[law at gcc dot gnu.org]

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

--- Comment #4 from Jeffrey A. Law  ---
Author: law
Date: Tue Sep 12 15:29:16 2017
New Revision: 252029

URL: https://gcc.gnu.org/viewcvs?rev=252029=gcc=rev
Log:
PR target/80204
* config/darwin-driver.c (darwin_find_version_from_kernel): Eliminate
calculation of the minor version, always output as 0.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/darwin-driver.c

[Bug target/82112] internal compiler error: in fold_convert_loc, at fold-const.c:2262

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 12 15:25:15 2017
New Revision: 252028

URL: https://gcc.gnu.org/viewcvs?rev=252028=gcc=rev
Log:
PR target/82112
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): For
ALTIVEC_BUILTIN_VEC_LD if arg1 has array type call default_conversion
on it early, rather than manual conversion late.  For
ALTIVEC_BUILTIN_VEC_ST if arg2 has array type call default_conversion
instead of performing manual conversion.

* gcc.target/powerpc/pr82112.c: New test.
* g++.dg/ext/altivec-18.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/altivec-18.C
trunk/gcc/testsuite/gcc.target/powerpc/pr82112.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-c.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/82192] gcc produces incorrect code with -O2 and bit-field

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Does -fsantize=undefined show anything?

I am suspecting you have undefined behavior with respect to the shift.

[Bug tree-optimization/82192] New: gcc produces incorrect code with -O2 and bit-field

[vsevolod.livinskij at frtk dot ru]

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

Bug ID: 82192
   Summary: gcc produces incorrect code with -O2 and bit-field
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

gcc produces incorrect code with -O2 and higher and unsigned int : 13 bit-field

>$ g++ -O2 driver.cpp func.cpp ; ./a.out 
6930

>$ g++ -O0 driver.cpp func.cpp ; ./a.out 
0

>$ cat init.h 
extern const unsigned long int a;

struct struct_t {
unsigned int memb : 13;
};

extern struct_t b;

>$ cat driver.cpp 
#include 
#include "init.h"

const unsigned long int a = 10798855141994013410UL;

struct_t b;

extern void foo ();

int main () {
foo ();
printf("%llu\n", b.memb);
return 0;
}

>$ cat func.cpp 
#include "init.h"
void foo() {
  b.memb = unsigned(a) >> (7227976781724269559 | a & ~3739384568U) -
7227976781724531672;
}

>$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/gcc-dev/bin-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /gcc-dev/trunk/configure --prefix=/gcc-dev/bin-trunk
--disable-bootstrap
Thread model: posix
gcc version 8.0.0 20170912 (Rev. 252003) (GCC)

[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

--- Comment #5 from Richard Biener  ---
Trying

Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c   (revision 252006)
+++ gcc/gimple-fold.c   (working copy)
@@ -3862,24 +3862,18 @@ gimple_fold_call (gimple_stmt_iterator *
  tree fndecl = builtin_decl_implicit (BUILT_IN_UNREACHABLE);
  gimple *new_stmt = gimple_build_call (fndecl, 0);
  gimple_set_location (new_stmt, gimple_location (stmt));
+ /* If the call had a SSA name as lhs morph that into
+an uninitialized value.  */
  if (lhs && TREE_CODE (lhs) == SSA_NAME)
{
  tree var = create_tmp_var (TREE_TYPE (lhs));
- tree def = get_or_create_ssa_default_def (cfun, var);
-
- /* To satisfy condition for
-cgraph_update_edges_for_call_stmt_node,
-we need to preserve GIMPLE_CALL statement
-at position of GSI iterator.  */
- update_call_from_tree (gsi, def);
- gsi_insert_before (gsi, new_stmt, GSI_NEW_STMT);
-   }
- else
-   {
- gimple_set_vuse (new_stmt, gimple_vuse (stmt));
- gimple_set_vdef (new_stmt, gimple_vdef (stmt));
- gsi_replace (gsi, new_stmt, false);
+ SET_SSA_NAME_VAR_OR_IDENTIFIER (lhs, var);
+ SSA_NAME_DEF_STMT (lhs) = gimple_build_nop ();
+ set_ssa_default_def (cfun, var, lhs);
}
+ gimple_set_vuse (new_stmt, gimple_vuse (stmt));
+ gimple_set_vdef (new_stmt, gimple_vdef (stmt));
+ gsi_replace (gsi, new_stmt, false);
  return true;
}
}

[Bug tree-optimization/82191] [8 Regression] ICE: Segmentation fault (in verify_use)

[rguenther at suse dot de]

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

--- Comment #2 from rguenther at suse dot de  ---
On Tue, 12 Sep 2017, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82191
> 
> Martin Liška  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2017-09-12
>  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  ---
> Started with r251798.

Likely dup of PR82157

> BT:
> gcc pr82191.c -O2 -c
> during GIMPLE pass: pre
> pr82191.c: In function ‘cg’:
> pr82191.c:5:1: internal compiler error: Segmentation fault
>  cg (int *tc, int y2)
>  ^~
> 0xc2d05b crash_signal
> ../../gcc/toplev.c:341
> 0xe66288 gimple_code
> ../../gcc/gimple.h:1678
> 0xe67281 gimple_nop_p
> ../../gcc/gimple.h:6276
> 0xe6a51d verify_use
> ../../gcc/tree-ssa.c:863
> 0xe6b2dc verify_ssa(bool, bool)
> ../../gcc/tree-ssa.c:1141
> 0xb495c7 execute_function_todo
> ../../gcc/passes.c:1999
> 0xb4a4f2 execute_todo
> ../../gcc/passes.c:2046
> 
>

[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

 CC||hubicka at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
Testing the attached but I expect it'll not work as the updating in
cgraph_update_edges_for_call_stmt_node seems to expect a 1:1 "folding".

It does look fragile as hell...

I guess I'll finally go and make SSA_NAME_DEFAULT_DEF possible on anon
SSA names which means we can avoid that extra stmt in folding...

[Bug testsuite/82114] gcc.dg/gimplefe-14.c for bare metal and argc is 0

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail||7.2.0

--- Comment #3 from Martin Liška  ---
Fixed on trunk so far.

[Bug testsuite/82114] gcc.dg/gimplefe-14.c for bare metal and argc is 0

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Tue Sep 12 14:32:39 2017
New Revision: 252024

URL: https://gcc.gnu.org/viewcvs?rev=252024=gcc=rev
Log:
Fix GIMPLE FE test (PR testsuite/82114)

2017-09-12  Martin Liska  

PR testsuite/82114
* gcc.dg/gimplefe-14.c (main): Add handling of case 0.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/gimplefe-14.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

--- Comment #3 from Richard Biener  ---
Hmm, causes

Running /tmp/trunk/gcc/testsuite/g++.dg/dg.exp ...
FAIL: g++.dg/ipa/pr65263.C  -std=gnu++98 (internal compiler error)
FAIL: g++.dg/ipa/pr65263.C  -std=gnu++98 (test for excess errors)
FAIL: g++.dg/ipa/pr65263.C  -std=gnu++11 (internal compiler error)
FAIL: g++.dg/ipa/pr65263.C  -std=gnu++11 (test for excess errors)
FAIL: g++.dg/ipa/pr65263.C  -std=gnu++14 (internal compiler error)
FAIL: g++.dg/ipa/pr65263.C  -std=gnu++14 (test for excess errors)

=== g++ Summary ===

# of unexpected failures6

/tmp/trunk/gcc/testsuite/g++.dg/ipa/pr65263.C: In member function 'int
D::F::operator()() const':^M
/tmp/trunk/gcc/testsuite/g++.dg/ipa/pr65263.C:42:5: internal compiler error:
Segmentation fault^M
0x11cea13 crash_signal^M
/tmp/trunk/gcc/toplev.c:341^M
0xc6da67 compute_call_stmt_bb_frequency(tree_node*, basic_block_def*)^M
/tmp/trunk/gcc/cgraphbuild.c:195^M
0xc677e4 cgraph_node::verify_node()^M
/tmp/trunk/gcc/cgraph.c:3244^M
0xc564a9 symtab_node::verify()^M
/tmp/trunk/gcc/symtab.c:1204^M

where a callgraph edge references a removed stmt (the folded call).  Because

static void
cgraph_update_edges_for_call_stmt_node (cgraph_node *node,
gimple *old_stmt, tree old_call,
gimple *new_stmt)
{
  tree new_call = (new_stmt && is_gimple_call (new_stmt))
  ? gimple_call_fndecl (new_stmt) : 0;

  /* We are seeing indirect calls, then there is nothing to update.  */
  if (!new_call && !old_call)
return;

we turned an indirect call into a non-call (the LHS effect of it after
a __builtin_unreachable ()).

Testing an updated patch.

[Bug tree-optimization/82191] [8 Regression] ICE: Segmentation fault (in verify_use)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-12
 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  ---
Started with r251798.

BT:
gcc pr82191.c -O2 -c
during GIMPLE pass: pre
pr82191.c: In function ‘cg’:
pr82191.c:5:1: internal compiler error: Segmentation fault
 cg (int *tc, int y2)
 ^~
0xc2d05b crash_signal
../../gcc/toplev.c:341
0xe66288 gimple_code
../../gcc/gimple.h:1678
0xe67281 gimple_nop_p
../../gcc/gimple.h:6276
0xe6a51d verify_use
../../gcc/tree-ssa.c:863
0xe6b2dc verify_ssa(bool, bool)
../../gcc/tree-ssa.c:1141
0xb495c7 execute_function_todo
../../gcc/passes.c:1999
0xb4a4f2 execute_todo
../../gcc/passes.c:2046

[Bug tree-optimization/82042] signed integer overflow in ao_ref_init_from_ptr_and_size

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
I see, thanks for clarification. I'm going to send patch for the remaining
bits, hopefully I made it in a right way.

[Bug tree-optimization/82157] [8 Regression] ICE on valid code at -O2 and -O3: cannot update SSA form

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug tree-optimization/82157] [8 Regression] ICE on valid code at -O2 and -O3: cannot update SSA form

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 12 14:15:37 2017
New Revision: 252020

URL: https://gcc.gnu.org/viewcvs?rev=252020=gcc=rev
Log:
2017-09-12  Richard Biener  

PR tree-optimization/82157
* tree-ssa-pre.c (remove_dead_inserted_code): Do not remove
stmts with side-effects.

* gcc.dg/torture/pr82157.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr82157.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug sanitizer/77631] no symbols in backtrace shown by ASan when debug info is split

[ian at airs dot com]

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

--- Comment #12 from Ian Lance Taylor  ---
I don't think this is a dup of 67165, which is about compressed debug sections.
 This PR is about debug info in separate files.

[Bug libstdc++/79433] __has_include() is true but #include gives #error when -std=old

[redi at gcc dot gnu.org]

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

--- Comment #26 from Jonathan Wakely  ---
Author: redi
Date: Tue Sep 12 14:03:06 2017
New Revision: 252019

URL: https://gcc.gnu.org/viewcvs?rev=252019=gcc=rev
Log:
PR libstdc++/79433 no #error for including TS headers with wrong -std

PR libstdc++/79433
* include/Makefile.am: Remove .
* include/Makefile.in: Regenerate.
* include/bits/c++14_warning.h: Remove.
* include/experimental/algorithm: Do not include .
* include/experimental/any: Likewise.
* include/experimental/array: Likewise.
* include/experimental/bits/erase_if.h: Likewise.
* include/experimental/bits/lfts_config.h: Likewise.
* include/experimental/bits/shared_ptr.h: Likewise.
* include/experimental/bits/string_view.tcc: Likewise.
* include/experimental/chrono: Likewise.
* include/experimental/deque: Likewise.
* include/experimental/filesystem: Do not include .
* include/experimental/forward_list: Do not include .
* include/experimental/functional: Likewise.
* include/experimental/iterator: Likewise.
* include/experimental/list: Likewise.
* include/experimental/map: Likewise.
* include/experimental/memory: Likewise.
* include/experimental/numeric: Likewise.
* include/experimental/optional: Likewise.
* include/experimental/propagate_const: Likewise.
* include/experimental/ratio: Likewise.
* include/experimental/regex: Likewise.
* include/experimental/set: Likewise.
* include/experimental/string: Likewise.
* include/experimental/string_view: Likewise.
* include/experimental/system_error: Likewise.
* include/experimental/tuple: Likewise.
* include/experimental/type_traits: Likewise.
* include/experimental/unordered_map: Likewise.
* include/experimental/unordered_set: Likewise.
* include/experimental/vector: Likewise.
* testsuite/experimental/any/misc/any_cast_neg.cc: Adjust dg-error
line number.
* testsuite/experimental/array/neg.cc: Likewise.
* testsuite/experimental/propagate_const/assignment/move_neg.cc:
Likewise.
* testsuite/experimental/propagate_const/cons/move_neg.cc: Likewise.
* testsuite/experimental/propagate_const/requirements2.cc: Likewise.
* testsuite/experimental/propagate_const/requirements3.cc: Likewise.
* testsuite/experimental/propagate_const/requirements4.cc: Likewise.
* testsuite/experimental/propagate_const/requirements5.cc: Likewise.

Removed:
trunk/libstdc++-v3/include/bits/c++14_warning.h
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/Makefile.am
trunk/libstdc++-v3/include/Makefile.in
trunk/libstdc++-v3/include/experimental/algorithm
trunk/libstdc++-v3/include/experimental/any
trunk/libstdc++-v3/include/experimental/array
trunk/libstdc++-v3/include/experimental/bits/erase_if.h
trunk/libstdc++-v3/include/experimental/bits/lfts_config.h
trunk/libstdc++-v3/include/experimental/bits/shared_ptr.h
trunk/libstdc++-v3/include/experimental/bits/string_view.tcc
trunk/libstdc++-v3/include/experimental/chrono
trunk/libstdc++-v3/include/experimental/deque
trunk/libstdc++-v3/include/experimental/filesystem
trunk/libstdc++-v3/include/experimental/forward_list
trunk/libstdc++-v3/include/experimental/functional
trunk/libstdc++-v3/include/experimental/iterator
trunk/libstdc++-v3/include/experimental/list
trunk/libstdc++-v3/include/experimental/map
trunk/libstdc++-v3/include/experimental/memory
trunk/libstdc++-v3/include/experimental/numeric
trunk/libstdc++-v3/include/experimental/optional
trunk/libstdc++-v3/include/experimental/propagate_const
trunk/libstdc++-v3/include/experimental/ratio
trunk/libstdc++-v3/include/experimental/regex
trunk/libstdc++-v3/include/experimental/set
trunk/libstdc++-v3/include/experimental/string
trunk/libstdc++-v3/include/experimental/string_view
trunk/libstdc++-v3/include/experimental/system_error
trunk/libstdc++-v3/include/experimental/tuple
trunk/libstdc++-v3/include/experimental/type_traits
trunk/libstdc++-v3/include/experimental/unordered_map
trunk/libstdc++-v3/include/experimental/unordered_set
trunk/libstdc++-v3/include/experimental/vector
trunk/libstdc++-v3/testsuite/experimental/any/misc/any_cast_neg.cc
trunk/libstdc++-v3/testsuite/experimental/array/neg.cc
   
trunk/libstdc++-v3/testsuite/experimental/propagate_const/assignment/move_neg.cc
trunk/libstdc++-v3/testsuite/experimental/propagate_const/cons/move_neg.cc
trunk/libstdc++-v3/testsuite/experimental/propagate_const/requirements2.cc
trunk/libstdc++-v3/testsuite/experimental/propagate_const/requirements3.cc

[Bug libstdc++/79433] __has_include() is true but #include gives #error when -std=old

[redi at gcc dot gnu.org]

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

--- Comment #25 from Jonathan Wakely  ---
Author: redi
Date: Tue Sep 12 14:02:59 2017
New Revision: 252018

URL: https://gcc.gnu.org/viewcvs?rev=252018=gcc=rev
Log:
PR libstdc++/79433 no #error for including headers with wrong -std

PR libstdc++/79433
* doc/xml/manual/status_cxx2017.xml: Update feature-test macros.
* doc/html/*: Regenerate.
* include/Makefile.am: Remove .
* include/Makefile.in: Regenerate.
* include/bits/c++17_warning.h: Remove.
* include/bits/string_view.tcc: Do not include 
for pre-C++17 modes.
* include/std/any: Likewise.
(__cpp_lib_any): Define.
* include/std/mutex (__cpp_lib_scoped_lock): Adjust value as per new
SD-6 draft.
* include/std/numeric (__cpp_lib_gcd_lcm): Define as per new SD-6
draft.
* include/std/optional: Do not include .
(__cpp_lib_optional): Define.
* include/std/shared_mutex: Do not include .
* include/std/string_view: Do not include .
(__cpp_lib_string_view): Define.
* include/std/variant: Do not include .
(__cpp_lib_variant): Define.
* testsuite/20_util/optional/cons/value_neg.cc: Adjust dg-error line
numbers.
* testsuite/26_numerics/gcd/1.cc: Test for __cpp_lib_gcd_lcm.
* testsuite/26_numerics/gcd/gcd_neg.cc: Adjust dg-error line
numbers.
* testsuite/26_numerics/lcm/1.cc: Test for __cpp_lib_gcd_lcm.
* testsuite/26_numerics/lcm/lcm_neg.cc: Adjust dg-error line
numbers.
* testsuite/30_threads/scoped_lock/requirements/typedefs.cc: Adjust
expected value of __cpp_lib_scoped_lock.

Removed:
trunk/libstdc++-v3/include/bits/c++17_warning.h
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
trunk/libstdc++-v3/include/Makefile.am
trunk/libstdc++-v3/include/Makefile.in
trunk/libstdc++-v3/include/bits/string_view.tcc
trunk/libstdc++-v3/include/std/any
trunk/libstdc++-v3/include/std/mutex
trunk/libstdc++-v3/include/std/numeric
trunk/libstdc++-v3/include/std/optional
trunk/libstdc++-v3/include/std/shared_mutex
trunk/libstdc++-v3/include/std/string_view
trunk/libstdc++-v3/include/std/variant
trunk/libstdc++-v3/testsuite/20_util/optional/cons/value_neg.cc
trunk/libstdc++-v3/testsuite/26_numerics/gcd/1.cc
trunk/libstdc++-v3/testsuite/26_numerics/gcd/gcd_neg.cc
trunk/libstdc++-v3/testsuite/26_numerics/lcm/1.cc
trunk/libstdc++-v3/testsuite/26_numerics/lcm/lcm_neg.cc
   
trunk/libstdc++-v3/testsuite/30_threads/scoped_lock/requirements/typedefs.cc

[Bug target/82185] ICE: Segmentation fault in expand_binop gcc/optabs.c:1137

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||rsandifo at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Patch applied.  Thanks for tracking down the problem and sorry for the
breakage.

[Bug testsuite/82132] 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

--- Comment #2 from Eric Gallager  ---
(In reply to Richard Biener from comment #1)
> There is no "builtin" for this, the link fail will not go away.
> 

Really? You did  r207595 yourself, which is the revision that bug 65244 comment
11 said added it...

[Bug libstdc++/70483] string_view::compare and coparision operators are not constexpr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |7.3

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk for both std::experimental::basic_string_view and
std::basic_string_view

[Bug libstdc++/70483] string_view::compare and coparision operators are not constexpr

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue Sep 12 13:31:20 2017
New Revision: 252017

URL: https://gcc.gnu.org/viewcvs?rev=252017=gcc=rev
Log:
PR libstdc++/70483 make std::experimental::string_view fully constexpr

PR libstdc++/70483
* include/experimental/bits/string_view.tcc (basic_string_view::find)
(basic_string_view::rfind, basic_string_view::find_first_of)
(basic_string_view::find_last_of, basic_string_view::find_first_not_of)
(basic_string_view::find_last_not_of): Add constexpr specifier.
* include/experimental/string_view (basic_string_view::remove_prefix)
(basic_string_view::remove_suffix, basic_string_view::swap)
(basic_string_view::compare, basic_string_view::find)
(basic_string_view::rfind, basic_string_view::find_first_of)
(basic_string_view::find_last_of, basic_string_view::find_first_not_of)
(basic_string_view::find_last_not_of, operator==, operator!=)
(operator<, operator>, operator<=, operator>=): Likewise.
* testsuite/experimental/string_view/operations/compare/char/70483.cc:
New.

Added:
   
trunk/libstdc++-v3/testsuite/experimental/string_view/operations/compare/char/70483.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/experimental/bits/string_view.tcc
trunk/libstdc++-v3/include/experimental/string_view

[Bug target/82185] ICE: Segmentation fault in expand_binop gcc/optabs.c:1137

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Tue Sep 12 13:27:13 2017
New Revision: 252008

URL: https://gcc.gnu.org/viewcvs?rev=252008=gcc=rev
Log:
PR81285: Fix uninitialised variable in emit_store_flag_int

2017-09-12  Richard Sandiford  

gcc/
PR rtl-optimization/82185
* expmed.c (emit_store_flag_int): Only test tem if it has been
initialized.

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

[Bug middle-end/82149] match.pd: 2919: bad if test ?

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 12 13:21:52 2017
New Revision: 252007

URL: https://gcc.gnu.org/viewcvs?rev=252007=gcc=rev
Log:
2017-09-12  Richard Biener  

PR middle-end/82149
* match.pd ((FTYPE) N CMP CST): Fix typo.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd

[Bug middle-end/82149] match.pd: 2919: bad if test ?

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug tree-optimization/82042] signed integer overflow in ao_ref_init_from_ptr_and_size

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Mon, 11 Sep 2017, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82042
> 
> Martin Liška  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2017-09-11
>  CC||marxin at gcc dot gnu.org,
>||rguenth at gcc dot gnu.org
>Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
> gnu.org
>  Ever confirmed|0   |1
> 
> --- Comment #2 from Martin Liška  ---
> Confirmed, I've got patch for 3/4 of ubsan errors.
> 
> The only one which is remaining is:
> 
>679  void
>680  ao_ref_init_from_ptr_and_size (ao_ref *ref, tree ptr, tree size)
>681  {
>682HOST_WIDE_INT t, size_hwi, extra_offset = 0;
>683ref->ref = NULL_TREE;
>684if (TREE_CODE (ptr) == SSA_NAME)
>685  {
>686gimple *stmt = SSA_NAME_DEF_STMT (ptr);
>687if (gimple_assign_single_p (stmt)
>688&& gimple_assign_rhs_code (stmt) == ADDR_EXPR)
>689  ptr = gimple_assign_rhs1 (stmt);
>690else if (is_gimple_assign (stmt)
>691 && gimple_assign_rhs_code (stmt) == POINTER_PLUS_EXPR
>692 && TREE_CODE (gimple_assign_rhs2 (stmt)) == 
> INTEGER_CST)
>693  {
>694ptr = gimple_assign_rhs1 (stmt);
>695extra_offset = BITS_PER_UNIT
>696   * int_cst_value (gimple_assign_rhs2 (stmt));
>697  }
>698  }
>699  
>700if (TREE_CODE (ptr) == ADDR_EXPR)
>701  {
>702ref->base = get_addr_base_and_unit_offset (TREE_OPERAND (ptr, 
> 0),
> );
>703if (ref->base)
>704  ref->offset = BITS_PER_UNIT * t;
>705else
> 
> Where offset should be probably offset_int type, which is not for free.
> Or do we have a special value for such case Richi?

Yeah, this is a know deficiency in ao_ref 'offset' (and also size and
maxsize).  Blowing up to offset_int isn't really a good idea.  size
and max_size have -1 as "unknown" but offset doesn't really have
such value and "failing" isn't an option for the alias machinery.

I've long thought about making ao_ref byte precision but that loses
bit-level disambiguation we get into with bitfield stores/loads so
I "postponed" that to until we (finally) get bitfield load/store 
lowering...

The issue is long-standing so I think we can just leave it that way...

[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Mon, 11 Sep 2017, wilco at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82004
> 
> Wilco  changed:
> 
>What|Removed |Added
> 
>  CC||wilco at gcc dot gnu.org
> 
> --- Comment #10 from Wilco  ---
> Using latest GLIBC, exp(log(10),-3) is only 3ULP different from 0.001. Since
> (double)0.001 is rounded up, any <1ULP POW implementation could round down and
> fail the test. So yes the first element in chlcnc really needs to be fixed to
> 0.00099 to allow for a few ULP of error in POW.
> 
> > As a last resort we can always choose to not touch 10**x
> 
> Unfortunately almost all useful cases are 10**x... So it would be great if we
> can allow use of exp10 and exp2 to get more accurate results. This requires a
> real implementation in GLIBC, and a way to disable it. Would it be feasible to
> add a exp10 symbol to libgcc/libgfortran in case the math libraries don't
> support it?

Not sure, it depends on whether we can make sure libm is prefered over
libgfortran.  Maybe we have existing cases in libgfortran already.

[Bug fortran/32834] [Meta-bug] 'Fortran 95'-only failures

[dominiq at lps dot ens.fr]

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

Bug 34640 Summary: ICE when assigning item of a derived-component to a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640

   What|Removed |Added

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

[Bug fortran/56818] [meta-bug] fortran-dev bugs

[dominiq at lps dot ens.fr]

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

Bug 34640 Summary: ICE when assigning item of a derived-component to a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640

   What|Removed |Added

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

[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking

[dominiq at lps dot ens.fr]

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

Bug 34640 Summary: ICE when assigning item of a derived-component to a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640

   What|Removed |Added

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

[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #42 from Dominique d'Humieres  ---
> Most of the tests give an ICE after r251949:
> ...

Looking more carefully to what I did, it turns out that I saw the ICEs on
r251946!-(

Sorry for the noise.

[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

--- Comment #3 from Richard Biener  ---
Not yet analyzed but I see LIM performs store-motion on

[0.00%] [count: INV] [loop 5 header]:
-  *h5_26(D) = tv_24(D);
+  h5__lsm.7_18 = tv_24(D);

where I think stores from undefined SSA names could be turned into CLOBBERs.

"Fixes" the testcase.

Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c   (revision 252002)
+++ gcc/gimple-fold.c   (working copy)
@@ -410,6 +410,16 @@ fold_gimple_assign (gimple_stmt_iterator

else if (DECL_P (rhs))
  return get_symbol_constant_value (rhs);
+
+   else if (TREE_CODE (rhs) == SSA_NAME
+&& SSA_NAME_IS_DEFAULT_DEF (rhs)
+&& ! ssa_defined_default_def_p (rhs)
+&& gimple_store_p (stmt))
+ {
+   tree clobber = build_constructor (TREE_TYPE (rhs), NULL);
+   TREE_THIS_VOLATILE (clobber) = true;
+   return clobber;
+ }
   }
   break;

[Bug c++/78269] FAIL: FAIL: g++.dg/cpp1z/noexcept-type11.C and FAIL: g++.dg/cpp1z/noexcept-type9.C

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  ---
Thanks Thomas.

[Bug tree-optimization/82191] New: [8 Regression] ICE: Segmentation fault (in verify_use)

[asolokha at gmx dot com]

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

Bug ID: 82191
   Summary: [8 Regression] ICE: Segmentation fault (in verify_use)
   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-alpha20170910 snapshot (r251952) ICEs when compiling the following
snippet w/ -O2, -O3, or -Ofast:

int
w5 (void);

int
cg (int *tc, int y2)
{
  int vf = 0;

  if (w5 () / ((y2 == 0) ? 1 : 2))
tc = 

  return *tc / vf;
}

% gcc-8.0.0-alpha20170910 -O2 -c apmo3uzv.c
during GIMPLE pass: pre
apmo3uzv.c: In function 'cg':
apmo3uzv.c:5:1: internal compiler error: Segmentation fault
 cg (int *tc, int y2)
 ^~

[Bug debug/82144] [8 Regression] ICE in add_dwarf_attr with alignas

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|rguenth at gcc dot gnu.org |aoliva at gcc dot 
gnu.org

--- Comment #3 from Richard Biener  ---
Hmm, we do it twice:

static dw_die_ref
gen_enumeration_type_die (tree type, dw_die_ref context_die)
{
...
  if (TYPE_SIZE (type))
{
  tree link;

  TREE_ASM_WRITTEN (type) = 1;
  add_byte_size_attribute (type_die, type);
  add_alignment_attribute (type_die, type);
...
}
  else
add_AT_flag (type_die, DW_AT_declaration, 1);

  add_alignment_attribute (type_die, type);

  add_pubtype (type, type_die);

  return type_die;
}

not sure which one to keep.  Alex, this is now yours.

[Bug target/82112] internal compiler error: in fold_convert_loc, at fold-const.c:2262

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 12 11:49:29 2017
New Revision: 252003

URL: https://gcc.gnu.org/viewcvs?rev=252003=gcc=rev
Log:
PR target/82112
* c-common.c (sync_resolve_size): Instead of c_dialect_cxx ()
assertion check that in the condition.
(get_atomic_generic_size): Likewise.  Before testing if parameter
has pointer type, if it has array type, call for C++
default_conversion to perform array-to-pointer conversion.

* c-c++-common/pr82112.c: New test.
* gcc.dg/pr82112.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr82112.c
trunk/gcc/testsuite/gcc.dg/pr82112.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

[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

--- Comment #2 from Richard Biener  ---
Latent issue in gimple-fold.c:

Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c   (revision 252002)
+++ gcc/gimple-fold.c   (working copy)
@@ -3872,7 +3872,7 @@ gimple_fold_call (gimple_stmt_iterator *
 we need to preserve GIMPLE_CALL statement
 at position of GSI iterator.  */
  update_call_from_tree (gsi, def);
- gsi_insert_before (gsi, new_stmt, GSI_NEW_STMT);
+ gsi_insert_before (gsi, new_stmt, GSI_SAME_STMT);
}
  else
{

[Bug target/81325] -fcompare-debug failure on ppc64le

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
I believe this is a bug in find_many_sub_basic_blocks.  When looking at say:
int i;
int bar (void);

void
foo (int x)
{
 l1:
  i += 2;
  if (bar ())
goto l1;
  int a = x + 5;
  int b = x + 10;
 l2:
  i += 2;
  if (bar ())
goto l2;
}
where before cddce1 we have at -O2 -g:
...
goto ; [INV] [count: INV]
...
   [0.00%] [count: INV]:
  a_13 = x_12(D) + 5;
  # DEBUG a => a_13
  b_14 = x_12(D) + 10;
  # DEBUG b => b_14

   [0.00%] [count: INV]:
l2:
and cddce1 decides to remove the unused a_13 and b_14, we just kill the
forwarder block bb 5 and the debug stmts are dropped on the floor (which is
unfortunate and on this testcase actually it wouldn't be impossible to move the
debug stmts to the following block if the underlying vars are not mentioned in
that loop and there are no debug stmts for that either, but we don't go that
far).
CCing Alex, because this is a nice example where debug stmts as well as
frontier stmts are dropped on the floor.
Anyway, I believe at least for now find_many_sub_basic_blocks should just throw
away sequences of debug stmts in between an instruction that must end a basic
block and instruction that must start a basic block.

[Bug target/82150] Produces a branch prefetch which causes a hang

[david.welch at netronome dot com]

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

--- Comment #3 from david.welch at netronome dot com ---
The problem exists as well with ldr pc,[something].  I have not dug through gcc
but did some compilation experiments, not nearly enough to be 100% sure, but
for switch statements the code generated always appears to do a comparison
(perhaps after a subtract or other modification, an ldrls pc,[], then an
unconditional branch to deal with the last item (or a default).  If that is
always the rule that is safe.  And for a function table, an array of function
pointers, it did the math using gprs and then a mov lr,pc ; bx rn.

an 

ldr pc,[]
literal pool data

will cause this undesired prefetch.

[Bug sanitizer/82116] "nested bug in the same thread" when a bug is found while reporting another one

[dvyukov at google dot com]

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

Dmitry Vyukov  changed:

   What|Removed |Added

 CC||dvyukov at google dot com

--- Comment #2 from Dmitry Vyukov  ---
Filed upstream bug:
https://github.com/google/sanitizers/issues/858
We can close this (or leave to track fix backport).

[Bug target/82190] New: Possibly latent miscompilation issue on ppc64le-linux-gnu for memcpy-bi.c with -fweb -fno-optimize-strlen

[prathamesh3492 at gcc dot gnu.org]

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

Bug ID: 82190
   Summary: Possibly latent miscompilation issue on
ppc64le-linux-gnu for memcpy-bi.c with -fweb
-fno-optimize-strlen
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42159
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42159=edit
Reduced from memcpy-bi.c

Hi,
I am working on type-promotion patch
(https://gcc.gnu.org/ml/gcc/2017-09/msg00024.html), which miscompiles
memcpy-bi.c on ppc64le-linux-gnu.
After some investigation it seems this is possibly a latent issue on the
target.

It can be reproduced for the attached test-case on pristine trunk (tested with
r250395) with following options: -fno-optimize-strlen -fweb 

The issue seems to be that strlen pass transforms
__builtin_memcmp (dst, src, n) != 0
to __builtin_memcmp_eq(dst, src, n) != 0.
Inhibiting the above transform by disabling strlen pass, somehow interferes
with web pass, which ends up calling abort() while executing
the test-case.

$ ../bootstrap-build/gcc/xgcc -B ../bootstrap-build/gcc -O2
-fno-optimize-strlen -fweb foo.c
$ ./a.out 
Aborted

The test-case is compiled correctly if strlen pass is enabled with web
pass.

Thanks,
Prathamesh

[Bug tree-optimization/82189] Two stage SLP needed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-12
 CC||rguenth at gcc dot gnu.org
 Blocks||53947
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I think what is missing is merging of two "vectors", aka, permutations of
different load chains:

  /* Grouped store or load.  */
  if (STMT_VINFO_GROUPED_ACCESS (vinfo_for_stmt (stmt)))
{
  if (REFERENCE_CLASS_P (lhs))
{
  /* Store.  */
  ;
}
  else
{
  /* Load.  */
  first_load = GROUP_FIRST_ELEMENT (vinfo_for_stmt (stmt));
  if (prev_first_load)
{
  /* Check that there are no loads from different interleaving
 chains in the same node.  */
  if (prev_first_load != first_load)
{
  if (dump_enabled_p ())
{
  dump_printf_loc (MSG_MISSED_OPTIMIZATION,
   vect_location,
   "Build SLP failed: different "
   "interleaving chains in one node ");
  dump_gimple_stmt (MSG_MISSED_OPTIMIZATION, TDF_SLIM,
stmt, 0);
}
  /* Mismatch.  */
  continue;

this is because we do not have a suitable way to represent those at the
moment.  So we split the store group and get the two element vectorization.

As we don't have a good intermediate representation for SLP at the moment
we can't really perfomr post-detection "optimization" on the SLP tree.

unified autovect to the rescue...


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/82188] Missed optimization opportunity for constant folding

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/82187] missed PRE at -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-12
 CC||rguenth at gcc dot gnu.org
Summary|missing optimization|missed PRE at -O3
   |pointer to char*|
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I see with -O2:
.L4:
movzbl  (%rax), %edx
cmpb$97, %dl
je  .L5
.L2:
addq$1, %rax
testb   %dl, %dl
jne .L4
xorl%eax, %eax
ret
.L5:
movl$1, %eax
ret

so a single load in the loop.  Something messes up at -O3.

[Bug c/82186] [7/8 Regression] ICE (segfault), VLA type with inlining

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Component|tree-optimization   |c

--- Comment #2 from Richard Biener  ---
Another instance of the C FE missing a DECL_EXPR.

[Bug fortran/82184] [8 Regression] 187.facerec in SPEC CPU 2000 miscompares

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug middle-end/82177] Alias analysis too aggressive with integer-to-pointer cast

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||alias
 CC||rguenth at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
This is a dup of another PR which I can't find right now.  GCC handles
pointer-to-integer casts just fine.  What it doesn't is creating alias
relationship
by relational tests (! n) but at the same time it sometimes propagates
conditional equivalences (that's not the issue in your case I think).

As said in that PR an incomplete fix would be to do sth like

Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c  (revision 251997)
+++ gcc/tree-ssa-structalias.c  (working copy)
@@ -4954,6 +4954,19 @@ find_func_aliases (struct function *fn,
make_escape_constraint (rhsop);
}
 }
+  else if (gcond *cond = dyn_cast  (t))
+{
+  if ((gimple_cond_code (cond) == EQ_EXPR
+  || gimple_cond_code (cond) == NE_EXPR)
+ && TREE_CODE (gimple_cond_rhs (cond)) == SSA_NAME)
+   {
+ auto_vec rhs1c;
+ auto_vec rhs2c;
+ get_constraint_for_rhs (gimple_cond_lhs (cond), );
+ get_constraint_for_rhs (gimple_cond_rhs (cond), );
+ process_all_all_constraints (rhs1c, rhs2c);
+   }
+}
   /* Handle escapes through return.  */
   else if (gimple_code (t) == GIMPLE_RETURN
   && gimple_return_retval (as_a  (t)) != NULL_TREE)

the effect on the number of constraints and optimization is unknown.

Incomplete because the above doesn't handle other ways of relating things.
The compare might be in an external function and thus not visible to GCC
at all.  Which means we must assume that all pointers that escaped the
current function might actually point to the same thing if a function
call happens (and the result is in any way used in a conditional).

You can workaround GCCs "deficiency" by using -fno-tree-pta.

[Bug tree-optimization/82188] Missed optimization opportunity for constant folding

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
There are a few different missed optimizations here that GCC does not do but
LLVM does:

* 1/(2U-x) != 0 is the same as x != 1

* 0!=x/2 is the same as x >= -1 && x <= 1

[Bug target/82175] [8 Regression] -march=native fails on armv7 big/little system armv7l-unknown-linux-gnueabihf with gcc 8.0.0

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |8.0
Summary|-march=native fails on  |[8 Regression]
   |armv7 big/little system |-march=native fails on
   |armv7l-unknown-linux-gnueab |armv7 big/little system
   |ihf with gcc 8.0.0  |armv7l-unknown-linux-gnueab
   ||ihf with gcc 8.0.0

[Bug c++/82165] Operator overloading doesn't work with enum bit fields

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
IIRC bitfield rvalues get promoted to 'int' before overload resolution applies
but I may be wrong.  enum bitfields may also be a GNU extension.