[Bug tree-optimization/71466] New: wrong code at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 71466
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O3
in both 32-bit and 64-bit modes.

This is a regression from 6.1.x, and goes away with -fno-tree-vrp. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160608 (experimental) [trunk revision 237199] (GCC) 
$ 
$ gcc-trunk -O2 small.c; ./a.out
0
$ gcc-6.1 -O3 small.c; ./a.out
0
$ gcc-trunk -O3 -fno-tree-vrp small.c; ./a.out
0
$ 
$ gcc-trunk -O3 small.c
$ ./a.out
$ 





int a, b, c, d;

void
fn1 ()
{
  for (c = 0; c < 2; c++)
{
  int e, f = 1;
  for (e = 0; e < 2; e++)
{
  if (!f)
return;
  for (d = 0; d; d++)
f = b;
}
}
}

int
main ()
{
  for (; a < 1; a++)
{
  fn1 ();
  __builtin_printf ("0\n");
}
  return 0;
}

[Bug bootstrap/60743] build/genautomata uses 700 MB memory for ARM

[heroxbd at sohu dot com]

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

Benda Xu  changed:

   What|Removed |Added

 CC||heroxbd at sohu dot com

--- Comment #18 from Benda Xu  ---
Redirected to bug 70473.

[Bug target/71310] Bitfields cause load hit store with smaller store and larger load

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
This happens because of

  /* Find the smallest nice mode to use.  */
  for (mode = GET_CLASS_NARROWEST_MODE (MODE_INT); mode != VOIDmode;
   mode = GET_MODE_WIDER_MODE (mode))
if (GET_MODE_BITSIZE (mode) >= bitsize)
  break;

in stor-layout.c:finish_bitfield_representative .

[Bug c++/71465] New: ICE on invalid C++ code (with duplicate base) on x86_64-linux-gnu: in dfs_build_secondary_vptr_vtt_inits, at cp/class.c:9075

[su at cs dot ucdavis.edu]

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

Bug ID: 71465
   Summary: ICE on invalid C++ code (with duplicate base) on
x86_64-linux-gnu: in
dfs_build_secondary_vptr_vtt_inits, at cp/class.c:9075
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk on
x86_64-linux-gnu in both 32-bit and 64-bit modes.

This is a regression from 6.1.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160608 (experimental) [trunk revision 237196] (GCC) 
$ 
$ g++-6.1 -c small.cpp
small.cpp:4:18: error: duplicate base type ‘C’ invalid
 struct D : C, B, C {};
  ^
$  
$ g++-trunk -c small.cpp
small.cpp:4:18: error: duplicate base type ‘C’ invalid
 struct D : C, B, C {};
  ^
small.cpp:4:8: internal compiler error: in dfs_build_secondary_vptr_vtt_inits,
at cp/class.c:9075
 struct D : C, B, C {};
