[Bug c++/81513] New: __has_cpp_attribute returns non-zero in C++03 mode, but attributes don't work

[proski at gnu dot org]

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

Bug ID: 81513
   Summary: __has_cpp_attribute returns non-zero in C++03 mode,
but attributes don't work
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: proski at gnu dot org
  Target Milestone: ---

Following compiles with "g++ -Wall -std=c++03 test.cpp -o test" and outputs
"200809 201603 199711"

#include 
int main()
{
  std::cout << __has_cpp_attribute(noreturn) << ' ' <<
__has_cpp_attribute(maybe_unused) << ' ' << __cplusplus << '\n';
}

[[maybe_unused]] doesn't work in C++03 mode in g++. It does work in C++11 mode,
despite it being a C++17 feature. In C++11 mode, __cplusplus would be less than
__has_cpp_attribute(maybe_unused), yet [[maybe_unused]] would work.

With clang-4.0 in C++03 mode, the output is "0 0 199711". I believe GCC should
do the same. If attributes are not supported at all, __has_cpp_attribute()
should return 0.

I want to do following without special casing GCC or older standards:

#if defined(__has_cpp_attribute) && __has_cpp_attribute(maybe_unused)
#define __maybe_unused [[maybe_unused]]
#endif

[Bug target/81504] [7/8 Regression] gcc-7 regression: vec_st in loop misoptimized

[zoltan at hidvegi dot com]

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

--- Comment #1 from Zoltan Hidvegi  ---
This may not be a gcc-7 regression, my application fails even with gcc-6, even
with -O1 when I use vec_ld and vec_st, but works if I replace them with vec_xl
and vec_xst, and also works when I replace it with inline assembly generating
lvx / stvx. This particular example works with gcc-6 or gcc-7 -O1, probably
gcc-7 -O2 creates the right condition for the misoptimization to happen. I will
try to distill down a simple example that shows the bug with gcc-6 but it'll
take a wile. But maybe this example will be enough to show the root cause for
someone who knows where to look.

[Bug bootstrap/45928] genattrtab is too slow.

[jay.krell at cornell dot edu]

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

--- Comment #4 from Jay  ---
Sorry wrong thread.

On Fri, Jul 21, 2017 at 4:09 PM Jay  wrote:

> The ifndef pid_t makes it a little unconvincing. I'll see if I can find my
> "sysroot".
>
> On Fri, Jul 21, 2017 at 9:42 AM egallager at gcc dot gnu.org <
> gcc-bugzi...@gcc.gnu.org> wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45928
>>
>> Eric Gallager  changed:
>>
>>What|Removed |Added
>>
>> 
>>  Status|UNCONFIRMED |NEW
>>Last reconfirmed||2017-07-21
>>  CC||egallager at gcc dot
>> gnu.org
>>  Ever confirmed|0   |1
>>
>> --- Comment #2 from Eric Gallager  ---
>> (In reply to Andrew Pinski from comment #1)
>> > Yes it is slow in 4.5.x.  It has been speed up on the trunk already.
>>
>> I remember it being slow in more recent builds I've done from trunk, too,
>> so
>> I'm confirming this bug.
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.
>
>

[Bug bootstrap/45928] genattrtab is too slow.

[jay.krell at cornell dot edu]

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

--- Comment #3 from Jay  ---
The ifndef pid_t makes it a little unconvincing. I'll see if I can find my
"sysroot".

On Fri, Jul 21, 2017 at 9:42 AM egallager at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45928
>
> Eric Gallager  changed:
>
>What|Removed |Added
>
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2017-07-21
>  CC||egallager at gcc dot
> gnu.org
>  Ever confirmed|0   |1
>
> --- Comment #2 from Eric Gallager  ---
> (In reply to Andrew Pinski from comment #1)
> > Yes it is slow in 4.5.x.  It has been speed up on the trunk already.
>
> I remember it being slow in more recent builds I've done from trunk, too,
> so
> I'm confirming this bug.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug target/81492] internal compiler error: Segmentation fault (ia64 target with "-O1 -g" and __attribute__((optimize("O3"))))

[slyfox at inbox dot ru]

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

--- Comment #2 from Sergei Trofimovich  ---
(In reply to Martin Liška from comment #1)
> Can't reproduce that with a cross compiler, can you please run --save-temps
> --verbose and execute 'cc1 ...' in GDB so that you can paste here a
> back-trace?

It fals here both on hative compiler and crosscompiler. Here is a backtrace:

[sf] ~/dev/bugs/gcc-ia64-crash:LANG=C gdb --args
/usr/libexec/gcc/ia64-unknown-linux-gnu/6.3.0/cc1 -fpreprocessed loops.i -quiet
-dumpbase loops.c -auxbase-strip loops.o -g -O1 -Wall -version -o loops.s
GNU gdb (Gentoo 8.0 vanilla) 8.0
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
/usr/libexec/gcc/ia64-unknown-linux-gnu/6.3.0/cc1...Reading symbols from
/usr/lib64/debug//usr/libexec/gcc/ia64-unknown-linux-gnu/6.3.0/cc1.debug...done.
done.
(gdb) run
Starting program: /usr/libexec/gcc/ia64-unknown-linux-gnu/6.3.0/cc1
-fpreprocessed loops.i -quiet -dumpbase loops.c -auxbase-strip loops.o -g -O1
-Wall -version -o loops.s
GNU C11 (Gentoo 6.3.0 p1.0) version 6.3.0 (ia64-unknown-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.1.2, MPFR version
3.1.3-p4, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (Gentoo 6.3.0 p1.0) version 6.3.0 (ia64-unknown-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.1.2, MPFR version
3.1.3-p4, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6b42849eb9b759fbb6a6b5d3684c5a13

Program received signal SIGSEGV, Segmentation fault.
bb_note (bb=bb@entry=0x0) at
/usr/src/debug/cross-ia64-unknown-linux-gnu/gcc-6.3.0/gcc-6.3.0/gcc/cfgrtl.c:669
669   note = BB_HEAD (bb);

(gdb) bt
#0  bb_note (bb=bb@entry=0x0) at
/usr/src/debug/cross-ia64-unknown-linux-gnu/gcc-6.3.0/gcc-6.3.0/gcc/cfgrtl.c:669
#1  0x008e221a in sel_bb_head (bb=0x0) at
/usr/src/debug/cross-ia64-unknown-linux-gnu/gcc-6.3.0/gcc-6.3.0/gcc/sel-sched-ir.c:4536
#2  0x008ee7c9 in moveup_expr_cached (expr=0x7fffca00,
insn=insn@entry=0x7fb762c90798,
inside_insn_group=inside_insn_group@entry=false)
at
/usr/src/debug/cross-ia64-unknown-linux-gnu/gcc-6.3.0/gcc-6.3.0/gcc/sel-sched.c:2531
#3  0x008f163f in move_op_ascend (insn=0x7fb762c90798,
static_params=)
at
/usr/src/debug/cross-ia64-unknown-linux-gnu/gcc-6.3.0/gcc-6.3.0/gcc/sel-sched.c:6151
#4  0x008f3498 in code_motion_path_driver (insn=0x7fb762c90798,
insn@entry=0x7fb762c92a80, orig_ops=, orig_ops@entry=0x1668ff8, 
path=0x16691b8, path@entry=0x0,
local_params_in=local_params_in@entry=0x7fffcae0,
static_params=static_params@entry=0x7fffcab0)
at
/usr/src/debug/cross-ia64-unknown-linux-gnu/gcc-6.3.0/gcc-6.3.0/gcc/sel-sched.c:6648
#5  0x008f3c32 in move_op (should_move=,
c_expr=0x7fffca00, dest=, expr_vliw=0x1668f90,
orig_ops=0x1668ff8, 
insn=0x7fb762c92a80) at
/usr/src/debug/cross-ia64-unknown-linux-gnu/gcc-6.3.0/gcc-6.3.0/gcc/sel-sched.c:6702
#6  move_exprs_to_boundary (bnd=, c_expr=0x7fffca00,
expr_seq=0x1668ff8, expr_vliw=0x1668f90)
at
/usr/src/debug/cross-ia64-unknown-linux-gnu/gcc-6.3.0/gcc-6.3.0/gcc/sel-sched.c:5225
#7  schedule_expr_on_boundary (bnd=bnd@entry=0x1668ba0,
expr_vliw=expr_vliw@entry=0x1668f90, seqno=seqno@entry=-1)
at
/usr/src/debug/cross-ia64-unknown-linux-gnu/gcc-6.3.0/gcc-6.3.0/gcc/sel-sched.c:5438
#8  0x008f673a in fill_insns (fence=fence@entry=0x1668350, seqno=-1,
scheduled_insns_tailpp=scheduled_insns_tailpp@entry=0x7fffcce0)
at
/usr/src/debug/cross-ia64-unknown-linux-gnu/gcc-6.3.0/gcc-6.3.0/gcc/sel-sched.c:5580
#9  0x008f8e23 in schedule_on_fences
(scheduled_insns_tailpp=0x7fffcce0, max_seqno=1, fences=0x1668348)
at
/usr/src/debug/cross-ia64-unknown-linux-gnu/gcc-6.3.0/gcc-6.3.0/gcc/sel-sched.c:7356
#10 sel_sched_region_2 (orig_max_seqno=orig_max_seqno@entry=22) at
/usr/src/debug/cross-ia64-unknown-linux-gnu/gcc-6.3.0/gcc-6.3.0/gcc/sel-sched.c:7494
#11 0x008fa541 in sel_sched_region_1 () at
/usr/src/debug/cross-ia64-unknown-linux-gnu/gcc-6.3.0/gcc-6.3.0/gcc/sel-sched.c:7536
#12 sel_sched_region (rgn=0) at
/usr/src/debug/cross-ia64-unknown-linux-gnu/gcc-6.3.0/gcc-6.3.0/gcc/sel-sched.c:7637
#13 0x008faeac in 