^
0x74907e dfs_build_secondary_vptr_vtt_inits
../../gcc-source-trunk/gcc/cp/class.c:9075
0x80472e dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
../../gcc-source-trunk/gcc/cp/search.c:1798
0x804774 dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
../../gcc-source-trunk/gcc/cp/search.c:1810
0x804774 dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
../../gcc-source-trunk/gcc/cp/search.c:1810
0x807b88 dfs_walk_once(tree_node*, tree_node* (*)(tree_node*, void*),
tree_node* (*)(tree_node*, void*), void*)
../../gcc-source-trunk/gcc/cp/search.c:1895
0x7492cd build_vtt_inits
../../gcc-source-trunk/gcc/cp/class.c:9022
0x74d216 build_vtt
../../gcc-source-trunk/gcc/cp/class.c:8907
0x74d216 finish_struct_1(tree_node*)
../../gcc-source-trunk/gcc/cp/class.c:7070
0x74edb4 finish_struct(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/cp/class.c:7265
0x78875c cp_parser_class_specifier_1
../../gcc-source-trunk/gcc/cp/parser.c:21368
0x78875c cp_parser_class_specifier
../../gcc-source-trunk/gcc/cp/parser.c:21596
0x78875c cp_parser_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:15836
0x79d223 cp_parser_decl_specifier_seq
../../gcc-source-trunk/gcc/cp/parser.c:12758
0x7aa711 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12299
0x7aab61 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12246
0x7b3f40 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12143
0x7b2a14 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12022
0x7b2d48 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4324
0x7b2d48 c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:37502
0x9162f2 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1064
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


-


struct A { virtual void foo () {} };
struct B : virtual A {};
struct C : virtual A {}; 
struct D : C, B, C {};

[Bug c++/71464] New: ICE on invalid C++11 code (with redeclared constructor) at -Os on x86_64-linux-gnu: Segmentation fault

[su at cs dot ucdavis.edu]

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

Bug ID: 71464
   Summary: ICE on invalid C++11 code (with redeclared
constructor) at -Os on x86_64-linux-gnu: Segmentation
fault
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-Os only (but not at the other optimization levels) on x86_64-linux-gnu in both
32-bit and 64-bit modes.

This is a regression from 4.8.x as it seems to affect all 4.9.x and later. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160608 (experimental) [trunk revision 237196] (GCC) 
$ 
$ g++-4.8 -Os -c small.cpp
small.cpp:6:3: error: ‘B::B()’ cannot be overloaded
   B () {};
   ^
small.cpp:5:3: error: with ‘B::B()’
   B () {};
   ^
$ 
$ g++-trunk -Os -c small.cpp
small.cpp:6:3: error: ‘B::B()’ cannot be overloaded
   B () {};
   ^
small.cpp:5:3: error: with ‘B::B()’
   B () {};
   ^
small.cpp:6:9: internal compiler error: Segmentation fault
   B () {};
 ^
0xdaf09f crash_signal
../../gcc-source-trunk/gcc/toplev.c:335
0x1051d71 decl_assembler_name(tree_node*)
../../gcc-source-trunk/gcc/tree.c:668
0x8505e1 cdtor_comdat_group
../../gcc-source-trunk/gcc/cp/optimize.c:151
0x850fd3 maybe_thunk_body
../../gcc-source-trunk/gcc/cp/optimize.c:274
0x85251c maybe_clone_body(tree_node*)
../../gcc-source-trunk/gcc/cp/optimize.c:503
0x8179e7 expand_or_defer_fn_1(tree_node*)
../../gcc-source-trunk/gcc/cp/semantics.c:4193
0x817cb8 expand_or_defer_fn(tree_node*)
../../gcc-source-trunk/gcc/cp/semantics.c:4215
0x7a981b cp_parser_function_definition_after_declarator
../../gcc-source-trunk/gcc/cp/parser.c:25423
0x7ad610 cp_parser_late_parsing_for_member
../../gcc-source-trunk/gcc/cp/parser.c:26255
0x788e29 cp_parser_class_specifier_1
../../gcc-source-trunk/gcc/cp/parser.c:21570
0x788e29 cp_parser_class_specifier
../../gcc-source-trunk/gcc/cp/parser.c:21596
0x788e29 cp_parser_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:15836
0x79d223 cp_parser_decl_specifier_seq
../../gcc-source-trunk/gcc/cp/parser.c:12758
0x7aa711 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12299
0x7aab61 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12246
0x7b3f40 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12143
0x7b2a14 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12022
0x7b2d48 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4324
0x7b2d48 c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:37502
0x9162f2 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1064
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 





struct A {}; 

struct B : virtual A
{
  B () {};
  B () {};
};

[Bug c++/57745] missing recursive lifetime extension within std::initializer_list

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #3 from Richard Smith  ---
Yes, this is now fixed; the remaining difference is a defect in the standard.

[Bug target/71310] Bitfields cause load hit store with smaller store and larger load

[anton at samba dot org]

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

--- Comment #3 from Anton Blanchard  ---
Another case found in the kernel:

struct mmu_gather {
long end;
int fullmm : 1;
};

void __tlb_reset_range(struct mmu_gather *p1)
{
if (p1->fullmm)
p1->end = 0;
}

void tlb_gather_mmu(struct mmu_gather *p1)
{
p1->fullmm = 1;
__tlb_reset_range(p1);
}

  30:   08 00 23 89 lbz r9,8(r3)
  34:   01 00 29 61 ori r9,r9,1
  38:   08 00 23 99 stb r9,8(r3)
  3c:   00 00 42 60 ori r2,r2,0
  40:   08 00 23 e9 ld  r9,8(r3)
  44:   01 00 2a 71 andi.   r10,r9,1
  48:   0c 00 82 41 beq 54 
  4c:   00 00 20 39 li  r9,0
  50:   00 00 23 f9 std r9,0(r3)
  54:   20 00 80 4e blr

[Bug c++/71463] "ignoring attributes on template argument" in -O1 and above

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Well I think the preprocessed source changes between -O0 and -O1 which is why
there is a difference there.

[Bug c++/71463] New: "ignoring attributes on template argument" in -O1 and above

[mail at milianw dot de]

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

Bug ID: 71463
   Summary: "ignoring attributes on template argument" in -O1 and
above
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mail at milianw dot de
  Target Milestone: ---

I've seen this error with gcc (GCC) 6.1.1 20160501 and code like this:

~~
#include 

template struct foo {};
foo emit_unexpected_warning;

int main() { return 0; }
~~

compiling it without optimizations shows no warning, but from -O1 and onwards I
get the unexpected warning on ignored template argument attributes:

~~~
$ g++ -std=c++11 -Wall -Wpedantic -O0 test.cpp
# no warnings
$ g++ -std=c++11 -Wall -Wpedantic -O1 test.cpp
test.cpp:9:24: warning: ignoring attributes on template argument ‘void*
(*)(size_t) throw () {aka void* (*)(long unsigned int) throw ()}’
[-Wignored-attributes]
 foo emit_unexpected_warning;
~~~

Clang does not emit any such warning. I believe it's a false-positive,
especially considering that it only shows up in -O1 and higher, but not -O0.

[Bug c/48116] -Wreturn-type does not work as advertised

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|diagnostic, easyhack|documentation
 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #12 from Martin Sebor  ---
Fixed in r23709 by correcting the manual
.

[Bug c++/71402] -Wunused-variable warnings ignore initialization side effects

[andysem at mail dot ru]

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

--- Comment #12 from andysem at mail dot ru ---
(In reply to Manuel López-Ibáñez from comment #11)
> 5.3 has the bug I mentioned above. It makes the pragmas  believe that, for
> this warning, the location is at the end of the file, which is after the
> pop. Perhaps you can trick gcc by placing another pragma ignored at the end
> of the file. But that will silence all warnings that suffer from this bug.

So that would effectively be equivalent to adding -Wno-unused-variable to the
command line, right? Only more obscure.

[Bug c++/71402] -Wunused-variable warnings ignore initialization side effects

[lopezibanez at gmail dot com]

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

--- Comment #11 from Manuel López-Ibáñez  ---
5.3 has the bug I mentioned above. It makes the pragmas  believe that, for
this warning, the location is at the end of the file, which is after the
pop. Perhaps you can trick gcc by placing another pragma ignored at the end
of the file. But that will silence all warnings that suffer from this bug.

[Bug tree-optimization/71462] New: gcc ICE at -O3 on valid code on x86_64-linux-gnu with “seg fault”

[helloqirun at gmail dot com]

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

Bug ID: 71462
   Summary: gcc ICE at -O3  on valid code on x86_64-linux-gnu with
“seg fault”
   Product: gcc
   Version: 7.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 -O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.

It appears to be a 7 regression.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 7.0.0 20160608 (experimental) [trunk revision 237212] (GCC)


$ gcc-trunk -O3 abc.c
abc.c: In function ‘fn1’:
abc.c:3:6: internal compiler error: Segmentation fault
 void fn1() {
  ^~~
0xb635cf crash_signal
../../gcc/gcc/toplev.c:335
0xcbe6bb ei_container
../../gcc/gcc/basic-block.h:393
0xcbe6bb ei_end_p
../../gcc/gcc/basic-block.h:429
0xcbe6bb ei_cond
../../gcc/gcc/basic-block.h:479
0xcbe6bb find_uses_to_rename_bb
../../gcc/gcc/tree-ssa-loop-manip.c:442
0xcc0a5e find_uses_to_rename
../../gcc/gcc/tree-ssa-loop-manip.c:476
0xcc0a5e rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
../../gcc/gcc/tree-ssa-loop-manip.c:642
0xca5b30 tree_unroll_loops_completely(bool, bool)
../../gcc/gcc/tree-ssa-loop-ivcanon.c:1388
0xca6030 execute
../../gcc/gcc/tree-ssa-loop-ivcanon.c:1531
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.


$ cat abc.c
short a;
long b;
void fn1() {
  int c = a = 1;
  for (; a; a++) {
for (; 9 <= 8;)
  for (;;) {
a = 20;
for (; a <= 35; a++)
  ;
  line:;
  }
if ((c += 264487869) == 9) {
  unsigned *d = 0;
  for (; b;)
d = (unsigned *)
  if (d)
for (;;)
  ;
}
  }
  goto line;
}

[Bug c++/71402] -Wunused-variable warnings ignore initialization side effects

[andysem at mail dot ru]

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

--- Comment #10 from andysem at mail dot ru ---
$ cat gcc_unused_variable.h
class Foo
{
public:
static bool init();
};

static bool FooInit = Foo::init();
$ cat gcc_unused_variable.cpp
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-variable"
#include "gcc_unused_variable.h"
#pragma GCC diagnostic pop

int main()
{
return 0;
}
$ g++ -Wall -O3 -o gcc_unused_variable.o -c gcc_unused_variable.cpp
In file included from gcc_unused_variable.cpp:3:0:
gcc_unused_variable.h:7:13: warning: ‘FooInit’ defined but not used
[-Wunused-variable]
 static bool FooInit = Foo::init();
 ^

[Bug c++/70507] integer overflow builtins not constant expressions

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun  8 19:03:17 2016
New Revision: 237238

URL: https://gcc.gnu.org/viewcvs?rev=237238=gcc=rev
Log:
PR c++/70507
PR c/68120
* builtins.def (BUILT_IN_ADD_OVERFLOW_P, BUILT_IN_SUB_OVERFLOW_P,
BUILT_IN_MUL_OVERFLOW_P): New builtins.
* builtins.c: Include gimple-fold.h.
(fold_builtin_arith_overflow): Handle
BUILT_IN_{ADD,SUB,MUL}_OVERFLOW_P.
(fold_builtin_3): Likewise.
* doc/extend.texi (Integer Overflow Builtins): Document
__builtin_{add,sub,mul}_overflow_p.
gcc/c/
* c-typeck.c (convert_arguments): Don't promote last argument
of BUILT_IN_{ADD,SUB,MUL}_OVERFLOW_P.
gcc/cp/
* constexpr.c: Include gimple-fold.h.
(cxx_eval_internal_function): New function.
(cxx_eval_call_expression): Call it.
(potential_constant_expression_1): Handle integer arithmetic
overflow built-ins.
* tree.c (builtin_valid_in_constant_expr_p): Handle
BUILT_IN_{ADD,SUB,MUL}_OVERFLOW_P.
gcc/c-family/
* c-common.c (check_builtin_function_arguments): Handle
BUILT_IN_{ADD,SUB,MUL}_OVERFLOW_P.
gcc/testsuite/
* c-c++-common/builtin-arith-overflow-1.c: Add test cases.
* c-c++-common/builtin-arith-overflow-2.c: New test.
* g++.dg/ext/builtin-arith-overflow-1.C: New test.
* g++.dg/cpp0x/constexpr-arith-overflow.C: New test.
* g++.dg/cpp1y/constexpr-arith-overflow.C: New test.

Added:
trunk/gcc/testsuite/c-c++-common/builtin-arith-overflow-2.c
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-arith-overflow.C
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-arith-overflow.C
trunk/gcc/testsuite/g++.dg/ext/builtin-arith-overflow-1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/builtins.def
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/tree.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/builtin-arith-overflow-1.c

[Bug c/68120] can't easily deal with integer overflow at compile time

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun  8 19:03:17 2016
New Revision: 237238

URL: https://gcc.gnu.org/viewcvs?rev=237238=gcc=rev
Log:
PR c++/70507
PR c/68120
* builtins.def (BUILT_IN_ADD_OVERFLOW_P, BUILT_IN_SUB_OVERFLOW_P,
BUILT_IN_MUL_OVERFLOW_P): New builtins.
* builtins.c: Include gimple-fold.h.
(fold_builtin_arith_overflow): Handle
BUILT_IN_{ADD,SUB,MUL}_OVERFLOW_P.
(fold_builtin_3): Likewise.
* doc/extend.texi (Integer Overflow Builtins): Document
__builtin_{add,sub,mul}_overflow_p.
gcc/c/
* c-typeck.c (convert_arguments): Don't promote last argument
of BUILT_IN_{ADD,SUB,MUL}_OVERFLOW_P.
gcc/cp/
* constexpr.c: Include gimple-fold.h.
(cxx_eval_internal_function): New function.
(cxx_eval_call_expression): Call it.
(potential_constant_expression_1): Handle integer arithmetic
overflow built-ins.
* tree.c (builtin_valid_in_constant_expr_p): Handle
BUILT_IN_{ADD,SUB,MUL}_OVERFLOW_P.
gcc/c-family/
* c-common.c (check_builtin_function_arguments): Handle
BUILT_IN_{ADD,SUB,MUL}_OVERFLOW_P.
gcc/testsuite/
* c-c++-common/builtin-arith-overflow-1.c: Add test cases.
* c-c++-common/builtin-arith-overflow-2.c: New test.
* g++.dg/ext/builtin-arith-overflow-1.C: New test.
* g++.dg/cpp0x/constexpr-arith-overflow.C: New test.
* g++.dg/cpp1y/constexpr-arith-overflow.C: New test.

Added:
trunk/gcc/testsuite/c-c++-common/builtin-arith-overflow-2.c
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-arith-overflow.C
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-arith-overflow.C
trunk/gcc/testsuite/g++.dg/ext/builtin-arith-overflow-1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/builtins.def
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/tree.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/builtin-arith-overflow-1.c

[Bug c++/71402] -Wunused-variable warnings ignore initialization side effects

[manu at gcc dot gnu.org]

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

--- Comment #9 from Manuel López-Ibáñez  ---
(In reply to andysem from comment #8)
> That testcase probably doesn't verify the fix for pragma since, as you said,
> the warning does not appear in 6.1 in the first place.

I verified it with 5.3.0. You can try many versions of GCC at:
http://melpon.org/wandbox/

[Bug c++/71402] -Wunused-variable warnings ignore initialization side effects

[andysem at mail dot ru]

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

--- Comment #8 from andysem at mail dot ru ---
(In reply to Manuel López-Ibáñez from comment #7)
> 
> In your testcase, this works just fine:

That testcase probably doesn't verify the fix for pragma since, as you said,
the warning does not appear in 6.1 in the first place.

But thank you for your responses anyway.

[Bug c++/71053] [6/7 Regression] Volatile read optimized into endless loop

[michael at weiser dot dinsnail.net]

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

Michael Weiser  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #8 from Michael Weiser  ---
I can confirm that this is fixed with trunk as of r237216 (today) as well as
with 6.1.0 and the patch from bug 71372 applied. Thanks!

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

[Bug c++/71372] [6/7 Regression] C++ FE drops TREE_THIS_VOLATILE in cp_fold on all tcc_reference trees

[michael at weiser dot dinsnail.net]

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

Michael Weiser  changed:

   What|Removed |Added

 CC||michael at weiser dot 
dinsnail.net

--- Comment #18 from Michael Weiser  ---
*** Bug 71053 has been marked as a duplicate of this bug. ***

[Bug c++/71442] [5/6/7 Regression] r232569 breaks -Wunused-*

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/71461] New: missed optimization in conditional assignment

[lhyatt at gmail dot com]

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

Bug ID: 71461
   Summary: missed optimization in conditional assignment
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lhyatt at gmail dot com
  Target Milestone: ---

=
int i, j;
void f1(bool b, int x) {
(b ? i : j) = x;
}
void f2(bool b, int x) {
*(b ?  : ) = x;
}
==

On x86-64 at -O3, gcc outputs different code for f1() vs f2(), using a branch
for f1() and a cmove for f2(). Is it something that can/should be optimized?

gcc (version 5, 6, or current trunk) outputs:
==
f1(bool, int):
testb   %dil, %dil
jne .L6
movl%esi, j(%rip)
ret
.L6:
movl%esi, i(%rip)
ret

f2(bool, int):
testb   %dil, %dil
movl$j, %edx
movl$i, %eax
cmove   %rdx, %rax
movl%esi, (%rax)
ret
==

vs clang:

==
f1(bool, int):# @f1(bool, int)
movl$i, %eax
movl$j, %ecx
testb   %dil, %dil
cmovneq %rax, %rcx
movl%esi, (%rcx)
retq

f2(bool, int):# @f2(bool, int)
movl$i, %eax
movl$j, %ecx
testb   %dil, %dil
cmovneq %rax, %rcx
movl%esi, (%rcx)
retq
==

In my tests, the branch version of f1() is about 2x-3x slower than f2() if the
branch is 50% predicted, and only about 1% faster than f2() if it is 100%
predicted.

FWIW, this version:

==
void f3(bool b, int x) {
if(b) i = x; else j = x;
}
==

ends up using a branch on both gcc and clang.

Thanks...

-Lewis

[Bug c++/71442] [5/6/7 Regression] r232569 breaks -Wunused-*

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun  8 18:05:38 2016
New Revision: 237234

URL: https://gcc.gnu.org/viewcvs?rev=237234=gcc=rev
Log:
PR c++/71442
* pt.c (tsubst_copy): Only set TREE_USED on DECLs.

* g++.dg/cpp0x/Wunused-variable-1.C: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/Wunused-variable-1.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/pt.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/71442] [5/6/7 Regression] r232569 breaks -Wunused-*

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun  8 18:00:30 2016
New Revision: 237233

URL: https://gcc.gnu.org/viewcvs?rev=237233=gcc=rev
Log:
PR c++/71442
* pt.c (tsubst_copy): Only set TREE_USED on DECLs.

* g++.dg/cpp0x/Wunused-variable-1.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/Wunused-variable-1.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/pt.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/71442] [5/6/7 Regression] r232569 breaks -Wunused-*

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun  8 17:57:30 2016
New Revision: 237232

URL: https://gcc.gnu.org/viewcvs?rev=237232=gcc=rev
Log:
PR c++/71442
* pt.c (tsubst_copy): Only set TREE_USED on DECLs.

* g++.dg/cpp0x/Wunused-variable-1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/Wunused-variable-1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug target/56831] [x86] sNaN value as a function call argument

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2016-06-08
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1

--- Comment #2 from Joseph S. Myers  ---
In my view, this is a valid quality-of-implementation bug that should be fixed:
SFmode and DFmode values should only be loaded into x87 FPRs when arithmetic is
to be carried out on them.

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
On Wed, 8 Jun 2016, ch3root at openwall dot com wrote:

> - padding in long double is not copied. Probably ok (in the same way as 
> padding
> in substructures is not always copied);

Yes, I think that's fine in struct copying.

> - sNaNs are turned into qNaNs on x86-32 if traps are turned off. Probably ok 
> if
> sNaNs and qNaNs are considered different representations of the same value;

For *scalar* assignment that would be fine because of TS 18661-1 saying 
"Whether C assignment (6.5.16) (and conversion as if by assignment) to the 
same format is an IEC 60559 convertFormat or copy operation is 
implementation-defined, even if  defines the macro 
FE_SNANS_ALWAYS_SIGNAL (F.2.1).".  It's rather less clear for struct 
assignment.

I expect the present bug is essentially the same as bug 58416 (which 
concerns a union, where the floating-point member isn't even the active 
one).

[Bug target/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #21 from Andrew Pinski  ---
*** Bug 56831 has been marked as a duplicate of this bug. ***

[Bug target/56831] [x86] sNaN value as a function call argument

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 57484.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484#c12 .

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

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think this is really a dup of bug 57484.  The problem is x87 related and
there is not much to be done.

[Bug c++/71402] -Wunused-variable warnings ignore initialization side effects

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez  ---
> Also, I'll add that the warning cannot be silenced with a #pragma, so I
> can't, for example, disable it for libresiprocate headers and leave it
> enabled for my code.

I think either Paolo or me fixed this in GCC 6.1. All warnings should be
affected by pragmas; otherwise it is a bug, please report it. Those bugs are
typically very easy to fix (you could even fix them yourself without any legal
paperwork involved).

In this case, I bet the warning call was:

warning ((TREE_CODE (decl) == FUNCTION_DECL)
? OPT_Wunused_function
: (TREE_READONLY (decl)
   ? OPT_Wunused_const_variable_
   : OPT_Wunused_variable),
"%q+D defined but not used", decl);

and it should be:

warning_at (DECL_SOURCE_LOCATION (decl),
(TREE_CODE (decl) == FUNCTION_DECL)
? OPT_Wunused_function
: (TREE_READONLY (decl)
   ? OPT_Wunused_const_variable_
   : OPT_Wunused_variable),
"%qD defined but not used", decl);


In your testcase, this works just fine:

#pragma GCC diagnostic ignored "-Wunused-variable"
class Foo
{
public:
static bool init();
};

static bool FooInit = Foo::init();

int main()
{
return 0;
}

[Bug tree-optimization/71416] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (vectorizable_live_operation)

[alahay01 at gcc dot gnu.org]

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

alahay01 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||alahay01 at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |alahay01 at gcc dot 
gnu.org

--- Comment #3 from alahay01 at gcc dot gnu.org ---
Looking at the ICE, this looks like a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71407

Tested in my current work-in-progress for 71407 and the ICE looks fixed.

Will roll this testcase into the fix for 71407.

[Bug c++/71402] -Wunused-variable warnings ignore initialization side effects

[andysem at mail dot ru]

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

--- Comment #6 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #5)
> I understand that and agree that there is a set of use cases where users
> don't expect a warning.  There is also another set of cases where a warning
> would be helpful:  If the unused variable in the submitted test case were
> the result of code changes that removed its uses and the variable was left
> defined unintentionally, the user would be served by having this pointed
> out.  Otherwise the dynamic initialization would waste resources.

I think issuing a warning about a perfectly valid code with no reasonable
confidence about the code being written by mistake does a poor job for the user
and encourages him to just disable the warning (possibly missing the real
mistakes that would have been highlighted by the warning).

> Adding a new warning (let's call it
> -Wunused-varible-with-dynamic-initializer) would be one way to provide the
> functionality that I think would be of use.

If the warning for a variable that has dynamic initialization is indeed
considered useful then I vote for the new flag solution. But frankly I think in
practice this warning would be next to useless (e.g. it would have to highlight
almost every mutex lock or scope guard).

> Another solution would be to issue the -Wunused-variable warning for the
> submitted test case and recommend users to annotate otherwise unused
> variables with attribute unused to suppress the warning.  This approach
> would also be in line with the intended use of the new (in C++ 17)
> maybe_unused attribute (proposed in WG21 document P0212R1).

There are large code bases that don't excersize non-portable compiler features
like attributes. One such example is libresiprocate, which has quite a few
flags like the one I described in public headers. This is what actually led to
this bug report.

Also, I'll add that the warning cannot be silenced with a #pragma, so I can't,
for example, disable it for libresiprocate headers and leave it enabled for my
code.

[Bug c++/71459] New: ICE writing to a string-initialized local array in a constexpr function

[msebor at gcc dot gnu.org]

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

Bug ID: 71459
   Summary: ICE writing to a string-initialized local array in a
constexpr function
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

All versions of GCC that support C++ 14 constexpr functions fail with an ICE on
the following valid test case.

$ cat cst.C && /home/msebor/build/gcc-trunk-svn/gcc/xgcc -B
/home/msebor/build/gcc-trunk-svn/gcc -Wall -Wextra -Wpedantic -xc++ cst.C
constexpr int f ()
{
  char a [] = "ab";
  a [1] = 'c';
  return 0; 
}

constexpr int i = f ();
cst.C: In function ‘constexpr int f()’:
cst.C:3:8: warning: variable ‘a’ set but not used [-Wunused-but-set-variable]
   char a [] = "ab";
^
cst.C: At global scope:
cst.C:8:21:   in constexpr expansion of ‘f()’
cst.C:8:22: internal compiler error: tree check: expected constructor, have
string_cst in cxx_eval_store_expression, at cp/constexpr.c:3072
 constexpr int i = f ();
  ^
0x140cc34 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/src/gcc-svn/gcc/tree.c:9752
0x792c15 tree_check(tree_node*, char const*, int, char const*, tree_code)
/src/gcc-svn/gcc/tree.h:3030
0xa6f784 cxx_eval_store_expression
/src/gcc-svn/gcc/cp/constexpr.c:3072
0xa71ccc cxx_eval_constant_expression
/src/gcc-svn/gcc/cp/constexpr.c:3656
0xa727df cxx_eval_constant_expression
/src/gcc-svn/gcc/cp/constexpr.c:3927
0xa71f2e cxx_eval_constant_expression
/src/gcc-svn/gcc/cp/constexpr.c:3697
0xa71f2e cxx_eval_constant_expression
/src/gcc-svn/gcc/cp/constexpr.c:3697
0xa7073a cxx_eval_statement_list
/src/gcc-svn/gcc/cp/constexpr.c:3352
0xa72e5e cxx_eval_constant_expression
/src/gcc-svn/gcc/cp/constexpr.c:3983
0xa72edd cxx_eval_constant_expression
/src/gcc-svn/gcc/cp/constexpr.c:3989
0xa6957c cxx_eval_call_expression
/src/gcc-svn/gcc/cp/constexpr.c:1500
0xa714db cxx_eval_constant_expression
/src/gcc-svn/gcc/cp/constexpr.c:3579
0xa737ca cxx_eval_outermost_constant_expr
/src/gcc-svn/gcc/cp/constexpr.c:4157
0xa73e63 cxx_constant_value(tree_node*, tree_node*)
/src/gcc-svn/gcc/cp/constexpr.c:4255
0x88c6e8 store_init_value(tree_node*, tree_node*, vec**, int)
/src/gcc-svn/gcc/cp/typeck2.c:816
0x7d80de check_initializer
/src/gcc-svn/gcc/cp/decl.c:6172
0x7db1f2 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/src/gcc-svn/gcc/cp/decl.c:6827
0x915ea7 cp_parser_init_declarator
/src/gcc-svn/gcc/cp/parser.c:18697
0x90b184 cp_parser_simple_declaration
/src/gcc-svn/gcc/cp/parser.c:12378
0x90af45 cp_parser_block_declaration
/src/gcc-svn/gcc/cp/parser.c:12246
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/71460] New: Copying structs can trap (on x86-32)

[ch3root at openwall dot com]

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

Bug ID: 71460
   Summary: Copying structs can trap (on x86-32)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

Members of structs that have a floating-point type are sometimes copied as
floating-point numbers instead of just blocks of memory (presumably due to SRA
optimization but it could happens even without optimizations -- see the example
below). There are several consequences on x86-32/64:

- padding in long double is not copied. Probably ok (in the same way as padding
in substructures is not always copied);

- sNaNs are turned into qNaNs on x86-32 if traps are turned off. Probably ok if
sNaNs and qNaNs are considered different representations of the same value;

- sNaNs trap on x86-32 if traps are turned on. This seems to be a problem as
C11, 6.2.6.1p6, specifically says that "[t]he value of a structure or union
object is never a trap representation, even though the value of a member of the
structure or union object may be a trap representation." This is especially
problematic for copying partially initialized structs that are not fully
specified in a standard.

Example for the last item above:

--
#define _GNU_SOURCE
#include 
#include 

int main()
{
  feenableexcept(FE_INVALID);

  struct s { double d; };
  struct s x = {0};
  ((unsigned char *))[7] = 0x7f;
  ((unsigned char *))[6] = 0xf0; // sNaN
  ((unsigned char *))[0] = 0x01;
  struct s y;

  y = x;
  printf("%02x\n", ((unsigned char *))[6]);
}
--

Results:

--
$ gcc -std=c11 -pedantic -Wall -Wextra -fsignaling-nans -lm -m32 test.c &&
./a.out
Floating point exception
--

gcc version: gcc (GCC) 7.0.0 20160608 (experimental)

[Bug tree-optimization/71416] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (vectorizable_live_operation)

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed|2016-06-06 00:00:00 |2016-6-8
 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed on aarch64 as well with:
int a, b, d, e, f, g;
int *c;
void fn2 (int *);
void fn1() { fn2(); }

void fn2(int *p1) {
  for (;;) {
for (; a; a++)
  if (*p1 = g || --f, b)
if (*c)
  d = *p1;
if (*p1)
  break;
  }
}

at -O3 -floop-interchange

[Bug c++/71458] New: ICE with -fsanitize=bounds

[barto at cambridgesemantics dot com]

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

Bug ID: 71458
   Summary: ICE with -fsanitize=bounds
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barto at cambridgesemantics dot com
  Target Milestone: ---

Created attachment 38663
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38663=edit
preprocessed file that fails

Seen with the released 5.4.0 build for Linux
Version: GCC 5.4

System Type: Linux barto-VirtualBox 3.16.0-69-generic #89~14.04.1-Ubuntu SMP
Thu Mar 17 20:51:04 UTC 2016 x86_64 GNU/Linux

Options when configured

../configure --prefix=/opt/ubuntu-tools-5.4 \
--program-suffix=-5.4.0 \
--disable-multilib \
--with-system-zlib \
--enable-lto \
--enable-tls \
--enable-libmpx \
--enable-languages=c,c++

Command line
/home/barto/UnixEnvironment/CSI/asan/toolchain/ubuntu-tools-5.4/bin/g++-5.4.0
-DUSE_GCC54 -c -o /home/barto/UnixEnvironment/CSI/asan/obj/tools/enum_scraper.o
-ggdb -DGCC5=1 -DLINUX=1 -DUSE_ADDRESS_SANITIZER -DUSE_SANTYPE_BOUNDS
-fsanitize=bounds -fcheck-pointer-bounds -mmpx -fPIE -pie
-fno-omit-frame-pointer -fno-optimize-sibling-calls -pipe -march=core2 -m64
-funroll-loops -funit-at-a-time -finline-functions -fweb -frename-registers
-funswitch-loops -ftree-vrp -ftree-vectorize -ftree-slp-vectorize -mfpmath=sse
-fstack-protector-strong -shared -finline-limit=4000 -DFRAME_SIZE -Werror
-Wsign-compare -Wno-long-long -Wreturn-type -Wno-variadic-macros
-Wignored-qualifiers -Wparentheses -Wuninitialized -Wno-unused-function -Wall
-Wextra -Winvalid-pch -Wsign-promo -Wreorder -Warray-bounds
-fdiagnostics-show-option -fno-strict-aliasing -D_BSD_SOURCE -std=gnu++11 -ggdb
-UGPROF -I. -DUSE_DLMALLOC -DUSE_STD_MUTEX -D_GLIBCXX_USE_DEPRECATED=0
-DFULL_RESERVATIONS -DMEM_LIMIT_LEAK_CHECKING -UBIG_CLUSTER -UCOMM2A
-Wno-type-limits -DUSE_ADDRESS_SANITIZER -DUSE_SANTYPE_BOUNDS -fsanitize=bounds
-fcheck-pointer-bounds -mmpx -fPIE -pie -fno-omit-frame-pointer
-fno-optimize-sibling-calls -DLINUX -DSYS=B4_2
-I/home/barto/UnixEnvironment/CSI/asan/obj/tools
/home/barto/UnixEnvironment/CSI/asan/source/tools/enum_scraper.cpp

Output:
/home/barto/UnixEnvironment/CSI/asan/source/tools/enum_scraper.cpp:276:1:
internal compiler error: Segmentation fault
 }
 ^
0xaa024f crash_signal
../../gcc/toplev.c:383
0xb1df68 chkp_walk_pointer_assignments
../../gcc/tree-chkp.c:3693
0xb1f56f chkp_finish_file()
../../gcc/tree-chkp.c:3803

Preprocessed file: enum_scraper.ii

[Bug c++/71402] -Wunused-variable warnings ignore initialization side effects

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
I understand that and agree that there is a set of use cases where users don't
expect a warning.  There is also another set of cases where a warning would be
helpful:  If the unused variable in the submitted test case were the result of
code changes that removed its uses and the variable was left defined
unintentionally, the user would be served by having this pointed out. 
Otherwise the dynamic initialization would waste resources.

Adding a new warning (let's call it -Wunused-varible-with-dynamic-initializer)
would be one way to provide the functionality that I think would be of use.

Another solution would be to issue the -Wunused-variable warning for the
submitted test case and recommend users to annotate otherwise unused variables
with attribute unused to suppress the warning.  This approach would also be in
line with the intended use of the new (in C++ 17) maybe_unused attribute
(proposed in WG21 document P0212R1).

[Bug c++/71402] -Wunused-variable warnings ignore initialization side effects

[andysem at mail dot ru]

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

--- Comment #4 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #2)
> I just happened to be looking into this report and it's not clear to me
> whether or not the warning should be expected in this case.  The
> documentation suggests it should be:
> 
> -Wunused-variable
> Warn whenever a local or static variable is unused aside from its
> declaration.

For the record, I think the warning should not be emitted in the case I
presented in this bug. Yes, the variable itself is not used anywhere beside its
declaration, but nonetheless the declaration is not useless (i.e. its whole
point is to invoke the dynamic initialization). I think the documentation
should be updated to reflect that the warning should not be emitted when the
variable declaration involves dynamic initialization with possible side
effects.

[Bug c++/71053] [6/7 Regression] Volatile read optimized into endless loop

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
I think this is a dup of bug 71372 which has already been fixed.

[Bug c++/55004] [meta-bug] constexpr issues

[msebor at gcc dot gnu.org]

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

Bug 67824 Summary: constexpr char* compare operations not constexpr, but char[] 
operations ARE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67824

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/71457] New: valid pointer plus conversion to bool rejected in constexpr context