[Bug middle-end/56882] ICE: when compiling gegl

[ygribov at gcc dot gnu.org]

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

Yury Gribov  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||ygribov at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #3 from Yury Gribov  ---
I couldn't repro either, neither w/ 4.8.0, not w/ trunk.  Perhaps you could try
checking with fresh GCC and provide up-to-date repro if it still fails?

[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily

[ygribov at gcc dot gnu.org]

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

Yury Gribov  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
  Known to fail||7.0

[Bug middle-end/81512] New: duplicate note in -Walloca-larger-than and alloca in a return statement

[msebor at gcc dot gnu.org]

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

Bug ID: 81512
   Summary: duplicate note in -Walloca-larger-than and alloca in a
return statement
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When a call to alloca() used as the argument of a return statement like in the
case below triggers a -Walloca-larger-than warning it ends up printing two
identical notes mentioning the size limit when one is expected.

$ cat a.c && gcc -O2 -S -Wall -Walloca-larger-than=12344 a.c
#define alloca __builtin_alloca

void* f (void)
{
  return alloca (12345);
}

a.c: In function ‘f’:
a.c:1:16: warning: argument to ‘alloca’ is too large [-Walloca-larger-than=]
 #define alloca __builtin_alloca
^
a.c:5:10: note: in expansion of macro ‘alloca’
   return alloca (12345);
  ^~
a.c:1:16: note: limit is 12344 bytes, but argument is 12345
 #define alloca __builtin_alloca
^
a.c:5:10: note: in expansion of macro ‘alloca’
   return alloca (12345);
  ^~

[Bug sanitizer/71962] error: ‘((& x) != 0u)’ is not a constant expression

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #7)

The null pointer check inserted by the sanitizer is eventually removed (see
below) so there's obviously no point in emitting it to begin with.  The DSP
case you mention simply isn't important to worry about, and certainly not worth
pessimizing the common case for.  If there really were a need to handle this
corner case then it should be provided as a separate feature, under its own
option, and be disabled by default (even with -fsantize=undefined).  It should
also be tested, which judging by the absence of test suite failures with the
patch, it currently isn't.

$ cat a.C && gcc -O2 -S -Wall -Wpedantic -fsanitize=undefined
-fdump-tree-ubsan=/dev/stdout -fdump-tree-optimized=/dev/stdout a.C
int f ()
{
  static int i = 1;

  int *p = 

  return *p;
}


;; Function int f() (_Z1fv, funcdef_no=0, decl_uid=2604, cgraph_uid=0,
symbol_order=1)

Introduced new external node (long unsigned int __builtin_object_size(const
void*, int)/2).

Symbols to be put in SSA form
{ D.2610 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 3
Number of blocks to update: 2 ( 67%)


int f() ()
{
  int * p;
  static int i = 1;
  int _3;
  long unsigned int _4;

   [0.00%] [count: INV]:
  p_1 = 
  UBSAN_NULL (p_1, 0B, 4);
  _4 = __builtin_object_size (p_1, 0);
  UBSAN_OBJECT_SIZE (p_1, 4, _4, 0);
  _3 = *p_1;
  return _3;

}



;; Function int f() (_Z1fv, funcdef_no=0, decl_uid=2604, cgraph_uid=0,
symbol_order=1)

Removing basic block 4
Merging blocks 2 and 3
int f() ()
{
  static int i = 1;
  int _2;

   [100.00%] [count: INV]:
  _2 = i;
  return _2;

}

[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily

[ygribov at gcc dot gnu.org]

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

Yury Gribov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ygribov at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #17 from Yury Gribov  ---
Fixed.

[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily

[ygribov at gcc dot gnu.org]

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

--- Comment #16 from Yury Gribov  ---
Author: ygribov
Date: Fri Jul 21 19:48:51 2017
New Revision: 250442

URL: https://gcc.gnu.org/viewcvs?rev=250442=gcc=rev
Log:
2017-07-21  Yury Gribov  

PR middle-end/56727
* ipa-visibility (function_and_variable_visibility): Convert
recursive PLT call to direct call if appropriate.

* gcc.dg/pr56727-1.c: New test.
* gcc.dg/pr56727-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr56727-1.c
trunk/gcc/testsuite/gcc.dg/pr56727-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-visibility.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/71962] error: ‘((& x) != 0u)’ is not a constant expression

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #6)
> The difference between success and failure is due to this bit of code in
> symtab.c:
> 
>   /* With !flag_delete_null_pointer_checks we assume that symbols may
>  bind to NULL. This is on by default on embedded targets only.
> 
>  Otherwise all non-WEAK symbols must be defined and thus non-NULL or
>  linking fails.  Important case of WEAK we want to do well are comdats.
>  Those are handled by later check for definition.
> 
>  When parsing, beware the cases when WEAK attribute is added later.  */
>   if (!DECL_WEAK (decl)
>   && flag_delete_null_pointer_checks)
> {
>   refuse_visibility_changes = true;
>   return true;
> }
> 
> But the address of a static local variable can never be null so the test
> above is unnecessarily restrictive.  The following patch relaxes the test,
> letting GCC accept the test case even with -fsanitize=undefined.  I didn't
> spot any obvious failures in the test suite with it.

-fno-delete-null-pointer-checks is an option that allows violating the C
requirements and a user variable can live at address 0.  That is something
people need on various DSPs etc. where e.g. the data or rodata section can
start at NULL.  So this change is wrong.
Whether automatic variables can have NULL addresses is a separate question.

Now, as I said before, we could change the options handling not to force
flag_delete_null_pointer_checks = 0; for the sanitizers and review the places
that check flag_delete_null_pointer_checks and in most of them check also the
corresponding sanitizer options. then we could on a case by case decide what is
and what isn't possible.

[Bug sanitizer/71962] error: ‘((& x) != 0u)’ is not a constant expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #6 from Martin Sebor  ---
The difference between success and failure is due to this bit of code in
symtab.c:

  /* With !flag_delete_null_pointer_checks we assume that symbols may
 bind to NULL. This is on by default on embedded targets only.

 Otherwise all non-WEAK symbols must be defined and thus non-NULL or
 linking fails.  Important case of WEAK we want to do well are comdats.
 Those are handled by later check for definition.

 When parsing, beware the cases when WEAK attribute is added later.  */
  if (!DECL_WEAK (decl)
  && flag_delete_null_pointer_checks)
{
  refuse_visibility_changes = true;
  return true;
}

But the address of a static local variable can never be null so the test above
is unnecessarily restrictive.  The following patch relaxes the test, letting
GCC accept the test case even with -fsanitize=undefined.  I didn't spot any
obvious failures in the test suite with it.

--- a/gcc/symtab.c
+++ b/gcc/symtab.c
@@ -1937,7 +1937,8 @@ symtab_node::nonzero_address ()

  When parsing, beware the cases when WEAK attribute is added later.  */
   if (!DECL_WEAK (decl)
-  && flag_delete_null_pointer_checks)
+  && (flag_delete_null_pointer_checks
+ || (TREE_STATIC (decl) && !DECL_EXTERNAL (decl
 {
   refuse_visibility_changes = true;
   return true;

[Bug tree-optimization/81511] New: gcc ICE at -O3 on valid code on x86_64-linux-gnu in operator[], at vec.h:749

[helloqirun at gmail dot com]

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

Bug ID: 81511
   Summary: gcc ICE at -O3 on valid code on x86_64-linux-gnu in
operator[], at vec.h:749
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following valid code causes an ICE when compiled with the current gcc trunk
at only -O3 on x86_64-linux-gnu.


$ gcc-trunk --version
gcc-trunk (GCC) 8.0.0 20170721 (experimental) [trunk revision 250425]

$ gcc-trunk -O3 abc.c
during GIMPLE pass: vect
abc.c: In function ‘fn1’:
abc.c:3:6: internal compiler error: in operator[], at vec.h:749
 void fn1() {
  ^~~
0x7624ac vec<_stmt_vec_info*, va_heap, vl_embed>::operator[](unsigned int)
../../gcc/gcc/vec.h:749
0x7624ac vec<_stmt_vec_info*, va_heap, vl_ptr>::operator[](unsigned int)
../../gcc/gcc/vec.h:1234
0x7624ac vinfo_for_stmt
../../gcc/gcc/tree-vectorizer.h:800
0x765cc4 vinfo_for_stmt
../../gcc/gcc/tree-vect-loop.c:3165
0x765cc4 vect_is_simple_reduction
../../gcc/gcc/tree-vect-loop.c:3072
0xee2884 vect_force_simple_reduction(_loop_vec_info*, gimple*, bool*, bool)
../../gcc/gcc/tree-vect-loop.c:3298
0xee2cd7 vect_analyze_scalar_cycles_1
../../gcc/gcc/tree-vect-loop.c:857
0xee4d4c vect_analyze_scalar_cycles
../../gcc/gcc/tree-vect-loop.c:934
0xee4d4c vect_analyze_loop_2
../../gcc/gcc/tree-vect-loop.c:1930
0xee4d4c vect_analyze_loop(loop*, _loop_vec_info*)
../../gcc/gcc/tree-vect-loop.c:2405
0xef0bb2 vectorize_loops()
../../gcc/gcc/tree-vectorizer.c:669
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ cat abc.c
int a, b, d, e;
char c, f;
void fn1() {
  for (; b; b = b + 5) {
e = a;
a = 1 | d;
d = f < 0 ^ c;
  }
}

[Bug tree-optimization/81510] [8 Regression] ice in operator[], at vec.h:749

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Component|c   |tree-optimization
Version|7.0 |8.0
   Target Milestone|--- |8.0
Summary|ice in operator[],  at  |[8 Regression] ice in
   |vec.h:749   |operator[],  at vec.h:749

[Bug c/81510] New: ice in operator[], at vec.h:749

[dcb314 at hotmail dot com]

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

Bug ID: 81510
   Summary: ice in operator[],  at vec.h:749
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

The following C code, when compiled by recent gcc trunk and flag -O3,
does this:

/home/dcb/creduce/dcbTest/bug371.c:7:1: internal compiler error: in operator[], 
at vec.h:749
 e() {
 ^
0xef8ea7 vec<_stmt_vec_info*, va_heap, vl_embed>::operator[](unsigned int)
../../trunk/gcc/vec.h:749
0xef8ea7 vec<_stmt_vec_info*, va_heap, vl_ptr>::operator[](unsigned int)
../../trunk/gcc/vec.h:1234
0xef8ea7 vinfo_for_stmt
../../trunk/gcc/tree-vectorizer.h:800
0xefeb5b vinfo_for_stmt
../../trunk/gcc/tree-vect-loop.c:3135

C code is

typedef d;
typedef f;
typedef long h;
a;
b;
c;
e() {
  f *g;
  h i;
  for (;;)
if (g)
  for (; b; b++) {
g = c;
if (a &= c) {
  d *j = 
  h k;
  for (; i; i++) {
*g ?: (*j = k);
g = 
  }
  for (; i <= 3; i++)
;
}
  }
}

Problem seems to exist between revisions 250361 and 250395.

[Bug bootstrap/38743] libgcc multilib fails if not able to exec "non" native programs

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #7 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #6)
> a patch like http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00474.html is
> needed for libgcc.

Confirming that libgcc/configure.ac is still missing something like that.

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

[daniel.kruegler at googlemail dot com]

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

--- Comment #2 from Daniel Krügler  ---
Shouldn't add a DR-1177 tag? (I forgot the exact construction pattern for this)
This may also help to validate that all other wording changes by this issue had
been implemented.

[Bug c++/81508] Control reaches end of non-void function - warning not emmited when optimization is turned on

[juraj.orsulic at fer dot hr]

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

--- Comment #3 from Juraj Oršulić  ---
Update: tested on 7.1.0, bug doesn't happen there (i.e. building without
optimisation is successful).

[Bug bootstrap/43952] NetBSD _ANSI_H_ vs. _I386_ANSI_H_ and _X86_64_ANSI_H_

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Arnaud Lacombe from comment #2)
> this issues seems to be a duplicate of PR38182.

Closing as a duplicate of that one then.

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

[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||corsepiu at gcc dot gnu.org

--- Comment #17 from Eric Gallager  ---
*** Bug 43952 has been marked as a duplicate of this bug. ***

[Bug bootstrap/44425] should probe prefix for gmp/mpfr/mpc

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Confirming; it would make the configure line much simpler for some package
managers that use nonstandard prefixes.

[Bug target/44002] need to #include unistd.h for pid_t on alpha-dec-vms

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
  Component|bootstrap   |target
Summary|need to #include unistd.h   |need to #include unistd.h
   |for pid_t   |for pid_t on alpha-dec-vms

--- Comment #1 from Eric Gallager  ---
The  include directly above should have gotten it; that's where
the pid_t typedef is for me, at least. Assuming this is a target-specific
issue.

[Bug bootstrap/43301] top-level configure script ignores ---with-build-time-tools

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
(In reply to Ryan Johnson from comment #0)
> ./configure ... --with-build-time-tools=$MY_TOOLS ignores $MY_TOOLS (though
> it correctly warns when $MY_TOOLS is not an absolute path).
> 
> Let's just say this led to extremely frustrating behavior until I decided to
> start digging...
> 
> Suggested patch to correct the problem:
> 
> Index: /home/Ryan/apps/gcc-4.5-src/configure.ac
> ===
> --- /home/Ryan/apps/gcc-4.5-src/configure.ac(revision 157227)
> +++ /home/Ryan/apps/gcc-4.5-src/configure.ac(working copy)
> @@ -3221,7 +3221,9 @@
>[  --with-build-time-tools=PATH
>use given path to find target tools during the
> build],
>[case x"$withval" in
> - x/*) ;;
> + x/*)
> +   with_build_time_tools=$withval
> +   ;;
>   *)
> with_build_time_tools=
> AC_MSG_WARN([argument to --with-build-time-tools must be an absolute
> path])

Confirming that GCC's configure.ac is still unpatched.

[Bug c++/81508] Control reaches end of non-void function - warning not emmited when optimization is turned on

[juraj.orsulic at fer dot hr]

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

--- Comment #2 from Juraj Oršulić  ---
Apologies for the spam, I have now attached an even smaller minimal working
example (without the glog dependency), along with some useful info:

- when optimisation is enabled, GCC correctly uses __attribute__ ((noreturn))
to figure out that LogMessageFatal() will not return when invoked from Flush().
However, without optimisation, we get the aforementioned error.

- for some strange reason, if we remove the declaration of the string local
variable in Flush(), compilation without optimisation will also be successful.

This odd behaviour (especially the second one) suggests to me that this could
really be a gcc bug.

[Bug bootstrap/45928] genattrtab is too slow.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> Yes it is slow in 4.5.x.  It has been speed up on the trunk already.

I remember it being slow in more recent builds I've done from trunk, too, so
I'm confirming this bug.

[Bug bootstrap/32690] 4.2.1 Bootstrap fails - gcc-4_2-branch/boehm-gc/ltconfig: No such file or directory

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
GCC no longer includes the boehm-gc directory so I'm closing this bug as FIXED
by the removal of boehm-gc.

[Bug c++/81508] Control reaches end of non-void function - warning not emmited when optimization is turned on

[juraj.orsulic at fer dot hr]

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

Juraj Oršulić  changed:

   What|Removed |Added

  Attachment #41804|0   |1
is obsolete||

--- Comment #1 from Juraj Oršulić  ---
Created attachment 41808
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41808=edit
Minimal working example 2 (more minimal)

This version does not require the glog dependency.

[Bug fortran/81509] Wrong compilation error: iand/ieor/ior + boz + -std=f2008

[ripero84 at gmail dot com]

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

--- Comment #2 from ripero84 at gmail dot com ---
Created attachment 41807
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41807=edit
Compilation output - gfortran v7.1.0

[Bug fortran/81509] Wrong compilation error: iand/ieor/ior + boz + -std=f2008

[ripero84 at gmail dot com]

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

--- Comment #1 from ripero84 at gmail dot com ---
Created attachment 41806
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41806=edit
Compilation output - gfortran v6.4.0

[Bug target/81495] Building Ada on Linux m68k natively fails with obscure linker errors

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
> Looks like the compiler itself is not functioning properly.

Do you mean the cross-compiled native compiler or the cross-compiler itself?

> I have tried building libgmpada, for example, and when trying to compile
> src/gnu_multiple_precision-big_integers.adb, the compiler is constantly
> generating segfaults:

It would be nice to have a backtrace for one of them.

[Bug fortran/81509] New: Wrong compilation error: iand/ieor/ior + boz + -std=f2008

[ripero84 at gmail dot com]

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

Bug ID: 81509
   Summary: Wrong compilation error: iand/ieor/ior + boz +
-std=f2008
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ripero84 at gmail dot com
  Target Milestone: ---

Created attachment 41805
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41805=edit
Example source code

When the following three conditions are met
(a) call to the intrinsic function IAND, IEOR, or IOR, and
(b) one of its arguments is a boz-literal-constant, and
(c) the -std=f2008 compilation flag is used,
for example,

write(*,*)  ior(b'001011101',5)

compilation aborts with the compilation error:

Error: GNU Extension: Different type kinds at (1)

with (1) also written below the left parenthesis after the intrinsic function.

This should not be an error, since the 2008 version of the Fortran standard
permits this: paragraph 3 "Arguments" of the subsections that define IAND(I,J),
IEOR(I,J), and IOR(I,J) (13.7.72, 13.7.78, and 13.7.82, respectively) say:

"I shall be of type integer or a boz-literal-constant.
"J shall be of type integer or a boz-literal-constant. If both I and J are of
type integer, they shall have the same kind type parameter. I and J shall not
both be boz-literal-constants."

Note that the cause for the error would not even make sense:
boz-literal-constants don't have a type (as per paragraph 1, section 4.7 of the
2008 standard), and therefore they could not have a type kind that could match
or not the type kind of the other argument of the intrinsic function.

I am experiencing this with versions 6.4.0 and 7.1.0 - please see the
attachments for an example that explores all combinations of boz constants and
intrinsics, and the respective compiler outputs with detailed version
information.

[Bug bootstrap/37996] libgcc.mvars missing dependency on the variable tmake_file, maybe others

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Confirming that gcc/Makefile.in is still missing this dependency for its
libgcc.mvars target.

[Bug c++/81508] New: Control reaches end of non-void function - warning not emmited when optimization is turned on

[juraj.orsulic at fer dot hr]

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

Bug ID: 81508
   Summary: Control reaches end of non-void function - warning not
emmited when optimization is turned on
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juraj.orsulic at fer dot hr
  Target Milestone: ---

Created attachment 41804
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41804=edit
Minimal working example

This is on Ubuntu 17.04, gcc 6.3.0.

Running (note that glog has to be installed):
g++ -c hybrid_grid_points_processor.cc -Werror=return-type 
gives:

hybrid_grid_points_processor.cc: In function ‘FlushResult Flush()’:
hybrid_grid_points_processor.cc:26:1: error: control reaches end of non-void
function [-Werror=return-type]
 }


When -O1 or -O2 or -O3 is added, compilation is successful.

Minimal working example (hybrid_grid_points_processor.cc) has been attached.

[Bug bootstrap/27516] install failure due to unconditional invocation of makeinfo for treelang.texi

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED
  Known to fail||

--- Comment #24 from Eric Gallager  ---
(In reply to Joseph S. Myers from comment #23)
> Closing 4.1 branch.  Removing milestone altogether as it's not clear this is
> a regression - and treelang is no longer present on trunk, so if this only
> affected treelang then there is no bug on trunk here any more.

I'm taking "no bug on trunk here any more" to mean I can close this as RESOLVED
FIXED by the removal of treelang.

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

[wilco at gcc dot gnu.org]

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

--- Comment #11 from Wilco  ---
(In reply to Martin Liška from comment #10)
> > > 
> > > Yep, I've noticed. It's strange for me why it's not working. I've just 
> > > asked
> > > at GCC ML: https://gcc.gnu.org/ml/gcc/2017-07/msg00144.html
> > 
> > It's marked as a tailcall so anything you generate afterwards will be
> > ignored:
> 
> Thanks, knowing that it was easy to fix ;) I'm going to test the patch and
> will send it to mailing list.

Well the new patch looks great - I tried it on GLIBC and it ends up generating
better code than inlining mempcpy in the string header. In total 111 calls to
mempcpy are turned into memcpy, and although there are 166 extra instructions
(most add/mov to deal with the return value), there are just 12 extra
callee-saves.

[Bug bootstrap/31840] race condition in makefiles

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-21
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Could you be more specific about how exactly bootstrap fails? What is the error
message?

[Bug bootstrap/28466] Cannot build inside an object tree with name including :

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
Confirming that this build failure still happens with trunk, but yeah, I don't
think this is really GCC's problem.

[Bug lto/81487] [mingw32] ld.exe: error: asprintf failed

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  ---
Author: gjl
Date: Fri Jul 21 15:58:14 2017
New Revision: 250428

URL: https://gcc.gnu.org/viewcvs?rev=250428=gcc=rev
Log:
lto-plugin/
PR lto/81487
* lto-plugin.c (claim_file_handler): Use xasprintf instead of
asprintf.
[hi!=0]: Swap hi and lo arguments supplied to xasprintf.

Modified:
trunk/lto-plugin/ChangeLog
trunk/lto-plugin/lto-plugin.c

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug middle-end/71905] Values passed to -Wlarger-than= and -Wframe-larger-than= and -Wstack-usage= should accept KB and MB suffixes

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
I still see the same warnings with a 64-bit GCC 8.0.0 20170717 on x86_64-linux.

[Bug target/81317] builtin_vec_ld fails for powerpc with altivec

[randy.macleod at windriver dot com]

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

--- Comment #23 from Randy MacLeod  ---
Here is the 'bt' and 'bt full' with line numbers and symbols. YP diff to enable
this is below as well. Thanks for you patience as I re-learn these ropes.

Program received signal SIGSEGV, Segmentation fault.
store_expr_with_bounds (exp=exp@entry=0x7658ed80,
target=target@entry=0x76722930, call_param_p=call_param_p@entry=0, 
nontemporal=nontemporal@entry=false, reverse=reverse@entry=false,
btarget=btarget@entry=0x7658d480)
at ../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/expr.c:5575
5575  if (CONSTANT_P (temp) && GET_MODE (temp) == VOIDmode
(gdb) bt 
#0  store_expr_with_bounds (exp=exp@entry=0x7658ed80,
target=target@entry=0x76722930, call_param_p=call_param_p@entry=0, 
nontemporal=nontemporal@entry=false, reverse=reverse@entry=false,
btarget=btarget@entry=0x7658d480)
at ../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/expr.c:5575
#1  0x007604e0 in expand_assignment (to=0x7658d480,
from=from@entry=0x7658ed80, nontemporal=nontemporal@entry=false)
at ../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/expr.c:5321
#2  0x006728fb in expand_call_stmt (stmt=0x76715240) at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/cfgexpand.c:2656
#3  expand_gimple_stmt_1 (stmt=0x76715240) at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/cfgexpand.c:3571
#4  expand_gimple_stmt (stmt=stmt@entry=0x76715240) at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/cfgexpand.c:3737
#5  0x006742f1 in expand_gimple_basic_block (bb=0x765a0410,
disable_tail_calls=disable_tail_calls@entry=false)
at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/cfgexpand.c:5744
#6  0x00678ddf in (anonymous namespace)::pass_expand::execute
(this=, fun=0x7671) 
[90/202]
at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/cfgexpand.c:6357
#7  0x0092be4b in execute_one_pass (pass=pass@entry=0x1a80650) at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/passes.c:2465
#8  0x0092c668 in execute_pass_list_1 (pass=0x1a80650) at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/passes.c:2554
#9  0x0092c6c5 in execute_pass_list (fn=,
pass=)
at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/passes.c:2565
#10 0x006a360d in cgraph_node::expand (this=0x7670c2e0) at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/cgraphunit.c:2042
#11 0x006a4b3d in expand_all_functions () at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/cgraphunit.c:2178
#12 symbol_table::compile (this=this@entry=0x76585000) at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/cgraphunit.c:2535
---Type  to continue, or q  to quit---
#13 0x006a6598 in symbol_table::compile (this=0x76585000)
at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/cgraphunit.c:2599
#14 symbol_table::finalize_compilation_unit (this=0x76585000) at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/cgraphunit.c:2625
#15 0x009e75b0 in compile_file () at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/toplev.c:492
#16 0x00577a4c in do_compile () at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/toplev.c:2000
#17 toplev::main (this=this@entry=0x7fffada0, argc=argc@entry=27,
argv=argv@entry=0x7fffaea8)
at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/toplev.c:2134
#18 0x00579dd7 in main (argc=27, argv=0x7fffaea8) at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/main.c:39
(gdb)


(gdb) bt full  
  [69/202]
#0  store_expr_with_bounds (exp=exp@entry=0x7658ed80,
target=target@entry=0x76722930, call_param_p=call_param_p@entry=0, 
nontemporal=nontemporal@entry=false, reverse=reverse@entry=false,
btarget=btarget@entry=0x7658d480)
at ../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/expr.c:5575
temp = 0x0
alt_rtl = 0x0
loc = 2147483667
__FUNCTION__ = "store_expr_with_bounds"
#1  0x007604e0 in expand_assignment (to=0x7658d480,
from=from@entry=0x7658ed80, nontemporal=nontemporal@entry=false)
at ../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/expr.c:5321
to_rtx = 
result = 
mode = 
align = 
icode = 
__FUNCTION__ = "expand_assignment"
#2  0x006728fb in expand_call_stmt (stmt=0x76715240) at
../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/gcc/cfgexpand.c:26[53/202]
exp = 0x7658ed80
i = 
builtin_p = 
#3  expand_gimple_stmt_1 (stmt=0x76715240) at

[Bug libstdc++/81482] by-value lambda capture in remove_if

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |minor

--- Comment #1 from Jonathan Wakely  ---
It's not specific to lambdas, but any stateful predicate.

As you say, this behaviour is conforming. C++2014 [algorithms.general] para 10
says:

[Note: Unless otherwise specified, algorithms that take function objects as
arguments are permitted to copy those function objects freely. Programmers for
whom object identity is important should consider using a wrapper class that
points to a noncopied implementation object such as reference_wrapper
(23.14.5), or some equivalent solution. — end note]


It looks like (at least) std::search and std::search_n and std::find_end make
copies of the predicate and then reuse the original object.

If there's a measurable performance cost to the copies I'd entertain patches to
do something about it (and even then, using reference_wrapper is probably
appropriate), but I'm not concerned by the surprising result for your testcase.
That's how the standard algorithms work. If you capture by reference, or pass
the predicate by reference, then everything works as expected.

[Bug c++/81507] map header kills variant of vectors

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Adding even more output doesn't necessarily make it easier to see the problem.

It also wouldn't always be correct: maybe the overload that was found *is* the
intended one, and there really is a problem with it. Saying "Did you mean ..."
for some other overload that happens to compile without errors might not help.

If you are serious about the proposal I suggest re-opening this and changing
the subject and Severity (to "enhancement") or opening a new bug, providing
simple examples and very clear descriptions of what you'd like the diagnostics
to produce. Nobody is going to implement a feature request buried in a a bug
already closed as INVALID.

[Bug tree-optimization/81503] [8 Regression] Wrong code at -O2

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #5 from Bill Schmidt  ---
Mine, but my queue is getting pretty deep, so it will be a bit before I look at
it.

[Bug bootstrap/32840] bootstrap broken on ix86-linux-gnu targets with --enable-targets=all

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-21
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to H.J. Lu from comment #1)
> Can you verify if it is the same as PR 31868? There is a a patch for PR
> 31868.

...which is now closed as FIXED. So is this fixed as well?

[Bug bootstrap/28758] `make` fails because of bad ORIGINAL_LD_FOR_TARGET

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-21
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> Can you show the output of the orginal configure?

And the `make` failure message?

[Bug sanitizer/71962] error: ‘((& x) != 0u)’ is not a constant expression

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-21
 Ever confirmed|0   |1
  Known to fail|7.0 |7.1.0, 8.0

--- Comment #5 from Jonathan Wakely  ---
A simpler test:

int main()
{
  static constexpr int x = 0;
  static_assert(bool(), "");
}

ubsan.cc: In function ‘int main()’:
ubsan.cc:4:3: error: non-constant condition for static assertion
   static_assert(bool(), "");
   ^
ubsan.cc:4:17: error: ‘((& x) != 0)’ is not a constant expression
   static_assert(bool(), "");
 ^~~~

[Bug bootstrap/3550] "touch" still in libiberty/Makefile.in

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WONTFIX
Summary|"touch" still in|"touch" still in
   |libiberty/Makefile.in,  |libiberty/Makefile.in
   |gcc/mklibgcc.in |

--- Comment #4 from egallager at gcc dot gnu.org ---
gcc/mklibgcc.in no longer exists as a file, but libiberty/Makefile.in still has
"touch" in it. Solaris 2.7 and Solaris 2.8 are really old; according to
Wikipedia support was dropped for them in 2008 and 2012 respectively. I'm going
to be bold and assume that support for them is no longer something gcc needs to
worry about, but please feel free to reopen if I'm wrong.

[Bug tree-optimization/65068] Improve rewriting for address type induction variables in IVOPT

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from amker at gcc dot gnu.org ---
Fixed now, we now generates below code for a72/a57:
.L4:
ldr w0, [x1]
add w0, w0, 1
str w0, [x1], 4
cmp x1, x2
bne .L4


The original issue reported is that loop invariant expression is split thus
can't be hoisted out of loop.  I think comment 3 is a different issue.  Closing
this one.

[Bug target/81495] Building Ada on Linux m68k natively fails with obscure linker errors

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #2 from John Paul Adrian Glaubitz  ---
(In reply to Eric Botcazou from comment #1)
> You're on your own here; try maybe to compare with a bootstrap on x86.

Looks like the compiler itself is not functioning properly. I have tried
building libgmpada, for example, and when trying to compile
src/gnu_multiple_precision-big_integers.adb, the compiler is constantly
generating segfaults:

root@pacman:/build/libgmpada/libgmpada-1.1# strace -p 25950
strace: Process 25950 attached
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x20398130} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x20398130} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x20398130} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x20398130} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x20398130} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x20398130} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x20398130} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x20398130} ---
(...)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x20398130} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x20398130} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x20398130} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x20398130} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x20398130} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x20398130} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x20398130} ---
root@pacman:/build/libgmpada/libgmpada-1.1#

I also noticed that Support_Atomic_Primitives is set True for Linux m68k but I
have no idea how reliable the atomics work here. So, I am bootstrapping again
with "Support_Atomic_Primitives := True" removed which is true for many other
Linux targets like hppa and sh4.

[Bug c++/81507] map header kills variant of vectors

[benni.buch at gmail dot com]

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

--- Comment #5 from Benjamin Buch  ---
Yes, but in a long list of template heavy calls it is not trivial to see it, if
you don't expect such an error in your code.

It would be nice to have something like the 'did you mean …' hints, if an
argument dependent overload results in an error, but the call of an overload in
the current namespace would be correct. I know this is not trivial to
implement, but it would be helpful.

And yes, in this minimal example it is possible to see it, but it took me 90
minutes get this minimal example.

[Bug tree-optimization/81303] [8 Regression] 410.bwaves regression caused by r249919

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Fri Jul 21 11:32:39 2017
New Revision: 250424

URL: https://gcc.gnu.org/viewcvs?rev=250424=gcc=rev
Log:
2017-07-21  Richard Biener  

PR tree-optimization/81303
* tree-vect-data-refs.c (vect_get_peeling_costs_all_drs): Pass
in datarefs vector.  Allow NULL dr0 for no peeling cost estimate.
(vect_peeling_hash_get_lowest_cost): Adjust.
(vect_enhance_data_refs_alignment): Likewise.  Use
vect_get_peeling_costs_all_drs to compute the penalty for no
peeling to match up costs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-data-refs.c

[Bug tree-optimization/81500] [8 Regression] ICE with -O3 in process_use, at tree-vect-stmts.c:506

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/81500] [8 Regression] ICE with -O3 in process_use, at tree-vect-stmts.c:506

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Fri Jul 21 11:32:01 2017
New Revision: 250423

URL: https://gcc.gnu.org/viewcvs?rev=250423=gcc=rev
Log:
2017-06-21  Richard Biener  

PR tree-optimization/81500
* tree-vect-loop.c (vect_is_simple_reduction): Properly fail if
we didn't identify a reduction path.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr81500.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug c++/81507] map header kills variant of vectors

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
/home/bebuch/media/programme/gcc-7/include/c++/7.1.1/tuple:1670:44:   required
from 'constexpr decltype(auto) std::apply(_Fn&&, _Tuple&&) [with _Fn = const
std::vector&; _Tuple = long unsigned int]'

^^^ there's your hint. It tells you that std::apply was called.

[Bug middle-end/81502] In some cases the data is moved to memory unnecessarily [partial regression]

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Note that with -mtune=intel we already get

_Z3barPv:
.LFB526:
.cfi_startproc
movq%rdi, %xmm0
movd%xmm0, %eax
ret

but yes, the intermediate temporary is unnecessary.  We do not optimize
this to a BIT_INSERT_EXPR because the vector element type doesn't match the
insertion quantity.  We can relax that a bit with the following:

Index: gcc/tree-ssa.c
===
--- gcc/tree-ssa.c  (revision 250386)
+++ gcc/tree-ssa.c  (working copy)
@@ -1513,8 +1513,8 @@ non_rewritable_lvalue_p (tree lhs)
   if (DECL_P (decl)
  && VECTOR_TYPE_P (TREE_TYPE (decl))
  && TYPE_MODE (TREE_TYPE (decl)) != BLKmode
- && types_compatible_p (TREE_TYPE (lhs),
-TREE_TYPE (TREE_TYPE (decl)))
+ && operand_equal_p (TYPE_SIZE_UNIT (TREE_TYPE (lhs)),
+ TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (decl))), 0)
  && tree_fits_uhwi_p (TREE_OPERAND (lhs, 1))
  && tree_int_cst_lt (TREE_OPERAND (lhs, 1),
  TYPE_SIZE_UNIT (TREE_TYPE (decl)))
@@ -1839,8 +1839,9 @@ execute_update_addresses_taken (void)
&& bitmap_bit_p (suitable_for_renaming, DECL_UID (sym))
&& VECTOR_TYPE_P (TREE_TYPE (sym))
&& TYPE_MODE (TREE_TYPE (sym)) != BLKmode
-   && types_compatible_p (TREE_TYPE (lhs),
-  TREE_TYPE (TREE_TYPE (sym)))
+   && operand_equal_p (TYPE_SIZE_UNIT (TREE_TYPE (lhs)),
+   TYPE_SIZE_UNIT
+ (TREE_TYPE (TREE_TYPE (sym))), 0)
&& tree_fits_uhwi_p (TREE_OPERAND (lhs, 1))
&& tree_int_cst_lt (TREE_OPERAND (lhs, 1),
TYPE_SIZE_UNIT (TREE_TYPE (sym)))
@@ -1848,6 +1849,18 @@ execute_update_addresses_taken (void)
% tree_to_uhwi (TYPE_SIZE_UNIT (TREE_TYPE (lhs ==
0)
  {
tree val = gimple_assign_rhs1 (stmt);
+   if (! types_compatible_p (TREE_TYPE (lhs),
+ TREE_TYPE (TREE_TYPE (sym
+ {
+   tree tem = make_ssa_name (TREE_TYPE (TREE_TYPE (sym)));
+   gimple *pun
+ = gimple_build_assign (tem,
+build1 (VIEW_CONVERT_EXPR,
+TREE_TYPE (TREE_TYPE
+ (sym)),
val));
+   gsi_insert_before (, pun, GSI_SAME_STMT);
+   val = tem;
+ }
tree bitpos
  = wide_int_to_tree (bitsizetype,
  mem_ref_offset (lhs) *
BITS_PER_UNIT);

this gets us to

int bar(void*) (void * ptr)
{
  int res;
  __m128i word;
  long long int _2;
  unsigned int _4;

   [100.00%] [count: INV]:
  _2 = (long long int) ptr_6(D);
  word_3 = BIT_INSERT_EXPR <{ 0, 0 }, _2, 0 (64 bits)>;
  _4 = BIT_FIELD_REF ;
  res_5 = (int) _4;
  return res_5;

in .optimized which shows (already known) missed foldings for bit-field-ref
of bit-insert.  That's a complicated one btw, extracting a component from
a vector insert.

Oh, and it misses bit-insert -> CONSTRUCTOR, thus

word_3 = { _2, 0 };

(simplify
 (bit_insert VECTOR_CST@0 @1 @2)
 {
   vec *v;
   vec_alloc (v, TYPE_VECTOR_SUBPARTS (type));
   for (unsigned i = 0; i < VECTOR_CST_NELTS (@0); ++i)
 {
   constructor_elt elt = { NULL_TREE, VECTOR_CST_ELT (@0, i) };
   v->quick_push (elt);
 }
   (*v)[TREE_INT_CST_LOW (@2) 
/ TREE_INT_CST_LOW (TYPE_SIZE (TREE_TYPE (type)))].value = @1;
   build_constructor (type, v);
 })

that gets us to

   [100.00%] [count: INV]:
  _2 = (long long int) ptr_6(D);
  word_3 = {_2, 0};
  _4 = BIT_FIELD_REF ;
  res_5 = (int) _4;
  return res_5;

where we still need that BIT_FIELD_REF simplification.  The IL is already
in this form when we run into FRE1 so handling it there should be
possible in principle.  Or we can fold

  word_3 = {_2, 0};
  _4 = BIT_FIELD_REF ;

to

  _4 = BIT_FIELD_REF <_2, 32, 0 [+adjustment]>;

thus a BIT_FIELD_REF on a CONSTRUCTOR to one on the element.

[Bug c++/81507] map header kills variant of vectors

[benni.buch at gmail dot com]

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

Benjamin Buch  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|libstdc++   |c++
 Resolution|--- |INVALID

--- Comment #3 from Benjamin Buch  ---
Not a bug.

[Bug libstdc++/81507] map header kills variant of vectors

[benni.buch at gmail dot com]

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

--- Comment #2 from Benjamin Buch  ---
Same with clang, and I found the reason:

Since the first argument is std::vector, the function std::apply is called
instead of my apply function …

So it's not a bug. But maybe you can add some kind hint for such errors in the
compiler frontend.

[Bug libstdc++/80165] Constexpr tuple of variant doesn't work

[benni.buch at gmail dot com]

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

--- Comment #4 from Benjamin Buch  ---
Sorry, wrong thread!

[Bug libstdc++/80165] Constexpr tuple of variant doesn't work

[benni.buch at gmail dot com]

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

Benjamin Buch  changed:

   What|Removed |Added

 CC||benni.buch at gmail dot com

--- Comment #3 from Benjamin Buch  ---
Same with clang, and I found the reason:

Since the first argument is std::vector, the function std::apply is called
instead of my apply function …

So it's not a bug. But maybe you can add some kind hint for such errors in the
compiler frontend.

[Bug target/77728] [5 Regression] Miscompilation multiple vector iteration on ARM

[d...@dominik-schmidt.de]

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

Dominik Schmidt  changed:

   What|Removed |Added

 CC||d...@dominik-schmidt.de

--- Comment #61 from Dominik Schmidt  ---
*** Bug 80236 has been marked as a duplicate of this bug. ***

[Bug target/80236] ARM NEON: Crash in std::map

[d...@dominik-schmidt.de]

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

Dominik Schmidt  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #19 from Dominik Schmidt  ---


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

[Bug target/80236] ARM NEON: Crash in std::map

[d...@dominik-schmidt.de]

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

--- Comment #18 from Dominik Schmidt  ---
Created attachment 41803
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41803=edit
Patch working for us

Indeed, it seems to be a duplicate of the other bug.

We backported the GCC-7 patch and could build a working toolchain with it. The
original GCC-6 patch only added a warning but did not contain the actual fix
(for ABI compatibility reasons).

P.S. I'm attaching the patch we ended up with, in case anyone else can't easily
upgrade either.

[Bug libstdc++/81507] map header kills variant of vectors

[benni.buch at gmail dot com]

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

--- Comment #1 from Benjamin Buch  ---
Same with:

$ /home/bebuch/media/programme/gcc-7/bin/g++ --version
g++ (GCC) 7.1.1 20170721
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug sanitizer/81505] [5/6/7/8 Regression] ICE in tree-ssa-loop-manip.c:95 with -fsanitize=signed-integer-overflow

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-21
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |5.5
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
90if (TREE_CODE (step) == INTEGER_CST)
91  {
92if (TYPE_UNSIGNED (TREE_TYPE (step)))
93  {
94step1 = fold_build1 (NEGATE_EXPR, TREE_TYPE (step), step);
95if (tree_int_cst_lt (step1, step))
96  {
(gdb) p debug_generic_expr (step)
-4B(OVF)

note this is a POINTER_TYPE constant.  fold_negate_const produces a
non-overflown 4B from that which is what confuses things.

Of course pointers should never get TREE_OVERFLOW set IMHO.  It gets that
from

#1  0x00b079aa in fold_convert_const_int_from_int (
type=, arg1=0x76a0bb70)
at /tmp/trunk/gcc/fold-const.c:1869
1869 TREE_OVERFLOW (arg1));
(gdb) l
1864  /* Given an integer constant, make new constant with new type,
1865 appropriately sign-extended or truncated.  Use widest_int
1866 so that any extension is done according ARG1's type.  */
1867  return force_fit_type (type, wi::to_widest (arg1),
1868 !POINTER_TYPE_P (TREE_TYPE (arg1)),
1869 TREE_OVERFLOW (arg1));
1870}
1871
1872/* A subroutine of fold_convert_const handling conversions a REAL_CST
1873   to an integer type.  */
(gdb) p arg1
$18 = (const_tree) 0x76a0bb70
(gdb) p debug_generic_expr (arg1)
-4(OVF)

so somewhat reasonable.  So the bug is in fold_negate_const loosing the
overflow
flag.  Fix:

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 250386)
+++ gcc/fold-const.c(working copy)
@@ -13693,8 +13693,8 @@ fold_negate_const (tree arg0, tree type)
bool overflow;
wide_int val = wi::neg (arg0, );
t = force_fit_type (type, val, 1,
-   (overflow | TREE_OVERFLOW (arg0))
-   && !TYPE_UNSIGNED (type));
+   (overflow && ! TYPE_UNSIGNED (type))
+   || TREE_OVERFLOW (arg0));
break;
   }

[Bug libstdc++/81507] New: map header kills variant of vectors

[benni.buch at gmail dot com]

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

Bug ID: 81507
   Summary: map header kills variant of vectors
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benni.buch at gmail dot com
  Target Milestone: ---

I ran into a very strange bug:



#include 
#include 

#include  // must include map to trigger the error!!!

template < typename A, typename B >
void apply(A const&, B const&){}

int main(){
auto value = std::variant< std::vector< int >, std::vector< short > >();
std::visit([](auto const& v){
apply(v, 0ul); // std::tuple_size is incomplete
}, value);
}



$ g++-7.1 -std=c++1z -o main gcc_variant_bug.cpp 
In file included from
/home/bebuch/media/programme/gcc-7/include/c++/7.1.1/bits/node_handle.h:40:0,
 from
/home/bebuch/media/programme/gcc-7/include/c++/7.1.1/bits/stl_tree.h:72,
 from
/home/bebuch/media/programme/gcc-7/include/c++/7.1.1/map:60,
 from gcc_variant_bug.cpp:4:
/home/bebuch/media/programme/gcc-7/include/c++/7.1.1/tuple: In instantiation of
'constexpr const size_t std::tuple_size_v':
/home/bebuch/media/programme/gcc-7/include/c++/7.1.1/tuple:1670:44:   required
from 'constexpr decltype(auto) std::apply(_Fn&&, _Tuple&&) [with _Fn = const
std::vector&; _Tuple = long unsigned int]'
gcc_variant_bug.cpp:14:8:   required from 'main()::
[with auto:1 = std::vector]'
/home/bebuch/media/programme/gcc-7/include/c++/7.1.1/variant:1236:44:  
required from 'constexpr decltype(auto) std::visit(_Visitor&&, _Variants&& ...)
[with _Visitor = main()::; _Variants =
{std::variant, std::vector > >&}]'
gcc_variant_bug.cpp:15:10:   required from here
/home/bebuch/media/programme/gcc-7/include/c++/7.1.1/tuple:1271:29: error:
incomplete type 'std::tuple_size' used in nested name
specifier
 inline constexpr size_t tuple_size_v = tuple_size<_Tp>::value;
 ^~~~



$ g++-7.1 --version
g++-7.1 (GCC) 7.1.1 20170509
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



I'm not quiet sure if it is a bug in the library or in the compiler frontend,
but since the header map is involved, I suppose it's in the library.

[Bug gcov-profile/81491] [8 Regression] PGO/LTO bootstrap: error: non-cold basic block 6 dominated by a block in the cold partition (15)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #3 from Markus Trippelsdorf  ---
Fixed.

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

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from amker at gcc dot gnu.org ---
Fixed.

[Bug lto/81430] nvptx acceleration compilation broken because of running pass_partition_blocks

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
Author: vries
Date: Fri Jul 21 09:46:05 2017
New Revision: 250421

URL: https://gcc.gnu.org/viewcvs?rev=250421=gcc=rev
Log:
Add nvptx_override_options_after_change

2017-07-21  Tom de Vries  

PR lto/81430
* config/nvptx/nvptx.c (nvptx_override_options_after_change): New
function.
(TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE): Define to
nvptx_override_options_after_change.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c

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

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries  ---
Author: vries
Date: Fri Jul 21 09:46:22 2017
New Revision: 250422

URL: https://gcc.gnu.org/viewcvs?rev=250422=gcc=rev
Log:
Add missing edge probabilities in nvptx_goacc_reduction_init

2017-07-21  Tom de Vries  
Cesar Philippidis  

PR gcov-profile/81442
* config/nvptx/nvptx.c (nvptx_goacc_reduction_init): Add missing edge
probabilities.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c

[Bug tree-optimization/81018] [8 regression] gfortran.dg/graphite/pr14741.f90 FAILs

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
Guess this reveals a miss-optimization in graphite.  Pending this issue for now
till it's fully understood.

[Bug tree-optimization/81500] [8 Regression] ICE with -O3 in process_use, at tree-vect-stmts.c:506

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Fri, 21 Jul 2017, dcb314 at hotmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81500
> 
> --- Comment #3 from David Binderman  ---
> Possible duplicate for this reduced code:
> 
> struct a {
>   int b;
>   int c
> };
> struct d {
>   struct a *e
> } f(struct d *g) {
>   int h;
>   int b;
>   for (; h; ++h) {
> int i = g->e[h].c + 1;
> g->e[h].c = g->e[h].b;
> g->e[h].b = b;
> b = i;
>   }
>   if (b)
> j();
> }

Yeah.  Fix is obvious:

Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 250386)
+++ gcc/tree-vect-loop.c(working copy)
@@ -3243,7 +3243,7 @@ pop:
 }

   /* Check whether the reduction path detected is valid.  */
-  bool fail = false;
+  bool fail = path.length () == 0;
   bool neg = false;
   for (unsigned i = 1; i < path.length (); ++i)
 {
@@ -3276,9 +3276,7 @@ pop:

   if (dump_enabled_p ())
 {
-  report_vect_op (MSG_MISSED_OPTIMIZATION,
- SSA_NAME_DEF_STMT
-   (USE_FROM_PTR (path[path.length ()-1].second)),
+  report_vect_op (MSG_MISSED_OPTIMIZATION, def_stmt,
  "reduction: unknown pattern: ");
 }

[Bug c/81306] valgrind error for function warn_for_multistatement_macros in file c-warn.c line 2474

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
Problem still seems to exist a couple of weeks later in latest gcc.

Any progress ?

[Bug tree-optimization/81500] [8 Regression] ICE with -O3 in process_use, at tree-vect-stmts.c:506

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
Possible duplicate for this reduced code:

struct a {
  int b;
  int c
};
struct d {
  struct a *e
} f(struct d *g) {
  int h;
  int b;
  for (; h; ++h) {
int i = g->e[h].c + 1;
g->e[h].c = g->e[h].b;
g->e[h].b = b;
b = i;
  }
  if (b)
j();
}

$ ~/gcc/results/bin/gcc -c -O3 -w bug370.c
during GIMPLE pass: vect
bug370.c: In function ‘f’:
bug370.c:7:3: internal compiler error: in vect_analyze_stmt, at
tree-vect-stmts.c:8524
 } f(struct d *g) {
   ^
0xef7559 vect_analyze_stmt(gimple*, bool*, _slp_tree*, _slp_instance*)
../../trunk/gcc/tree-vect-stmts.c:8519
0xf1217a vect_slp_analyze_node_operations
../../trunk/gcc/tree-vect-slp.c:2510
0xf12075 vect_slp_analyze_node_operations
../../trunk/gcc/tree-vect-slp.c:2453
0xf175ef vect_slp_analyze_operations(vec<_slp_instance*, va_heap, vl_ptr>,
void*)

[Bug target/81496] AVX load from adjacent memory location followed by concatenation

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Strangely I've just today tried icc on
typedef int V __attribute__((vector_size (32)));

V
f1 (int a, int b, int c, int d, int e, int f, int g, int h)
{
  return (V) { a, b, c, d, e, f, g, h };
}
with -O3 -march=core-avx2 and got:
movl  16(%rbp), %eax
movl  24(%rbp), %r10d
movl  %edi, -32(%rsp)
movl  %esi, -28(%rsp)
movl  %edx, -24(%rsp)
movl  %ecx, -20(%rsp)
movl  %r8d, -16(%rsp)
movl  %r9d, -12(%rsp)
movl  %eax, -8(%rsp)
movl  %r10d, -4(%rsp)
vmovdqu   -32(%rsp), %ymm0
ICC 17.0.4 20170411.
Similarly for
typedef long long V __attribute__((vector_size (64)));

V
f1 (long long a, long long b, long long c, long long d, long long e, long long
f, long long g, long long h)
{
  return (V) { a, b, c, d, e, f, g, h };
}
and -O3 -xCORE-AVX512.

[Bug tree-optimization/81500] [8 Regression] ICE with -O3 in process_use, at tree-vect-stmts.c:506

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|c   |tree-optimization
Version|7.0 |8.0
   Target Milestone|--- |8.0

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

[Bug target/81496] AVX load from adjacent memory location followed by concatenation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*, i?86-*-*

--- Comment #4 from Richard Biener  ---
We should definitely aim at comment#2, everything else will be notoriously slow
because of STLF not working.  So the "win" to use a 256bit move will be
marginal at best (code size).

As of first building xmms and then merging them, ICC always uses a series of
inserts into the final ymm.  Bulldozer/Zen might benefit from the xmm variant
though.

[Bug tree-optimization/81303] [8 Regression] 410.bwaves regression caused by r249919

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
So if in addition to this patch we do

Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 250386)
+++ gcc/tree-vect-loop.c(working copy)
@@ -7376,7 +7377,7 @@ vect_transform_loop (loop_vec_info loop_
   /* Version the loop first, if required, so the profitability check
  comes first.  */

-  if (LOOP_REQUIRES_VERSIONING (loop_vinfo))
+  if (check_profitability || LOOP_REQUIRES_VERSIONING (loop_vinfo))
 {
   vect_loop_versioning (loop_vinfo, th, check_profitability);
   check_profitability = false;

thus always do the profitability check by versioning which means not sharing
the epilogue loop with the scalar execution (plus reliably executing the
cost model check first) we get down to 212s from 250s.  This might be solely
because we do not completely peel the versioned copy as we are not able to
analyze its number of iterations (despite the dominating > 7 check).

  _33 = (unsigned int) _1;
  if (_33 > 7)
goto ; [80.01%] [count: INV]
  else
goto ; [19.99%] [count: INV]

   [3.00%] [count: INV]:

   [16.99%] [count: INV] loop 6 header:
  # m_23 = PHI <1(34), m_449(36)>
...
  m_449 = m_23 + 1;
  if (_1 < m_449)
goto ; [17.65%] [count: INV]
  else
goto ; [82.35%] [count: INV]

   [13.99%] [count: INV] loop 6 latch:
  goto ; [100.00%] [count: INV]

we're probably confused by the casting here and infering a range from just
the above for _1 would result in [INT_MIN, 7] only (good enough I guess).

We peel the vector epilogue because:

Loop 8 iterates at most 5 times.
Loop 8 likely iterates at most 5 times.
Estimating sizes for loop 8
 BB: 29, after_exit: 0
  size:   0 _372 = (integer(kind=8)) m_375;
  size:   1 _371 = _372 * stride.88_115;
...
  size:   1 _332 = _349 + _333;
  size:   1 m_331 = m_375 + 1;
  size:   2 if (_1 < m_331)
   Exit condition will be eliminated in last copy.
 BB: 30, after_exit: 1
size: 41-0, last_iteration: 41-2
  Loop size: 41
  Estimated size after unrolling: 162

that is we determine that no stmts will be optimized away due to propagating
constants but then apply our usual 2/3 optimistic heuristic leading to
that estimate (max-completely-peeled-insns is 200).

For small trip count loops the advantage of peeling (irrespective of size)
is better branch predictor hitrate.

There's quite a mistake in cost modeling peeling for alignment but still
with fixing that we end up with a nopeel inside-cost of 14 and a best peel
inside-cost of 13 (we manage to align one load).  Now it doesn't take into
account outside cost at all which is 59 vs 115, but it's hard to combine
both in a sensible way ...

[Bug regression/81497] error compiling arm_acle.h

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||arm
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-21
 CC||avieira at gcc dot gnu.org,
   ||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed. This happens only in g++.
The intrinsics that have void return type should not "return" their builtin,
they should just call it.

[Bug target/81492] internal compiler error: Segmentation fault (ia64 target with "-O1 -g" and __attribute__((optimize("O3"))))

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-21
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can't reproduce that with a cross compiler, can you please run --save-temps
--verbose and execute 'cc1 ...' in GDB so that you can paste here a back-trace?

[Bug c++/81506] New: Invalid declaration with decltype accepted

[reichelt at gcc dot gnu.org]

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

Bug ID: 81506
   Summary: Invalid declaration with decltype accepted
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
CC: paolo.carlini at oracle dot com
Depends on: 51786
  Target Milestone: ---

The error message "declaration does not declare anything" is not
triggered in certain cases when using decltype:

===
template struct A
{
  A() { decltype(this); }
};

A<0> a;
===

It *is* triggered if I make A a non-template class.

This is actually the second testcase from PR51786. While the first one
was successfully fixed, the second testcase still doesn't work.

Btw, clang produces a warning for this case.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51786
[Bug 51786] [c++0x] Invalid declaration with decltype accepted

[Bug tree-optimization/81503] [8 Regression] Wrong code at -O2

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
  if (a + b * -2)
c = (b-1073741824)*-2;

might let you find an earlier culprit.

[Bug c/81500] [8 Regression] ICE with -O3 in process_use, at tree-vect-stmts.c:506

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-21
 CC||marxin at gcc dot gnu.org
Summary|ice with -O3 in |[8 Regression] ICE with -O3
   |process_use, at |in process_use, at
   |tree-vect-stmts.c:506   |tree-vect-stmts.c:506
 Ever confirmed|0   |1

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

[Bug c++/53598] missed diagnostics / equality comparison result unused

[arnaud.bienner at ensimag dot fr]

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

--- Comment #3 from Arnaud Bienner  ---
For the record, bug 62182 (closed as duplicate of this one) contained a patch I
wrote. It's not really working/neat, and I didn't have time to spend more time
on it, but might be useful for someone trying to implement this.

[Bug sanitizer/81505] New: [5/6/7/8 Regression] ICE in tree-ssa-loop-manip.c:95 with -fsanitize=signed-integer-overflow

[marxin at gcc dot gnu.org]

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

Bug ID: 81505
   Summary: [5/6/7/8 Regression] ICE in tree-ssa-loop-manip.c:95
with -fsanitize=signed-integer-overflow
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
marxin at gcc dot gnu.org, mpolacek at gcc dot gnu.org
  Target Milestone: ---

Starting from Marek's commit r218621, we ICE on:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr52298.c
-fsanitize=signed-integer-overflow -O3 -c

during GIMPLE pass: vect
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr52298.c: In
function ‘fn1’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr52298.c:8:1:
internal compiler error: tree check: expected integer_cst, have negate_expr in
get_len, at tree.h:5351
 fn1 ()
 ^~~
0x10e3467 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9848
0x762eda tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3339
0x762eda wi::extended_tree<192>::get_len() const
../../gcc/tree.h:5351
0x762eda wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
../../gcc/wide-int.h:929
0x762eda
wide_int_ref_storage::wide_int_ref_storage
> >(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:976
0x762eda generic_wide_int::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:753
0x762eda bool wi::lts_p >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc/wide-int.h:1794
0x762eda wi::binary_traits >,
generic_wide_int >,
wi::int_traits > >::precision_type,
wi::int_traits >
>::precision_type>::signed_predicate_result operator<
 >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc/wide-int.h:3107
0x762eda tree_int_cst_lt(tree_node const*, tree_node const*)
../../gcc/tree.h:5416
0xf38c1d create_iv(tree_node*, tree_node*, tree_node*, loop*,
gimple_stmt_iterator*, bool, tree_node**, tree_node**)
../../gcc/tree-ssa-loop-manip.c:95
0x175f492 vect_create_data_ref_ptr(gimple*, tree_node*, loop*, tree_node*,
tree_node**, gimple_stmt_iterator*, gimple**, bool, bool*, tree_node*)
../../gcc/tree-vect-data-refs.c:4204
0x1052aa7 vectorizable_load
../../gcc/tree-vect-stmts.c:7360
0x105af69 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*,
_slp_tree*, _slp_instance*)
../../gcc/tree-vect-stmts.c:8645
0x107244c vect_transform_loop(_loop_vec_info*)
../../gcc/tree-vect-loop.c:7544
0x108ce38 vectorize_loops()
../../gcc/tree-vectorizer.c:745
0xf58a71 execute
../../gcc/tree-ssa-loop.c:412

Where my x86_64 tuning is: -mtune=generic -march=x86-64

[Bug tree-optimization/81503] [8 Regression] Wrong code at -O2

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Started with r249447:

gcc/
* match.pd (nop_convert): New predicate.
((A +- CST1) +- CST2): Allow some NOP conversions.

gcc/testsuite/
* gcc.dg/tree-ssa/addadd.c: Un-XFAIL.
* gcc.dg/tree-ssa/addadd-2.c: New file.

[Bug tree-optimization/81503] [8 Regression] Wrong code at -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-21
 CC||wschmidt at gcc dot gnu.org
  Known to work||7.1.1
   Target Milestone|--- |8.0
Summary|Wrong code at -O2   |[8 Regression] Wrong code
   ||at -O2
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Seems to work with GCC 7.

[Bug target/81504] [7/8 Regression] gcc-7 regression: vec_st in loop misoptimized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
Version|unknown |7.1.0
   Target Milestone|--- |7.2
Summary|gcc-7 regression: vec_st|[7/8 Regression] gcc-7
   |in loop misoptimized|regression: vec_st  in loop
   ||misoptimized

[Bug tree-optimization/81303] [8 Regression] 410.bwaves regression caused by r249919

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Fri Jul 21 07:13:57 2017
New Revision: 250416

URL: https://gcc.gnu.org/viewcvs?rev=250416=gcc=rev
Log:
2016-07-21  Richard Biener  

PR tree-optimization/81303
* tree-vect-loop.c (vect_estimate_min_profitable_iters): Take
into account prologue and epilogue iterations when raising
min_profitable_iters to sth at least covering one vector iteration.

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

[Bug target/58502] ICE with attribute(target) and -flto

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.9.3, 5.1.0, 6.1.0
 Resolution|--- |FIXED
  Known to fail||4.9.1, 4.9.2

--- Comment #3 from Volker Reichelt  ---
This is fixed since GCC 4.9.3.

[Bug target/81504] New: gcc-7 regression: vec_st in loop misoptimized

[zoltan at hidvegi dot com]

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

Bug ID: 81504
   Summary: gcc-7 regression: vec_st  in loop misoptimized
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zoltan at hidvegi dot com
CC: wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-unknown-linux-gnu

Created attachment 41802
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41802=edit
gcc-7 -O2, vec_st  in loop misoptimized

The attached code miscompiles with gcc-7 -O2, but gcc-6 produces correct code.
gcc-7 -O1 also generates good code. With gcc-7 -O2 idx is always incremented
before p[idx] is written using vec_st. I've tried to create a minimal testcase
to reproduce the problem, this is not real code. The background on this is that
I needed a pointer wrapper class for ppcle vectors because gcc by default never
uses the lvx / stvx instructions even if it knows an address is aligned, it
always wants to use lxvd2x / xxswapd, and generates tons of unnecessary xxswapd
instructions. I'm aware of attempts to optimize away swaps, but those don't
apply to my application, so I just want to use lvx without the swaps. This is
somehow related to vec_st, since if I use inline asm to generate stvx it works.
It also works if there is no builtin_constant_p check in the rotate_left macro.
It would be really nice if there was a way to disable lane swap optimizations
and allow gcc to use the aligned load/stores when the address is known to be
aligned. On x86 gcc already knows when to use aligned vs. unaligned loads, so
it must be possible on pcc as well. My code can execute over 100 million vector
load and store instructions per second, so removing the swaps have a real
performance impact.

Here is the gcc-7 assembly, note the addi 3,3,16 after the unconditional branch
to L4 is executed before the first stvx 0,0,3, the vector pointer is
incremented before it's ever written:

sldi 9,5,4
srdi 10,4,5
add 3,3,9
addi 9,10,1
mtctr 9
li 8,1
b .L3
.p2align 4,,15
.L2:
stvx 0,0,3
addi 5,5,1
.L3:
#APP
 # 20 "msary_bug.C" 1
rotld 9,8,5
 # 0 "" 2
#NO_APP
mtvsrd 32,9
addi 3,3,16
xxpermdi 32,32,32,0
bdnz .L2
sldi 10,10,5
subf 4,10,4
mtvsrd 32,4
xxpermdi 32,32,32,0
stvx 0,0,3
blr

[Bug tree-optimization/81503] Wrong code at -O2

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Looks like SLSR does an overflow-unsafe transformation, then VRP2 takes
advantage of it. Maybe.

[Bug middle-end/81502] In some cases the data is moved to memory unnecessarily [partial regression]

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-21
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
.optimized dump:

int bar(void*) (void * ptr)
{
  int res;
  __m128i word;
  long unsigned int _2;
  vector(2) long long int word.3_3;
  unsigned int _4;

   [100.00%] [count: INV]:
  _2 = (long unsigned int) ptr_9(D);
  word = { 0, 0 };
  MEM[(char * {ref-all})] = _2;
  word.3_3 = word;
  word ={v} {CLOBBER};
  _4 = BIT_FIELD_REF ;
  res_5 = (int) _4;
  return res_5;

}

We missed turning the memory write into a BIT_INSERT_EXPR, and passes like PRE
missed following the bit_field_expr all the way to _2.

.combine dump:
[...]
(insn 8 3 10 2 (set (reg/v:V2DI 90 [ word ])
(vec_concat:V2DI (reg/v/f:DI 92 [ ptr ])
(const_int 0 [0]))) "b.c":16 3712 {vec_concatv2di}
 (expr_list:REG_DEAD (reg/v/f:DI 92 [ ptr ])
(nil)))
(insn 10 8 15 2 (set (reg:SI 94 [ res ])
(vec_select:SI (subreg:V4SI (reg/v:V2DI 90 [ word ]) 0)
(parallel [
(const_int 0 [0])
]))) "b.c":20 3697 {*vec_extractv4si_0}
 (expr_list:REG_DEAD (reg/v:V2DI 90 [ word ])
(nil)))
[...]

combine tries
(set (reg:SI 94 [ res ])
(vec_select:SI (subreg:V4SI (vec_concat:V2DI (reg/v/f:DI 92 [ ptr ])
(const_int 0 [0])) 0)
(parallel [
(const_int 0 [0])
])))
which we fail to simplify. The xmm1-xmm0 mov is not considered a mov by the
compiler but concatenation with 0, so not a RA problem.

The change of mode (64-bit pointer to 32-bit int) seems to play a big role in
confusing things here.

[Bug c++/80061] error on constexpr function with an unevaluated throw

[matthijsvanduin at gmail dot com]

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

--- Comment #2 from Matthijs van Duin  ---
> void foo( bool ok ) {
 ^constexpr

[Bug c++/80061] error on constexpr function with an unevaluated throw

[matthijsvanduin at gmail dot com]

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

Matthijs van Duin  changed:

   What|Removed |Added

 CC||matthijsvanduin at gmail dot 
com

--- Comment #1 from Matthijs van Duin  ---
Simpler test case:

void foo( bool ok ) {
if( ok )
return;
throw;
}

fails to compile with g++ 6.3.0 and g++ 7.1.0

[Bug c++/67371] Never executed "throw" in constexpr function fails to compile

[matthijsvanduin at gmail dot com]

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

Matthijs van Duin  changed:

   What|Removed |Added

 CC||matthijsvanduin at gmail dot 
com

--- Comment #13 from Matthijs van Duin  ---
This is still not working for me in g++ 6 and 7:

constexpr void foo( bool ok ) {
if( ok )
return;
throw;
}

In function ‘constexpr void foo(bool)’:
error: expression ‘’ is not a constant-expression


Rewriting the code as:

constexpr void foo( bool ok ) {
if( ok )
return;
else
throw;
}

gets rid of the error, but this can be really awkward to do in more complicated
functions.