[msebor at gcc dot gnu.org]

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

Bug ID: 71457
   Summary: valid pointer plus conversion to bool rejected in
constexpr context
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC rejects both of the following valid constant expressions (Clang accepts
both):

$ cat zzz.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc -B
/home/msebor/build/gcc-trunk-svn/gcc -Wall -Wextra -Wpedantic -xc++ zzz.c
constexpr bool f ()
{
  int i = 1;
  return  + 1;
}

constexpr bool b0 = f ();

constexpr bool b1 = "abc" + 1;

zzz.c:4:15: error: ‘(((& i) + 4u) != 0u)’ is not a constant expression
   return  + 1;
   ^
zzz.c:9:29: error: ‘const char*)"abc") + 1u) != 0u)’ is not a constant
expression
 constexpr bool b1 = "abc" + 1;
 ^

[Bug c++/67824] constexpr char* compare operations not constexpr, but char[] operations ARE

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||7.0
 Resolution|--- |DUPLICATE
  Known to fail|6.0 |6.1.0

--- Comment #5 from Martin Sebor  ---
This is fixed on trunk (7.0) by the patch for bug 71448 committed in r237212.

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

[Bug c++/71448] pointer relational comparison fails inside constant expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||erich.keane at intel dot com

--- Comment #8 from Martin Sebor  ---
*** Bug 67824 has been marked as a duplicate of this bug. ***

[Bug c++/71053] [6/7 Regression] Volatile read optimized into endless loop

[gjl at gcc dot gnu.org]

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

--- Comment #6 from Georg-Johann Lay  ---
(In reply to Michael Weiser from comment #5)
> I think it's well estabilished and verified by now that this is an
> avr-target-specific regression (which I think is what Richard meant).

Well, "avr-specific" would mean that the bug is in the avr backend
(component=target) part of the compiler.  I don't see how the avr backend could
produce different code for C++ vs. C and make a v-qualifier disappear for C++
only and in such an early stage of compilation...

The fact that up to now it has been reproduced for target=avr only does not
necessarily mean it's an avr thing.

> Can I do anything to help debug this further (i.e. try to figure out
> the commit that caused the regression)?

Would be great to see the commit that made the "{v}" disappear from the .ssa
dump.  Same for the commit that introduced the problem; presumably it's the
same commit.  If you use that dump as an indicator you can -fdump-tree-ssa
which should contain a "{v}" -- at least v5.1 dumps and the dumps for C do
contain the "{v}".

[Bug c++/71402] -Wunused-variable warnings ignore initialization side effects

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
For reference, I opened bug 71456 for the problems I noted in comment #2.

[Bug c++/71456] New: missing -Wunused-variable on a static global initialized with another

[msebor at gcc dot gnu.org]

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

Bug ID: 71456
   Summary: missing -Wunused-variable on a static global
initialized with another
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While looking into bug 71402 I noticed that -Wunused-variable doesn't diagnose
unused static namespace scope variables that are dynamically initialized, while
emitting the dynamic initialization for them (see the test case below).

I think this is a problem (defect) for a number of reasons:

1) It doesn't match what the documentation promises:
  -Wunused-variable -- Warn whenever a local or static variable is unused aside
from its declaration.
2) The dynamic initialization (even when mostly optimized away at -O) isn't
without cost that users might want to know might be taking place unnecessarily
(in general, whether or not it is necessary depends on the initializer which
may be a function call, but in trivial cases like the one below it could be
eliminated altogether).
3) The behavior differs from that of Clang which does issue a warning in the
case below and also optimizes the variable out.  (Clang only diagnoses the
dynamic initialization with potential side-effects with -Wglobal-constructors,
and regardless of whether the static variable is used or not.)

I think the subset of (2) where the dynamic initialization has (or could have)
side-effects could be viewed as an enhancement request for a new warning
pointing out that it takes places even though the variable is unused.

I view the rest of this report (i.e., the mismatch with documentation noted in
(1), and the rest of (2) where the dynamic initializer is known not to have
side-effects and could be diagnosed and omitted) as a bug.

$ cat zzz.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc -B
/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout -xc++ zzz.c

static int i;
static int j = i;   // -Wunused-variable warning expected

;; Function void __static_initialization_and_destruction_0(int, int)
(_Z41__static_initialization_and_destruction_0ii, funcdef_no=0, decl_uid=2245,
cgraph_uid=0, symbol_order=2)

void __static_initialization_and_destruction_0(int, int) (int __initialize_p,
int __priority)
{
  int i.0_1;

  :
  if (__initialize_p_3(D) == 1)
goto ;
  else
goto ;

  :
  if (__priority_5(D) == 65535)
goto ;
  else
goto ;

  :
  i.0_1 = i;
  j = i.0_1;

  :
  return;

}



;; Function (static initializers for zzz.c) (_GLOBAL__sub_I_zzz.c,
funcdef_no=1, decl_uid=2249, cgraph_uid=1, symbol_order=3)

(static initializers for zzz.c) ()
{
  :
  __static_initialization_and_destruction_0 (1, 65535);
  return;

}

[Bug c/71455] New: On files with many functions, gcc 4.8.3 is much slower than v4.4.5

[avibl at cadence dot com]

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

Bug ID: 71455
   Summary: On files with many functions, gcc 4.8.3 is much slower
than v4.4.5
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: avibl at cadence dot com
  Target Milestone: ---

Created attachment 38662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38662=edit
compressed tar file with C code and gcc -v output

We’ve recently upgraded from gcc 4.4.5 to 4.8.3 and we noticed that for files
with a large amount of functions compiling with version 4.8.3 is almost an
order of magnitude slower than 4.4.5. This is even without the optimizer.
Attached is an example of such a file and the output of gcc -v with the 2
versions.

Thanks

[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc

[adhemerval.zanella at linaro dot org]

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

--- Comment #10 from Adhemerval Zanella  
---
I think add versioned symbols in libsanitizer seems feasible with current
supported platforms and seems to be the more complete fix. I will check on
that.

[Bug tree-optimization/70729] Loop marked with omp simd pragma is not vectorized

[ysrumyan at gmail dot com]

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

--- Comment #23 from Yuri Rumyantsev  ---
OK. I will try to prepare the second part of patch.
Few comments about vect-simd-clone-5.c test failure.
1. This loop is marked with safelen=MAX_INT.
2. It contains the following stmt's:
D.3301 = foo.simdclone.1 (vect_vec_iv_.25_12, 123, _17);
# VUSE <.MEM_39>
_22 = MEM[(vector(2) long long int[2] *)];
# VUSE <.MEM_39>
_23 = MEM[(vector(2) long long int[2] *) + 16B];
# .MEM_40 = VDEF <.MEM_39>
D.3301 ={v} {CLOBBER};
vect__3.28_24 = VEC_PACK_TRUNC_EXPR <_22, _23>;
 and fuction ref_indep_Loop_p_1 checks that references
 MEM[(vector(2) long long int[2] *)]
and
MEM[(vector(2) long long int[2] *) + 16B]
are independent.
We can avoid such bad behavior of safelen-check (1) put restriction that loop
does not contain non-analyzed references; (2) add additional check that
reference does not have operands defined inside loop (D.3301 in our case).

What approach is more profitable for you?

[Bug libstdc++/71337] temp_directory_path(error_code&) shouldn't throw from !exists(p) || !is_directory(p)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-08
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Somebody forgot to pass the error_code argument down in the implementation,
because he did exactly what the spec said and didn't use any imagination. Bad
somebody.

[Bug fortran/59093] Segfault in gfc_trans_pointer_assignment

[matthew.thompson at nasa dot gov]

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

--- Comment #11 from Matt Thompson  ---
Bug still present in GCC 6.1.0:

(907) $ gfortran  --version
GNU Fortran (GCC) 6.1.0
Copyright (C) 2016 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.

(908) $ gfortran test.F90
test.F90:23:0:

 GRIDIM => LocStream%Ptr%Tiling(:)%IM

internal compiler error: Segmentation fault
0xa94eff crash_signal
../../gcc-6.1.0/gcc/toplev.c:333
0x6edd9d gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*)
../../gcc-6.1.0/gcc/fortran/trans-expr.c:7945
0x6b594a trans_code
../../gcc-6.1.0/gcc/fortran/trans.c:1697
0x6d8cdc gfc_generate_function_code(gfc_namespace*)
../../gcc-6.1.0/gcc/fortran/trans-decl.c:6154
0x6d8b57 gfc_generate_contained_functions
../../gcc-6.1.0/gcc/fortran/trans-decl.c:5144
0x6d8b57 gfc_generate_function_code(gfc_namespace*)
../../gcc-6.1.0/gcc/fortran/trans-decl.c:6083
0x671920 translate_all_program_units
../../gcc-6.1.0/gcc/fortran/parse.c:5613
0x671920 gfc_parse_file()
../../gcc-6.1.0/gcc/fortran/parse.c:5819
0x6b2ab5 gfc_be_parse_file
../../gcc-6.1.0/gcc/fortran/f95-lang.c:201
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/71448] pointer relational comparison fails inside constant expression

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #5)
> That said, I wonder if it is ok that we don't reject clear out of bound
> POINTER_PLUS_EXPR in constexprs, like:
> static constexpr const char foo[] = "foo";
> static constexpr const char *bar = "bar";
> 
> static_assert (foo < foo + 30, "check");
> static_assert (foo != foo + 30, "check");
> static_assert (bar <= bar + 30, "check");
> static_assert (bar != bar + 30, "check");
> 
> But that is preexisting, the patch doesn't really change anything on that,
> and most likely we want to handle this in the FE (if at all).

Those should all be rejected in the static_assert because they are not core
constant expressions as a result of the undefined behavior in the pointer
arithmetic.  Bug 70151 tracks this defect.

[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
The thing is that programs or libraries compiled/linked against glibc 2.24+
might contain garbage in the high 32 bits of those values.
So using e.g. kernel APIs directly in the wrappers will misbehave and so would
the asan etc. diagnostics.
I really think we either should symbol version all of libsanitizer (but the
wrappers around libc functions should use the symbol versions from libc, so it
will be non-fun, because the exact versions differ between different
architectures), or always ignore the high bits, or at runtime check if we are
running against glibc 2.24+ and only ignore the high bits in that case (the
compatibility with pre-2.24 compiled objects would still not be perfect, as
we'd ignore the upper bits when running against glibc 2.24+, but when running
against older glibc we'd honor those).

[Bug middle-end/69526] ivopts candidate strangeness

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de  ---
On Tue, 7 Jun 2016, rdapp at linux dot vnet.ibm.com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
> 
> --- Comment #15 from rdapp at linux dot vnet.ibm.com ---
> Thanks for the suggestions. The omission of the inner op was actually more or
> less on purpose as I intended to capture the
> (convert @inner)
> in order to access @inner's value range as a whole rather than re-calculating
> what VRP already figured out.
> 
> Is there a simple method to access @inner when
> capturing
> (outer_op (convert (inner_op SSA_NAME@0 INTEGER_CST@1)) INTEGER_CST@2))
>^-^
>  @inner
> or, even-better both, @inner as well as @0 and @1, at the same time? (Apart
> from looking through use stmts)
> 
> In my case VRP determines @0's range as ~[0,0] and @inner's as [0,INT_MAX-1].
> VRP probably canonicalized the anti-range to a normal range and performed 
> other
> simplifications in order to arrive at [0,INT_MAX-1]. If I cannot get @inner's
> VRP info with the capture above, would there be another way to obtain it?
> 
> The TREE_OVERFLOW/const_binop code is copied from the (A +- CST) +- CST -> A +
> CST pattern and the result of const_binop is used in the final simplification.
> The overflow check could of course be done via wi::add/sub but wouldn't I just
> replicate what int_const_binop_1 is doing on top of it when I need the result
> anyway?

int_const_binop_1 is legacy, it is better to avoid building an INTEGER_CST
if you throw away the result due to TREE_OVERFLOW.

[Bug tree-optimization/71414] 2x slower than clang summing small float array, GCC should consider larger vectorization factor for "unrolling" reductions

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Tue, 7 Jun 2016, yyc1992 at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71414
> 
> --- Comment #7 from Yichao Yu  ---
> If I add `-fvariable-expansion-in-unroller` (omg this options is like half the
> command line ;-p ...), the performance matches the clang one after the clang
> 3.8 regression.
> 
> ```
> % gcc -funroll-loops -fvariable-expansion-in-unroller -Ofast -march=core-avx2
> benchmark.c -o benchmark2 
> % ./benchmark2 
> 45.588861
> % ./benchmark-gcc
> 80.518152
> % ./benchmark-clang38
> 41.920054
> % ./benchmark-clang37
> 25.093145
> ```

Yeah, but -fvariable-expansion-in-unroller is quite late.

[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc

[adhemerval.zanella at linaro dot org]

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

--- Comment #8 from Adhemerval Zanella  
---
Indeed I did not take in consideration the versioned issue with interposed
wrapper mainly because the idea of the patch was to fix the static compile
asserts against newer glibc.  I see the runtime issue as separated issue.

However regarding the kernel interface, kernel accepts 64-bit msg_iovlen,
msg_controllen and cmsg_len; so it is a matter if libsanitizer also want to
enforce the POSIX compliance in the syscalls for Linux.  One solution is as
Jakub suggested is limit the check to 32-bits values, another might be to
remove the compiler asserts and use the kernel interface instead of defined
POSIX one. I am not sure which is better option.

[Bug tree-optimization/61194] [4.9/5/6/7 Regression] vectorization failed with "bit-precision arithmetic not supported" even if conversion to int is requested

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|4.9.4   |7.0

--- Comment #20 from Richard Biener  ---
All functions in the description are vectorized on trunk so do those from
comment#1 and comment#2.  All but bar2 are vectorized with GCC 6 already.

Thus fixed on trunk (or with GCC5/6 with OMP SIMD aka force-vect).

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rguenth at gcc dot gnu.org]

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

Bug 61194 Summary: [4.9/5/6/7 Regression] vectorization failed with 
"bit-precision arithmetic not supported" even if conversion to int is requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194

   What|Removed |Added

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

[Bug tree-optimization/54939] Very poor vectorization of loops with complex arithmetic

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
With AVX2 we indeed generate

.L4:
vmovupd (%rdx,%rax), %ymm3
addl$1, %r9d
vpermpd $177, %ymm3, %ymm4
vmovapd %ymm3, %ymm2
vmulpd  %ymm6, %ymm4, %ymm4
vfmsub132pd %ymm5, %ymm4, %ymm2
vfmadd132pd %ymm5, %ymm4, %ymm3
vshufpd $10, %ymm3, %ymm2, %ymm2
vaddpd  (%rcx,%rax), %ymm2, %ymm2
vmovupd %ymm2, (%rcx,%rax)
addq$32, %rax
cmpl%esi, %r9d
jb  .L4

thus either there is no addsub for %ymm or there is insufficient pattern
support
for it.  Note that with AVX2 the above is what is generated even with the cost
model as it's now considered a profitable vectorization.

[Bug tree-optimization/54939] Very poor vectorization of loops with complex arithmetic

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
So we now would vectorize this but compute the SLP vectorization as never
profitable.  Generated code with -fno-vect-cost-model (-Ofast -march=corei7):

.L4:
movupd  (%rdx,%rax), %xmm0
movapd  %xmm3, %xmm1
mulpd   %xmm0, %xmm1
palignr $8, %xmm0, %xmm0
mulpd   %xmm2, %xmm0
addsubpd%xmm0, %xmm1
movupd  (%rcx,%rax), %xmm0
addpd   %xmm0, %xmm1
movups  %xmm1, (%rcx,%rax)
addq$16, %rax
cmpq%rsi, %rax
jne .L4

t.f:6:0: note: Cost model analysis:
  Vector inside of loop cost: 15
  Vector prologue cost: 10
  Vector epilogue cost: 0
  Scalar iteration cost: 14
  Scalar outside cost: 6
  Vector outside cost: 10
  prologue iterations: 0
  epilogue iterations: 0
t.f:6:0: note: cost model: the vector iteration cost = 15 divided by the scalar
iteration cost = 14 is greater or equal to the vectorization factor = 1.
t.f:6:0: note: not vectorized: vectorization not profitable.
t.f:6:0: note: not vectorized: vector version will never be profitable.

as it is basically equal to basic-block vectorizing the loop body.  Note that
we pessimistically handle addsubpd as if it were not present and the code
would really end up as

  vect__31.16_42 = vect__27.10_49 - vect__28.15_43;
  vect__31.17_41 = vect__27.10_49 + vect__28.15_43;
  _40 = VEC_PERM_EXPR ;

which is what the vectorizer handles this with (two vector_stmt plus one
vec_perm cost).  The x86 vectorizer cost model would need to be adjusted
for this.

With cost model enabled we fall back to vectorization using interleaving:

.L5:
movupd  (%rax), %xmm5
addl$1, %r9d
addq$32, %rax
addq$32, %r8
movupd  -32(%r8), %xmm1
movupd  -16(%r8), %xmm0
movapd  %xmm5, %xmm2
movapd  %xmm1, %xmm6
movupd  -16(%rax), %xmm9
unpckhpd%xmm0, %xmm1
unpcklpd%xmm0, %xmm6
movapd  %xmm6, %xmm0
mulpd   %xmm8, %xmm0
unpcklpd%xmm9, %xmm2
unpckhpd%xmm9, %xmm5
mulpd   %xmm7, %xmm6
addpd   %xmm0, %xmm2
movapd  %xmm1, %xmm0
mulpd   %xmm7, %xmm0
mulpd   %xmm8, %xmm1
subpd   %xmm0, %xmm2
movapd  %xmm1, %xmm0
addpd   %xmm6, %xmm0
movapd  %xmm2, %xmm1
addpd   %xmm5, %xmm0
unpcklpd%xmm0, %xmm1
unpckhpd%xmm0, %xmm2
movups  %xmm1, -32(%rax)
movups  %xmm2, -16(%rax)
cmpl%esi, %r9d
jb  .L5

t.f:6:0: note: Cost model analysis:
  Vector inside of loop cost: 26
  Vector prologue cost: 10
  Vector epilogue cost: 14
  Scalar iteration cost: 14
  Scalar outside cost: 6
  Vector outside cost: 24
  prologue iterations: 0
  epilogue iterations: 1
  Calculated minimum iters for profitability: 6
t.f:6:0: note:   Runtime profitability threshold = 5
t.f:6:0: note:   Static estimate profitability threshold = 16



Thus this is now a cost model issue.

[Bug tree-optimization/68558] Fails to SLP loop

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Wed Jun  8 13:28:21 2016
New Revision: 237216

URL: https://gcc.gnu.org/viewcvs?rev=237216=gcc=rev
Log:
2016-06-08  Richard Biener  

PR tree-optimization/68558
* gcc.dg/vect/slp-44.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/slp-44.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/68558] Fails to SLP loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
We do SLP vectorize this now with GCC 6 but with vectorization factor 4 because
of the *dest++ = 0; stmt.

Thus, fixed.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rguenth at gcc dot gnu.org]

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

Bug 68558 Summary: Fails to SLP loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68558

   What|Removed |Added

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

[Bug c++/71053] [6/7 Regression] Volatile read optimized into endless loop

[michael at weiser dot dinsnail.net]

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

--- Comment #5 from Michael Weiser  ---
I think it's well estabilished and verified by now that this is an
avr-target-specific regression (which I think is what Richard meant). Is
anybody looking into this? Is more information needed? Can I do anything to
help debug this further (i.e. try to figure out the commit that caused the
regression)?

[Bug tree-optimization/71452] [4.9/5/6 Regression] Wrong optimization of stores to _Bool via char*

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Wed Jun  8 13:11:43 2016
New Revision: 237214

URL: https://gcc.gnu.org/viewcvs?rev=237214=gcc=rev
Log:
2016-06-08  Richard Biener  

PR tree-optimization/71452
* tree-ssa.c (non_rewritable_lvalue_p): Make sure that the
type used for the SSA rewrite has enough precision to cover
the dynamic type of the location.

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

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

[Bug tree-optimization/71452] [4.9/5/6 Regression] Wrong optimization of stores to _Bool via char*

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[4.9/5/6/7 Regression]  |[4.9/5/6 Regression] Wrong
   |Wrong optimization of   |optimization of stores to
   |stores to _Bool via char*   |_Bool via char*

--- Comment #2 from Richard Biener  ---
Fixed on trunk sofar.

[Bug rtl-optimization/71453] Spills to vector registers are sub-optimal.

[ysrumyan at gmail dot com]

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

--- Comment #2 from Yuri Rumyantsev  ---
Forgot to mention that number of instructions is on 10% more 632 vs 702 for
spills into vector registers.

[Bug tree-optimization/71428] [7 Regression] wrong code with -Os -fno-tree-forwprop (breaks in the .bswap dump)

[zsojka at seznam dot cz]

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

--- Comment #7 from Zdenek Sojka  ---
*** Bug 71427 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/71427] [7 Regression] wrong code with -Os -fno-tree-forwprop (breaks in the .bswap dump)

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

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

--- Comment #2 from Zdenek Sojka  ---
It is a duplicate of PR#71428; bugzilla had timeouts while submitting the
report and uploading attachments. Repeated requests resulted in duplicate
attachments and bugreports.

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

[Bug c++/71448] pointer relational comparison fails inside constant expression

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun  8 12:57:26 2016
New Revision: 237212

URL: https://gcc.gnu.org/viewcvs?rev=237212=gcc=rev
Log:
PR c++/71448
* fold-const.c (fold_comparison): Handle CONSTANT_CLASS_P (base0)
the same as DECL_P (base0) for indirect_base0.  Use equality_code
in one further place.

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

Added:
trunk/gcc/testsuite/g++.dg/torture/pr71448.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71427] New: [7 Regression] wrong code with -Os -fno-tree-forwprop (breaks in the .bswap dump)

[marxin at gcc dot gnu.org]

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

Bug ID: 71427
   Summary: [7 Regression] wrong code with -Os -fno-tree-forwprop
(breaks in the .bswap dump)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
CC: marxin at gcc dot gnu.org

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Os -fno-tree-forwprop testcase.c -Wno-psabi
$ ./a.out 
Aborted

Diffing 6-branch and trunk assembly output shows:
@@ -7,10 +7,10 @@
 .LFB0:
.cfi_startproc
mov dx, WORD PTR [rsp+10]
-   or  WORD PTR [rsp+70], dx
mov rax, rdi
lea rsi, [rsp+8]
mov ecx, 16
+   mov WORD PTR [rsp+70], dx
rep movsd
ret
.cfi_endproc


The "or" seems to disappear in the .bswap dump in trunk.
6-branch .bswap doesn't perform any transformation, but trunk's one does.

--- Comment #1 from Martin Liška  ---
Can't reproduce the issue on a Haswell machine, can you please attach
'--verbose' output?

[Bug c++/71451] [4.9/5/6/7 Regression] ICE on invalid C++11 code on x86_64-linux-gnu: in dependent_type_p, at cp/pt.c:22599

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-08
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug fortran/71454] [oop] extend type, missing relationship to baseclass in DWARF

[bernhard.heckel at intel dot com]

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

Bernhard Heckel  changed:

   What|Removed |Added

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

--- Comment #3 from Bernhard Heckel  ---
Yes, it is a duplicate.
The use-case was exactly:

"In this example, x%a and x%t2%a access the component of the parent type"

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

[Bug fortran/49475] [OOP][debugging] Add DWARF info for Fortran's OOP features (extension, member functions)

[bernhard.heckel at intel dot com]

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

Bernhard Heckel  changed:

   What|Removed |Added

 CC||bernhard.heckel at intel dot 
com

--- Comment #3 from Bernhard Heckel  ---
*** Bug 71454 has been marked as a duplicate of this bug. ***

[Bug fortran/71454] [oop] extend type, missing relationship to baseclass in DWARF

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-06-08
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Duplicate/instance of pr49475?

[Bug fortran/71454] [oop] extend type, missing relationship to baseclass in DWARF

[bernhard.heckel at intel dot com]

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

--- Comment #1 from Bernhard Heckel  ---
Created attachment 38661
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38661=edit
Type extend, source example

[Bug fortran/71454] New: [oop] extend type, missing relationship to baseclass in DWARF

[bernhard.heckel at intel dot com]

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

Bug ID: 71454
   Summary: [oop] extend type, missing relationship to baseclass
in DWARF
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernhard.heckel at intel dot com
  Target Milestone: ---

Created attachment 38660
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38660=edit
Dwarf_output

Fortran support type extension. When looking into the DWARF output of such a
type, there is no relation between extended type and baseclass.

The baseclass is handled in DWARF like a struct member of the extended type 
rather then using DW_TAG_inheritance.

[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #7 from Yuri Gribov  ---
Same issue: https://github.com/google/sanitizers/issues/654

[Bug ada/71413] [7 Regression] bootstrap (gnat) broken on arm-linux-gnueabi*

[bernds at gcc dot gnu.org]

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

--- Comment #9 from Bernd Schmidt  ---
Author: bernds
Date: Wed Jun  8 11:41:54 2016
New Revision: 237208

URL: https://gcc.gnu.org/viewcvs?rev=237208=gcc=rev
Log:
PR debug/71432
PR ada/71413
* tree-ssa-strlen.c (handle_builtin_memcmp): Ignore debug insns.

* g++.dg/debug/pr71432.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/debug/pr71432.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug debug/71432] [7 Regression] -fcompare-debug failure (length)

[bernds at gcc dot gnu.org]

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

--- Comment #6 from Bernd Schmidt  ---
Author: bernds
Date: Wed Jun  8 11:41:54 2016
New Revision: 237208

URL: https://gcc.gnu.org/viewcvs?rev=237208=gcc=rev
Log:
PR debug/71432
PR ada/71413
* tree-ssa-strlen.c (handle_builtin_memcmp): Ignore debug insns.

* g++.dg/debug/pr71432.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/debug/pr71432.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug rtl-optimization/71453] Spills to vector registers are sub-optimal.

[ysrumyan at gmail dot com]

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

--- Comment #1 from Yuri Rumyantsev  ---
Created attachment 38659
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38659=edit
test-case to reproduce

Must be compiled with -O2 -march=core-avx2 -m32 options.

[Bug rtl-optimization/71453] New: Spills to vector registers are sub-optimal.

[ysrumyan at gmail dot com]

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

Bug ID: 71453
   Summary: Spills to vector registers are sub-optimal.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com
  Target Milestone: ---

We notice significant performance regression on one important benchmark after
r235523.
Note that fix is not responsible for it. A problem is related to spill/fill
to/from vector registers (aka xmm registers). For example, for attached
test-case we can see a nimber of redundant "vector registers spills" and
movements between them:
vmovd   %ecx, %xmm5
vmovd   %xmm5, %ecx
vmovd   %xmm5, 40(%esp) !! It wil be more profitable to save %ecx on stack.
vmovdqa %xmm3, %xmm5 !! this is completely redundant.
...

There is also another issue with spill to vector registers - we must estimate
profitability of such spill in comparison with spill on stack. For example,
such spill can be not profitable if fill to register is not required:
movl%eax, 44(%esp)  !! spill
...
andl44(%esp), %eax !! fill is not required.

[Bug c++/57745] missing recursive lifetime extension within std::initializer_list

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
 A()
 A()
-
~C()
~B()
~B()
~A()
~A()

This is what I am getting from all recent versions of g++ (including 4.9.N) and
clang++ (as opposed to both ~A before  in 4.8.N). That's not the exact
order asked in the report, is it still wrong or can we consider it fixed?

[Bug c++/71053] [6/7 Regression] Volatile read optimized into endless loop

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P4  |P3
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-08
  Component|target  |c++
 CC||gjl at gcc dot gnu.org
   Host|x86_64-apple-darwin15   |x86_64
 Ever confirmed|0   |1
  Known to fail||7.0
  Build|x86_64-apple-darwin15   |

--- Comment #4 from Georg-Johann Lay  ---
(In reply to Richard Biener from comment #1)
> On x86_64 I get
> 
> main:
> .LFB0:
> .cfi_startproc
> .L2:
> movb1, %al
> testb   $1, %al
> je  .L2
> xorl%eax, %eax
> ret
> 
> and thus it works fine there.  Target issue.

Sorry, I cannot follow your argument.  Test case:

#define REG (*(unsigned char volatile*)0x31)
void foo ()
{
while ((REG & 1) == 1);
}

worsks fine then compiled as C, but for C++

$ avr-gcc -x c++ foo.c -S -Os -fdump-tree-all

I see the following .ssa dump:

;; Function void foo() (_Z3foov, funcdef_no=0, decl_uid=1976, cgraph_uid=0,
symbol_order=0)

void foo() ()
{
  volatile unsigned char * _1;
  unsigned char _2;
  int _3;
  int _4;
  bool retval.0_6;

  :
  _1 = 49B;
  _2 = *_1;
  _3 = (int) _2;
  _4 = _3 & 1;
  retval.0_6 = _4 != 0;
  if (retval.0_6 != 0)
goto ;
  else
goto ;

  :
  return;
}


The dump is missing a {v} qualifier which is present in the dump generated for
C code:

  ...
  _2 ={v} *_1;
  ...

The missing qualifier results in the mentioned wrong optimization in load
invariant motion, see .lim2 dump.

I used avr-gcc built from trunk SVN 236978 from 2016-06-11:

$ ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-7 --disable-shared --disable-nls --with-dwarf2
--enable-target-optspace=yes --with-gnu-as --with-gnu-ld target_alias=avr
--enable-languages=c,c++,lto

[Bug c/65471] type interpretation in _Generic

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|SUSPENDED   |NEW

--- Comment #4 from Marek Polacek  ---
I think no longer SUSPENDED, given
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01054.html .  I'll add the
testcase in Comment 1.

[Bug tree-optimization/71433] [7 Regression] -Warray-bounds false positive with -O2

[vincent-gcc at vinc17 dot net]

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

--- Comment #3 from Vincent Lefèvre  ---
The bug was introduced in r236831.

[Bug c++/71446] Incorrect overload resolution when using designated initializers

[roman.perepelitsa at gmail dot com]

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

--- Comment #1 from Roman Perepelitsa  ---
The same bug can lead to incorrect behaviour at run time.

  #include 
  #include 

  struct S {
int value;
  };

  void F(S) { puts("right"); }
  void F(std::initializer_list) { puts("wrong"); }

  int main() {
F({.value = 0});
  }

Should print "right" but actually prints "wrong".

[Bug tree-optimization/64946] [AArch64] gcc.target/aarch64/vect-abs-compile.c - "abs" vectorization fails for char/short types

[rguenther at suse dot de]

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

--- Comment #22 from rguenther at suse dot de  ---
On Wed, 8 Jun 2016, shiva0217 at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946
> 
> --- Comment #21 from Shiva Chen  ---
> Hi, Richard
> 
> On following example
> 
> int a = ABS_EXPR (b);
> int c = a - 1;
> 
> c will get it's range base on a which is ~[INT_MIN+1, -1]

No, a has [0, INT_MAX] and thus c gets [-1, INT_MAX-1] currently.

> Even if we transfer to 
> 
> int a = (int) ABSU_EXPR (b);
> int c = a - 1;
> 
> Therefore, c still have to consider INT_MIN.

Only now we have to consider INT_MIN.  This is why we should do the
transform to ABSU_EXPR only when it will likely help or when it
doesn't change things.  Like for short types.  Thus

 short s;
 int a = (int) s;
 int b = ABS_EXPR (a);
 int c = b - 1;

can be transformed to

 unsigned short bp = ABSU_EXPR (s);
 int b = (int) bp;
 int c = b - 1;

and VRP analysis result will be unchanged but vectorization is now happy
and ABSU_EXPR does not invoke undefined behavior when s == SHORT_MIN.

[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
I don't see how that would help much.  You still wouldn't know if the recvmsg
or sendmsg that is being called by whatever library and is interposed by
libasan etc. is the one with 64-bit msg_iovlen, msg_controllen or cmsg_len, or
32-bit one.
E.g. in write_msghdr used by recvmsg wrapper, there is:
  if (msg->msg_iov && msg->msg_iovlen)
COMMON_INTERCEPTOR_WRITE_RANGE(ctx, msg->msg_iov,
   sizeof(*msg->msg_iov) * msg->msg_iovlen);
  write_iovec(ctx, msg->msg_iov, msg->msg_iovlen, maxlen);
The broken change committed to llvm repo makes this a static choice - if you
compile libsanitizer against glibc older than 2.24, you assume msg_iovlen must
be always 64-bit, even if you e.g. at runtime link against glibc 2.24 and run a
program that uses recvmsg@@GLIBC_2.24.
If you compile libsanitizer against glibc 2.24+, you assume msg_iovlen must be
always 32-bit, even if the app calls recvmsg@GLIBC_2.2.5.  Not sure what dlsym
actually gives you in that case, I think recvmsg@@GLIBC_2.24, but it would need
to be verified.
What we could do is just assume people don't really use > 2G values in these
cases, and just use (int) msg->msg_iovlen instead of msg->msg_iovlen (for Linux
only).  Similarly for the other two fields, and perhaps keep the structures as
is and just make the size and offset checks for these fields accept all the
expected variants (i.e. also the case where the glibc headers have the field
half the size and for big endian also at a different offset (difference of half
the size).
For e.g. asan, this would just mean that programs linked against glibc < 2.24
that use > 2GB msg_iovlen and overwrite through that some buffer wouldn't be
detected, I think that is sufficiently rare that it might be acceptable.
Over time more and more programs/libraries will be rebuilt against glibc >=
2.24 and the problem will go away there.

[Bug c++/71169] [7 Regression] ICE on invalid C++ code in pop_nested_class (cp/class.c:7785)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-08
 Ever confirmed|0   |1

[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc

[m.ostapenko at samsung dot com]

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

--- Comment #5 from Maxim Ostapenko  ---
Can we use dlvsym for versioned symbols (recvmsg, sendmsg, etc) in the
wrappers?

[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
That change looks wrong to me though.
If glibc has added symbol versioning and changed ABI for existing symbols that
sanitizer libraries wrap, then I'm afraid either we need to start symbol
versioning libsanitizer too (and make sure to use the same symbol version glibc
uses for the various symbols in there, so e.g. on x86_64 libasan would need to
export recvmsg@GLIBC_2.2.5 and recgmsg@@GLIBC_2.24), or the wrappers need to be
changed (if at all possible), so that they provide ABI compatibility, so that
it will work well for apps linked against the pre-glibc-2.24
{recvmsg,sendmsg,recvmmsg,sendmmsg} (whatever else changed) as well as apps
linked agains the new one.  I doubt a plain change in the structure layout is
sufficient here.

[Bug c/71255] Implement #pragma may_alias

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|SUSPENDED

--- Comment #29 from Marek Polacek  ---
Given the above, I'm suspending this PR for the time being.

[Bug c/71255] Implement #pragma may_alias

[fw at gcc dot gnu.org]

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

--- Comment #28 from Florian Weimer  ---
We can put such a version check into the glibc headers and see how it works out
in practice.  As long as there is consensus to fix any related breakage
(related to the attribute and forward declarations) for the GCC 7 release, this
should work.  I think we won't need a may_alias pragma after all.

[Bug c/71255] Implement #pragma may_alias

[mpolacek at gcc dot gnu.org]

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

--- Comment #27 from Marek Polacek  ---
Typo: I meant __GNUC__ >= 7 as this is fixed for GCC 7 and onwards.

[Bug c++/71450] [7 Regression] ICE on invalid C++11 code on x86_64-linux-gnu: in tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_base, at cp/search

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-08
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug tree-optimization/64946] [AArch64] gcc.target/aarch64/vect-abs-compile.c - "abs" vectorization fails for char/short types

[shiva0217 at gmail dot com]

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

--- Comment #21 from Shiva Chen  ---
Hi, Richard

On following example

int a = ABS_EXPR (b);
int c = a - 1;

c will get it's range base on a which is ~[INT_MIN+1, -1]

Even if we transfer to 

int a = (int) ABSU_EXPR (b);
int c = a - 1;

Therefore, c still have to consider INT_MIN.

or you mean that we could transfer like

unsigned int a = ABSU_EXPR (b);
int c = (int) (a - 1)

Then we could simplify value range analysis until convert back to int.

we could get

a : [0, -INT_MIN]
a - 1 : [0, INT_MAX] and UINT_MAX
c : [-1, INT_MAX]

[Bug c/71255] Implement #pragma may_alias

[mpolacek at gcc dot gnu.org]

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

--- Comment #26 from Marek Polacek  ---
(In reply to Florian Weimer from comment #22)
> (In reply to Marek Polacek from comment #21)
> > The testcase in Comment 14 should now compile fine.
> 
> What's the best way to detect that a compiler has this fix?  We cannot use a
> configure check.  Is there anything better than looking at __GNUC__?  Are
> you going to backport this fix?  Thanks.

I'm not planning on backporting this, so I think the best way is to check
__GNUC__ > 7.

Now, I'm kind of flummoxed.  Is there any need for the new pragma anymore?  The
other C testcase in Comment 16 compiles without warnings I think.  I wouldn't
want to spend time implementing a new #pragma that is useless ;).

[Bug c++/57433] Local classes have an associated namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Yep, seems like G++ is doing the right thing here.