[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[olegendo at gcc dot gnu.org]

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

--- Comment #22 from Oleg Endo  ---
(In reply to Oleg Endo from comment #21)
> 
> It seems the patch is not good.  I see new failures when testing on sh-elf. 
> I will try to see what's going on there.

False alarm.  Those were other unrelated changes on trunk.

[Bug target/69789] g++ -O2 is removing tests against a variable that can be changed

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
This works in GCC 6 on aarch64 as far as I can tell.

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[olegendo at gcc dot gnu.org]

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

--- Comment #21 from Oleg Endo  ---
(In reply to Oleg Endo from comment #17)
> 
> 
> I guess because the recently added "sibcall_value_pcrel_fdpic" pattern also
> uses "=k" as the clobber constraint, it might run into the same problem.  To
> play safe for now, I'd like to commit the following to trunk and backport it
> to 5 and possibly 4.9:
> 
> [...]

It seems the patch is not good.  I see new failures when testing on sh-elf.  I
will try to see what's going on there.

[Bug tree-optimization/69802] New: gcc ICE at -O1 and above 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=69802

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

It might be a regression from 4.7.


$ 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/6.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 6.0.0 20160212 (experimental) [trunk revision 233377] (GCC)




$ gcc-trunk abc.c -c -O3
abc.c: In function 'fn1':
abc.c:5:5: internal compiler error: Segmentation fault
 int fn1() {
 ^~~
0xb5df2f crash_signal
../../gcc/gcc/toplev.c:335
0x8d12c9 bb_seq_addr
../../gcc/gcc/gimple.h:1654
0x8d12c9 gsi_start_bb
../../gcc/gcc/gimple-iterator.h:129
0x8d12c9 gsi_for_stmt(gimple*)
../../gcc/gcc/gimple-iterator.c:617
0xcf4a27 update_range_test
../../gcc/gcc/tree-ssa-reassoc.c:2099
0xcfc178 optimize_range_tests
../../gcc/gcc/tree-ssa-reassoc.c:2638
0xd0034d reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:4882
0xcfffb7 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:4960
0xd026ba do_reassoc
../../gcc/gcc/tree-ssa-reassoc.c:5074
0xd026ba execute_reassoc
../../gcc/gcc/tree-ssa-reassoc.c:5161
0xd026ba execute
../../gcc/gcc/tree-ssa-reassoc.c:5200
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
struct S {
  unsigned f1 : 1;
};
int d, a;
int fn1() {
  unsigned b = 0;
  struct S c;
  d = ((1 && b) < c.f1) & c.f1;
  return a;
}

[Bug tree-optimization/69801] New: gcc ICE on valid code on x86_64-linux-gnu in "operand_equal_p"

[helloqirun at gmail dot com]

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

Bug ID: 69801
   Summary: gcc ICE  on valid code on x86_64-linux-gnu in
"operand_equal_p"
   Product: gcc
   Version: 6.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
on x86_64-linux-gnu in both 32-bit and 64-bit modes.



(*) But a nearly identical case can pass.



$ 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/6.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 6.0.0 20160212 (experimental) [trunk revision 233377] (GCC)



$ gcc-trunk abc.c -c
abc.c: In function 'fn1':
abc.c:5:1: internal compiler error: in operand_equal_p, at fold-const.c:2776
 void fn1() { e ? (d ? b : c).c : (d ? b : c).c; }
 ^~~~
0x872dc5 operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../gcc/gcc/fold-const.c:2776
0x871c2e operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../gcc/gcc/fold-const.c:2982
0x872378 operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../gcc/gcc/fold-const.c:3123
0x8714c6 operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../gcc/gcc/fold-const.c:3067
0x8711ca operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../gcc/gcc/fold-const.c:3091
0xf5ff61 generic_simplify_COND_EXPR
/home/absozero/trunk/build-gcc/gcc/generic-match.c:26035
0xf5ff61 generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)
/home/absozero/trunk/build-gcc/gcc/generic-match.c:26273
0x87e93c fold_ternary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)
../../gcc/gcc/fold-const.c:11406
0x880ee3 fold_build3_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)
../../gcc/gcc/fold-const.c:12506
0x68b7e3 c_fully_fold_internal
../../gcc/gcc/c/c-fold.c:506
0x68cd4b c_fully_fold(tree_node*, bool, bool*)
../../gcc/gcc/c/c-fold.c:90
0x629a0f c_process_expr_stmt(unsigned int, tree_node*)
../../gcc/gcc/c/c-typeck.c:10231
0x629e0d c_finish_expr_stmt(unsigned int, tree_node*)
../../gcc/gcc/c/c-typeck.c:10276
0x6770d0 c_parser_statement_after_labels
../../gcc/gcc/c/c-parser.c:5275
0x678d5b c_parser_compound_statement_nostart
../../gcc/gcc/c/c-parser.c:4859
0x6795de c_parser_compound_statement
../../gcc/gcc/c/c-parser.c:4695
0x675144 c_parser_declaration_or_fndef
../../gcc/gcc/c/c-parser.c:2107
0x68089d c_parser_external_declaration
../../gcc/gcc/c/c-parser.c:1551
0x6812c9 c_parser_translation_unit
../../gcc/gcc/c/c-parser.c:1429
0x6812c9 c_parse_file()
../../gcc/gcc/c/c-parser.c:17826
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
struct {
  char c[1];
} b, c;
int d, e;
void fn1() { e ? (d ? b : c).c : (d ? b : c).c; }



A nearly identical case:
$ diff abc.c a.c
5c5
< void fn1() { e ? (d ? b : c).c : (d ? b : c).c; }
---
> void fn1() { e ? (d ? b : c).c : (e ? b : c).c; }

$ gcc-trunk a.c -c

Syntactically, variables d and e should be treated in the same way.

[Bug c/69798] ICE on invalid code on x86_64-linux-gnu in c_parser_braced_init, at c/c-parser.c:4338

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code

--- Comment #1 from Andrew Pinski  ---
>It is a regression from 5.3.x. 

Not really because:
> small.c:4: confused by earlier errors, bailing out
Means there was an ICE after an error happened but due to checking not being
enabled, report that ICE this way so it is likely to be reported as GCC bug and
they fix their code first :).

[Bug tree-optimization/69800] New: FAIL: g++.dg/tree-ssa/pr61034.C -std=gnu++98 scan-tree-dump-times optimized "free" 4

[danglin at gcc dot gnu.org]

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

Bug ID: 69800
   Summary: FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++98
scan-tree-dump-times optimized "free" 4
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

Created attachment 37677
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37677&action=edit
Tree dump

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/h
ome/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/tree-ssa/pr61034.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -O2 -fdump-tree-fre3 -fdump-tree-optimized -S -o pr61034.sPASS:
g++.dg/tree-ssa/pr61034.C  -std=gnu++98 (test for excess errors)
PASS: g++.dg/tree-ssa/pr61034.C  -std=gnu++98  scan-tree-dump-times fre3 ";;
Function" 1PASS: g++.dg/tree-ssa/pr61034.C  -std=gnu++98  scan-tree-dump-times
fre3 "unreachable" 11PASS: g++.dg/tree-ssa/pr61034.C  -std=gnu++98 
scan-tree-dump-times fre3 "free" 14FAIL: g++.dg/tree-ssa/pr61034.C 
-std=gnu++98  scan-tree-dump-times optimized "free" 4

Also:
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++11  scan-tree-dump-times optimized
"free" 4
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++14  scan-tree-dump-times optimized
"free" 4

[Bug libfortran/69799] New: FAIL: gfortran.dg/coarray_allocate_3.f08 at -O1 and above

[danglin at gcc dot gnu.org]

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

Bug ID: 69799
   Summary: FAIL: gfortran.dg/coarray_allocate_3.f08 at -O1 and
above
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

spawn -ignore SIGHUP
/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran1/../../gfortran
-B/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran1/../../
-B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/coarray_allocate_3.f08
-fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -fcoarray=single
-B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs -lm -o
./coarray_allocate_3.exePASS: gfortran.dg/coarray_allocate_3.f08   -O1  (test
for excess errors)Setting LD_LIBRARY_PATH to
.:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs:/home/dave/gnu/gcc/objdir/gcc:
.:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs:/home/dave/gnu/gc
c/objdir/hppa-linux-gnu/./libgfortran/.libs:/home/dave/gnu/gcc/objdir/hppa-linux
-gnu/./libatomic/.libs:/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/h
ppa-linux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/li
bssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu
/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home
/dave/gnu/gcc/objdir/./prev-gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc
spawn [open ...]

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

Backtrace for this error:


(gdb) r
Starting program:
/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran/coarray_allocate_3.exe 

Program received signal SIGSEGV, Segmentation fault.
0xfc481c04 in __GI___libc_free (mem=0x1) at malloc.c:2928
2928malloc.c: No such file or directory.
(gdb) bt
#0  0xfc481c04 in __GI___libc_free (mem=0x1) at malloc.c:2928
#1  0x00010cd8 in MAIN__ ()
at
/home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/coarray_allocate_3.f08:26
#2  main (argc=, argv=)
at
/home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/coarray_allocate_3.f08:27
#3  0xfc41a3ec in __libc_start_main (main=@0x121fa: 0x108e8 , argc=1, 
argv=0xfd703020, init=, fini=, 
rtld_fini=, stack_end=) at libc-start.c:291
#4  0x000106b8 in _start ()

[Bug target/67636] [6 Regression][SH] gcc.target/sh/pr54236-1.c failures

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #3 from Oleg Endo  ---
Fixed the symptoms on trunk.

[Bug testsuite/69583] FAIL: gcc.dg/tree-ssa/sra-17.c scan-tree-dump-times esra "Removing load: a = \\*\\.?LC\\.?\\.?0;" 1

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #2 from John David Anglin  ---
Fixed.

[Bug c/69798] New: ICE on invalid code on x86_64-linux-gnu in c_parser_braced_init, at c/c-parser.c:4338

[su at cs dot ucdavis.edu]

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

Bug ID: 69798
   Summary: ICE on invalid code on x86_64-linux-gnu in
c_parser_braced_init, at c/c-parser.c:4338
   Product: gcc
   Version: 6.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.  

It is a regression from 5.3.x. 


$ 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/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160212 (experimental) [trunk revision 233377] (GCC) 
$ 
$ 
$ 
$ gcc-5.3 -c small.c
small.c: In function ‘main’:
small.c:4:3: error: -fcilkplus must be enabled to use ‘_Cilk_spawn’
   _Cilk_spawn (void); 
   ^
small.c:4: confused by earlier errors, bailing out
$ 
$ 
$
$ gcc-trunk -c small.c
small.c: In function ‘main’:
small.c:4:3: error: -fcilkplus must be enabled to use ‘_Cilk_spawn’
   _Cilk_spawn (void);
   ^~~
small.c:4:3: internal compiler error: in c_parser_braced_init, at
c/c-parser.c:4338
0x628b9d c_parser_braced_init
../../gcc-trunk/gcc/c/c-parser.c:4338
0x628da0 c_parser_postfix_expression_after_paren_type
../../gcc-trunk/gcc/c/c-parser.c:8092
0x61ed02 c_parser_postfix_expression
../../gcc-trunk/gcc/c/c-parser.c:7521
0x61f173 c_parser_postfix_expression
../../gcc-trunk/gcc/c/c-parser.c:8013
0x6202ba c_parser_unary_expression
../../gcc-trunk/gcc/c/c-parser.c:6876
0x6210b7 c_parser_cast_expression
../../gcc-trunk/gcc/c/c-parser.c:6705
0x6212d5 c_parser_binary_expression
../../gcc-trunk/gcc/c/c-parser.c:6514
0x622045 c_parser_conditional_expression
../../gcc-trunk/gcc/c/c-parser.c:6285
0x6226e0 c_parser_expr_no_commas
../../gcc-trunk/gcc/c/c-parser.c:6202
0x622e42 c_parser_expression
../../gcc-trunk/gcc/c/c-parser.c:8387
0x623889 c_parser_expression_conv
../../gcc-trunk/gcc/c/c-parser.c:8420
0x63d001 c_parser_statement_after_labels
../../gcc-trunk/gcc/c/c-parser.c:5275
0x63ec9b c_parser_compound_statement_nostart
../../gcc-trunk/gcc/c/c-parser.c:4859
0x63f51e c_parser_compound_statement
../../gcc-trunk/gcc/c/c-parser.c:4695
0x63b084 c_parser_declaration_or_fndef
../../gcc-trunk/gcc/c/c-parser.c:2107
0x6467dd c_parser_external_declaration
../../gcc-trunk/gcc/c/c-parser.c:1551
0x647209 c_parser_translation_unit
../../gcc-trunk/gcc/c/c-parser.c:1429
0x647209 c_parse_file()
../../gcc-trunk/gcc/c/c-parser.c:17826
0x6a85d2 c_common_parse_file()
../../gcc-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.
$ 


--


int 
main ()
{
  _Cilk_spawn (void); 
  return 0;
}

[Bug c++/69797] New: ICE on invalid code on x86_64-linux-gnu in operator[], at vec.h:714

[su at cs dot ucdavis.edu]

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

Bug ID: 69797
   Summary: ICE on invalid code on x86_64-linux-gnu in operator[],
at vec.h:714
   Product: gcc
   Version: 6.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.  

This also affects 4.8.x and later releases, and is a regression from 4.7.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/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160212 (experimental) [trunk revision 233377] (GCC) 
$ 
$ 
$ 
$ g++-4.7 -c small.cc
small.cc: In function ‘void fn1()’:
small.cc:4:23: error: too few arguments to function ‘__atomic_fetch_add’
$ 
$ 
$ 
$ g++-trunk -c small.cc
small.cc: In function ‘void fn1()’:
small.cc:4:23: internal compiler error: in operator[], at vec.h:714
   __atomic_fetch_add ();
   ^
0x8643c2 vec::operator[](unsigned int)
../../gcc-trunk/gcc/vec.h:714
0x8643c2 resolve_overloaded_atomic_exchange
../../gcc-trunk/gcc/c-family/c-common.c:11030
0x8643c2 resolve_overloaded_builtin(unsigned int, tree_node*, vec*)
../../gcc-trunk/gcc/c-family/c-common.c:11305
0x781c2a finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc-trunk/gcc/cp/semantics.c:2381
0x6fe182 cp_parser_postfix_expression
../../gcc-trunk/gcc/cp/parser.c:6902
0x6fc28c cp_parser_unary_expression
../../gcc-trunk/gcc/cp/parser.c:7989
0x706557 cp_parser_cast_expression
../../gcc-trunk/gcc/cp/parser.c:8666
0x706aed cp_parser_binary_expression
../../gcc-trunk/gcc/cp/parser.c:8767
0x707390 cp_parser_assignment_expression
../../gcc-trunk/gcc/cp/parser.c:9054
0x709d6a cp_parser_expression
../../gcc-trunk/gcc/cp/parser.c:9223
0x70a313 cp_parser_expression_statement
../../gcc-trunk/gcc/cp/parser.c:10684
0x71958e cp_parser_statement
../../gcc-trunk/gcc/cp/parser.c:10535
0x719f94 cp_parser_statement_seq_opt
../../gcc-trunk/gcc/cp/parser.c:10807
0x71a09f cp_parser_compound_statement
../../gcc-trunk/gcc/cp/parser.c:10761
0x71a1fd cp_parser_function_body
../../gcc-trunk/gcc/cp/parser.c:20641
0x71a1fd cp_parser_ctor_initializer_opt_and_function_body
../../gcc-trunk/gcc/cp/parser.c:20677
0x71acb1 cp_parser_function_definition_after_declarator
../../gcc-trunk/gcc/cp/parser.c:25309
0x71b904 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-trunk/gcc/cp/parser.c:25221
0x71b904 cp_parser_init_declarator
../../gcc-trunk/gcc/cp/parser.c:18419
0x71bb1b cp_parser_simple_declaration
../../gcc-trunk/gcc/cp/parser.c:12359
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.
$ 


---


void
fn1 () 
{
  __atomic_fetch_add ();
}

[Bug target/66183] FAIL: gcc.dg/torture/pr66123.c

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #2 from John David Anglin  ---
Fixed by someone.

[Bug testsuite/65900] FAIL: gcc.dg/pr65345-2.c (test for excess errors)

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
  Build|hppa2.0w-hp-hpux11.11   |hppa64-hp-hpux11.11

--- Comment #1 from John David Anglin  ---
Resolved by:
/* { dg-require-effective-target sync_int_long } */

[Bug c/69796] New: ICE on invalid code in useless_type_conversion_p, at gimple-expr.c:83

[su at cs dot ucdavis.edu]

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

Bug ID: 69796
   Summary: ICE on invalid code in useless_type_conversion_p, at
gimple-expr.c:83
   Product: gcc
   Version: unknown
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.  

This is a regression from 5.3.x. 


$ 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/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160212 (experimental) [trunk revision 233377] (GCC) 
$ 
$ gcc-5.3 -c small.c
small.c: In function ‘fn1’:
small.c:5:3: error: expression statement has incomplete type
   s a;
   ^
small.c:5:5: error: expected ‘;’ before ‘a’
   s a;
 ^
$ 
$ gcc-trunk -c small.c
small.c: In function ‘fn1’:
small.c:5:3: error: expression statement has incomplete type
   s a;
   ^
small.c:5:5: error: expected ‘;’ before ‘a’
   s a;
 ^
small.c: At top level:
small.c:1:10: error: storage size of ‘s’ isn’t known
 struct S s;
  ^
small.c: In function ‘fn1’:
small.c:5:3: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:83
   s a;
   ^
0xda28b7 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-trunk/gcc/tree.c:9688
0x893e70 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc-trunk/gcc/tree.h:3129
0x893e70 useless_type_conversion_p(tree_node*, tree_node*)
../../gcc-trunk/gcc/gimple-expr.c:83
0xd1e68b tree_ssa_strip_useless_type_conversions(tree_node*)
../../gcc-trunk/gcc/tree-ssa.c:1160
0x8bbd97 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-trunk/gcc/gimplify.c:10056
0x8c15f6 gimplify_stmt(tree_node**, gimple**)
../../gcc-trunk/gcc/gimplify.c:5643
0x8c2835 gimplify_bind_expr
../../gcc-trunk/gcc/gimplify.c:1142
0x8bc8d2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-trunk/gcc/gimplify.c:10362
0x8c15f6 gimplify_stmt(tree_node**, gimple**)
../../gcc-trunk/gcc/gimplify.c:5643
0x8c3454 gimplify_body(tree_node*, bool)
../../gcc-trunk/gcc/gimplify.c:11294
0x8c3ae6 gimplify_function_tree(tree_node*)
../../gcc-trunk/gcc/gimplify.c:11450
0x74cbe7 cgraph_node::analyze()
../../gcc-trunk/gcc/cgraphunit.c:625
0x74ff53 analyze_functions
../../gcc-trunk/gcc/cgraphunit.c:1080
0x750c38 symbol_table::finalize_compilation_unit()
../../gcc-trunk/gcc/cgraphunit.c:2534
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 S s; 

void fn1 ()
{
  s a;
}

[Bug target/64345] [SH] Improve single bit extraction

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  ---
Author: olegendo
Date: Sat Feb 13 00:50:25 2016
New Revision: 233397

URL: https://gcc.gnu.org/viewcvs?rev=233397&root=gcc&view=rev
Log:
gcc/
PR target/67636
PR target/64345
* config/sh/sh.md (*zero_extract_3): New insn_and_split pattern.

gcc/testsuite/
PR target/67636
PR target/64345
* gcc.target/sh/pr54236-1.c: Adjust optimization level.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/sh/pr54236-1.c

[Bug target/67636] [6 Regression][SH] gcc.target/sh/pr54236-1.c failures

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  ---
Author: olegendo
Date: Sat Feb 13 00:50:25 2016
New Revision: 233397

URL: https://gcc.gnu.org/viewcvs?rev=233397&root=gcc&view=rev
Log:
gcc/
PR target/67636
PR target/64345
* config/sh/sh.md (*zero_extract_3): New insn_and_split pattern.

gcc/testsuite/
PR target/67636
PR target/64345
* gcc.target/sh/pr54236-1.c: Adjust optimization level.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/sh/pr54236-1.c

[Bug c++/69795] New: g++ ICE on invalid code on x86_64-linux-gnu in "reject_gcc_builtin"

[helloqirun at gmail dot com]

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

Bug ID: 69795
   Summary: g++ ICE on invalid code on x86_64-linux-gnu in
"reject_gcc_builtin"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

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

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.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 6.0.0 20160212 (experimental) [trunk revision 233377] (GCC) 



$ g++-trunk abc.cc
abc.cc:1:27: error: expected end of capture-list
 int freopen ( freopen += *[
   ^
abc.cc: In lambda function:
abc.cc:1:27: error: expected ‘{’ at end of input
abc.cc: At global scope:
abc.cc:1:27: internal compiler error: tree check: expected function_decl, have
var_decl in reject_gcc_builtin, at c-family/c-common.c:12620
0xfb074c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9637
0x89cf16 tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3262
0x89cf16 reject_gcc_builtin(tree_node const*, unsigned int)
../../gcc/gcc/c-family/c-common.c:12620
0x668f1c mark_rvalue_use(tree_node*, unsigned int, bool)
../../gcc/gcc/cp/expr.c:99
0x7eaa74 rvalue(tree_node*)
../../gcc/gcc/cp/tree.c:716
0x7eadad stabilize_expr(tree_node*, tree_node**)
../../gcc/gcc/cp/tree.c:4209
0x7805bf cp_build_modify_expr(tree_node*, tree_code, tree_node*, int)
../../gcc/gcc/cp/typeck.c:7704
0x62f275 build_new_op_1
../../gcc/gcc/cp/call.c:5740
0x62fa4e build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc/gcc/cp/call.c:5824
0x781ceb build_x_modify_expr(unsigned int, tree_node*, tree_code, tree_node*,
int)
../../gcc/gcc/cp/typeck.c:7899
0x7416f6 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9095
0x741877 cp_parser_constant_expression
../../gcc/gcc/cp/parser.c:9324
0x742e2a cp_parser_parenthesized_expression_list
../../gcc/gcc/cp/parser.c:7454
0x7438d6 cp_parser_initializer
../../gcc/gcc/cp/parser.c:20730
0x7552dd cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:18594
0x755beb cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12359
0x755f7a cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12235
0x75ecde cp_parser_declaration
../../gcc/gcc/cp/parser.c:12132
0x75d646 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12011
0x75d958 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4321
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.cc
int freopen ( freopen += *[

[Bug libstdc++/69794] New: [5 Regression] std::regex_search match failure with regex object with flags grep|icase

[andrey.vul at gmail dot com]

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

Bug ID: 69794
   Summary: [5 Regression] std::regex_search match failure with
regex object with flags grep|icase
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.vul at gmail dot com
  Target Milestone: ---

I have observed a regression in std::regex_search when the regex object has
flags grep | icase and is multi-line for grep semantics.

The following testcase works as expected in GCC 4.9.3 and clang 3.7 with
libc++.
The failing behavior is observed in gcc 5.3.0 and is reproducible when gcc 5.3
stdlib is used with clang 3.7.

Gcc 5.1 and 5.2 were not tested.

TC:
// begin re.cc
#include 
#include 

int main() {
std::string re_str
{   "/abcd" "\n"
"/aecf" "\n"
"/ghci"
};
auto rx = std::regex(re_str, std::regex_constants::grep |
std::regex_constants::icase);
std::cmatch result;
return !std::regex_search("/abcd", result, rx);
}
// end re.cc

INVOCATION:
gcc -std=c++11 re.cc && ./a.out; echo $?

OUTPUT:
EXPECTED: 0
ACTUAL: 1

GCC VERSION:
gcc -v:
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/5.3.0/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/5.3.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.3.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.3.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/5.3.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 5.3.0 p1.0, pie-0.6.5' --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj
--enable-libgomp --disable-libmudflap --disable-libssp --enable-libcilkrts
--enable-lto --with-isl --disable-isl-version-check --enable-libsanitizer
Thread model: posix
gcc version 5.3.0 (Gentoo 5.3.0 p1.0, pie-0.6.5)

[Bug fortran/57553] [F08] Valid use of STORAGE_SIZE rejected, bad error message for invalid use

[anlauf at gmx dot de]

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

--- Comment #6 from Harald Anlauf  ---
(In reply to Harald Anlauf from comment #5)

I think I mixed up gfc_option.warn_std and gfc_option.allow_std
in the previous patch.  A revised version follows:

Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c  (revision 233388)
+++ gcc/fortran/expr.c  (working copy)
@@ -2264,6 +2264,15 @@
 "new_line", NULL
   };

+  /* std=f2008+ or -std=gnu */
+  static const char *const inquiry_func_gnu[] = {
+"lbound", "shape", "size", "ubound",
+"bit_size", "len", "kind",
+"digits", "epsilon", "huge", "maxexponent", "minexponent",
+"precision", "radix", "range", "tiny",
+"new_line", "storage_size", NULL
+  };
+
   int i = 0;
   gfc_actual_arglist *ap;

@@ -2290,8 +2299,11 @@
 {
   name = e->symtree->n.sym->name;

-  functions = (gfc_option.warn_std & GFC_STD_F2003)
+  /* Choose appropriate set.  Note that -std=gnu is std=f2008+ */
+  functions = (gfc_option.allow_std & GFC_STD_F2003)
? inquiry_func_f2003 : inquiry_func_f95;
+  functions = (gfc_option.allow_std & GFC_STD_F2008)
+   ? inquiry_func_gnu : functions;

   for (i = 0; functions[i]; i++)
if (strcmp (functions[i], name) == 0)

[Bug c++/69793] New: g++ ICE on invalid code on x86_64-linux-gnu in "cp_lexer_peek_nth_token"

[helloqirun at gmail dot com]

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

Bug ID: 69793
   Summary: g++ ICE on invalid code on x86_64-linux-gnu in
"cp_lexer_peek_nth_token"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

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

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.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 6.0.0 20160212 (experimental) [trunk revision 233377] (GCC) 



$ g++-trunk abc.cc
abc.cc:2:12: error: ‘state’ has not been declared
 template < state > bool operator!= (fpos,; operator!=
^
abc.cc:2:42: error: expected identifier before ‘;’ token
 template < state > bool operator!= (fpos,; operator!=
  ^
abc.cc:2:42: error: expected ‘)’ before ‘;’ token
abc.cc:2:52: internal compiler error: in cp_lexer_peek_nth_token, at
cp/parser.c:1055
 template < state > bool operator!= (fpos,; operator!=
^~
0x7249d2 cp_lexer_peek_nth_token
../../gcc/gcc/cp/parser.c:1055
0x7478af cp_parser_template_id
../../gcc/gcc/cp/parser.c:14829
0x748e9a cp_parser_type_name
../../gcc/gcc/cp/parser.c:16364
0x737451 cp_parser_type_name
../../gcc/gcc/cp/parser.c:16335
0x737451 cp_parser_simple_type_specifier
../../gcc/gcc/cp/parser.c:16249
0x7334ad cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:15902
0x7486e1 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:12745
0x755b31 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12288
0x755f7a cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12235
0x75ecde cp_parser_declaration
../../gcc/gcc/cp/parser.c:12132
0x75d646 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12011
0x75d958 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4321
0x75d958 c_parse_file()
../../gcc/gcc/cp/parser.c:37383
0x8b6632 c_common_parse_file()
../../gcc/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.


$ cat abc.cc
class fpos;
template < state > bool operator!= (fpos,; operator!=

[Bug rtl-optimization/69737] [5 Regression] FAIL: gcc.c-torture/execute/pr64682.c -O2 execution test

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #4 from Segher Boessenkool  ---
Fixed everywhere.

[Bug preprocessor/69792] New: spurious warning for UDL declaration with parenthesized literal-operator-id

[redi at gcc dot gnu.org]

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

Bug ID: 69792
   Summary: spurious warning for UDL declaration with
parenthesized literal-operator-id
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This example surrounds operator""_min in parentheses, to protect it from
macros:

#define _min(a, b) (((a) < (b)) ? (a) : (b))
long double (operator""_min)(long double m) { return m; }
long double d = 1.0_min;

But the preprocessor thinks that (operator""_min) is a string literal followed
by a token, and so complains there is no whitespace:

bug.cc:2:22: warning: invalid suffix on literal; C++11 requires a space between
literal and string macro [-Wliteral-suffix]
 long double (operator""_min)(long double m) { return m; }
  ^

This isn't a literal with an invalid suffix, but a literal-operator-id.

There's a simple workaround, which is to add the suggested whitespace, which
works, but not for the reason the preprocessor thinks it works :-)

[Bug bootstrap/69791] New: ICE in ultimate_transparent_alias_target, at varasm.c:1263

[dilyan.palauzov at aegee dot org]

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

Bug ID: 69791
   Summary: ICE in ultimate_transparent_alias_target, at
varasm.c:1263
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
  Target Milestone: ---

When I try to pass -flto gcc from  is compiled (most recent version from git),
I get the following error:

export GCC=yes
export enable_static=no
export enable_shared=yes
export CFLAGS="-pipe -O3 -fno-fat-lto-objects -flto"
export CXXFLAGS="-pipe -O3 -fno-fat-lto-objects -flto"
export LDFLAGS="-Wl,-O1,-z,relro,-s -flto=4  -L/lib64"
export enable_silent_rules=yes




[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory '/home/d/gcc'
make[2]: Entering directory '/home/d/gcc'
make[3]: Entering directory '/home/d/gcc'
rm -f stage_current
make[3]: Leaving directory '/home/d/gcc'
make[2]: Leaving directory '/home/d/gcc'
make[2]: Entering directory '/home/d/gcc'
make[3]: Entering directory '/home/d/gcc/libiberty'
make[4]: Entering directory '/home/d/gcc/libiberty/testsuite'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory '/home/d/gcc/libiberty/testsuite'
make[3]: Leaving directory '/home/d/gcc/libiberty'
make[3]: Entering directory '/home/d/gcc/lto-plugin'
make  all-am
make[4]: Entering directory '/home/d/gcc/lto-plugin'
make[4]: Leaving directory '/home/d/gcc/lto-plugin'
make[3]: Leaving directory '/home/d/gcc/lto-plugin'
make[3]: Entering directory '/home/d/gcc/intl'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/d/gcc/intl'
make[3]: Entering directory '/home/d/gcc/build-x86_64-pc-linux-gnu/libiberty'
make[4]: Entering directory
'/home/d/gcc/build-x86_64-pc-linux-gnu/libiberty/testsuite'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory
'/home/d/gcc/build-x86_64-pc-linux-gnu/libiberty/testsuite'
make[3]: Leaving directory '/home/d/gcc/build-x86_64-pc-linux-gnu/libiberty'
make[3]: Entering directory '/home/d/gcc/build-x86_64-pc-linux-gnu/fixincludes'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/d/gcc/build-x86_64-pc-linux-gnu/fixincludes'
make[3]: Entering directory '/home/d/gcc/build-x86_64-pc-linux-gnu/libcpp'
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[3]: Leaving directory '/home/d/gcc/build-x86_64-pc-linux-gnu/libcpp'
make[3]: Entering directory '/home/d/gcc/libbacktrace'
make  all-am
make[4]: Entering directory '/home/d/gcc/libbacktrace'
true  DO=all multi-do # make
make[4]: Leaving directory '/home/d/gcc/libbacktrace'
make[3]: Leaving directory '/home/d/gcc/libbacktrace'
make[3]: Entering directory '/home/d/gcc/libcpp'
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[3]: Leaving directory '/home/d/gcc/libcpp'
make[3]: Entering directory '/home/d/gcc/libdecnumber'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/d/gcc/libdecnumber'
make[3]: Entering directory '/home/d/gcc/gcc'
make[3]: Leaving directory '/home/d/gcc/gcc'
Checking multilib configuration for libgcc...
make[3]: Entering directory '/home/d/gcc/x86_64-pc-linux-gnu/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
# Early copyback; see "all" above for the rationale.  The
# early copy is necessary so that the gcc -B options find
# the right startup files when linking shared libgcc.
/bin/bash /git/gcc/libgcc/../mkinstalldirs ../.././gcc
parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o crtprec32.o
crtprec64.o crtprec80.o crtfastmath.o";\
for file in $parts; do  \
  rm -f ../.././gcc/$file;  \
  /usr/local/bin/install -c -m 644 $file ../.././gcc/;  \
  case $file in \
*.a)\
  /usr/local/x86_64-pc-linux-gnu/bin/ranlib ../.././gcc/$file ;;\
  esac; \
done
# @multilib_flags@ is still needed because this may use
# /home/d/gcc/./gcc/xgcc -B/home/d/gcc/./gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-includeand -O2  -g -O2 -pipe -O3
-fno-fat-lto-objects -flto -DIN_GCC -fPIC   -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector  directly.
# @multilib_dir@ is not really necessary, but sometimes it has
# more uses than just a directory name.
/bin/bash /git/gcc/libgcc/../mkinstalldirs .
/home/d/gcc/./gcc/xgcc -B/home/d/gcc/./gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/loca

[Bug bootstrap/69790] New: LTO compiling GCC does not work (lib/bfd-plugin path has unclear location)

[dilyan.palauzov at aegee dot org]

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

Bug ID: 69790
   Summary: LTO compiling GCC does not work (lib/bfd-plugin path
has unclear location)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
  Target Milestone: ---

On my system, when I compile gcc using -flto -O3 (meaning LTO is applied to the
compiler) I face the problem, that liblto_plugin.so on my system is installed
under /usr/local/lib/bfd-plugins , where binutils accepts it.  But nm compiled
during bootstrapping gcc looks for the plugins under
/usr/local/x86_64-pc-linux-gnu/lib/bfd-plugins .

nm compiled as part of binutils and as part of gcc should look at the same
location for gcc plugins.

[Bug rtl-optimization/69789] g++ -O2 is removing tests against a variable that can be changed

[tmark at isc dot org]

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

--- Comment #1 from Thomas Markwalder  ---
Created attachment 37676
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37676&action=edit
compressed compilation temp file

[Bug rtl-optimization/69789] New: g++ -O2 is removing tests against a variable that can be changed

[tmark at isc dot org]

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

Bug ID: 69789
   Summary: g++ -O2 is removing tests against a variable that can
be changed
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tmark at isc dot org
  Target Milestone: ---

Our Kea project uses boost::asio. When compiled with gcc 5.3.1 and -O2, the
optimizer is incorrectly removing tests against a variable which can be changed
from one of the boost::asio functions.

1. gcc --version output:

Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)

2. OS info:

Linux fedora23-64-1 4.3.4-300.fc23.x86_64 #1 SMP Mon Jan 25 13:39:23 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux

3. Compiler command line:

g++ -DHAVE_CONFIG_H -I. -I../../../..  -I../../../../src/lib
-I../../../../src/lib  -DTEST_DATA_DIR=\"./testdata\" -I/opt/gtest/gtest-1.7.0
-I/opt/gtest/gtest-1.7.0/include -DOS_LINUX  -I../../../../ext/coroutine
-DBOOST_ASIO_HEADER_ONLY -DBOOST_ASIO_DISABLE_THREADS=1
-DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_SYSTEM_NO_DEPRECATED -Wall -Wextra
-Wnon-virtual-dtor -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare
-pthread -Werror -fPIC -Wno-missing-field-initializers -Wno-unused-parameter -g
-O2 -save-temps -MT run_unittests-udp_socket_unittest.o -MD -MP -MF
.deps/run_unittests-udp_socket_unittest.Tpo -c -o
run_unittests-udp_socket_unittest.o `test -f 'udp_socket_unittest.cc' || echo
'./'`udp_socket_unittest.cc

4. I have attached the .ii file

5. BOOST Info:

Version 1.58

The affected function is in the file:

  /usr/include/boost/asio/detail/impl/socket_ops.ipp

and is excerpted below. The tests for ec against interrupted,
would_block, and try_again are optimized out, cauing the function
to always return true:


bool non_blocking_recvfrom(socket_type s,
buf* bufs, size_t count, int flags,
socket_addr_type* addr, std::size_t* addrlen,
boost::system::error_code& ec, size_t& bytes_transferred)
{
  for (;;)
  {
// Read some data.
signed_size_type bytes = socket_ops::recvfrom(
s, bufs, count, flags, addr, addrlen, ec);

// Retry operation if interrupted by signal.
if (ec == boost::asio::error::interrupted)
  continue;

// Check if we need to run the operation again.
if (ec == boost::asio::error::would_block
|| ec == boost::asio::error::try_again)
  return false;

// Operation is complete.
if (bytes >= 0)
{
  ec = boost::system::error_code();
  bytes_transferred = bytes;
}
else
  bytes_transferred = 0;

return true;
  }
}

[Bug fortran/69668] [4.9/5/6 Regression] Error reading namelist opened with DELIM='NONE'

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Feb 12 21:02:02 2016
New Revision: 233388

URL: https://gcc.gnu.org/viewcvs?rev=233388&root=gcc&view=rev
Log:
2016-02-12  Jerry DeLisle  

PR libgfortran/69668
* gfortran.dg/namelist_88.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/namelist_88.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/69788] New: FAIL: gfortran.dg/derived_constructor_comps_6.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

Bug ID: 69788
   Summary: FAIL: gfortran.dg/derived_constructor_comps_6.f90 -O0
execution test
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

Test was fixed exposing fail:

spawn /mnt/gnu/gcc/objdir-test/gcc/testsuite/gfortran/../../gfortran
-B/mnt/gnu/gc
c/objdir-test/gcc/testsuite/gfortran/../../
-B/mnt/gnu/gcc/objdir-test/hppa2.0w-hp
-hpux11.11/./libgfortran/
/mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/derived_const
ructor_comps_6.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never -O0
-peda
ntic-errors -fdump-tree-original
-B/mnt/gnu/gcc/objdir-test/hppa2.0w-hp-hpux11.11/
./libgfortran/.libs
-L/mnt/gnu/gcc/objdir-test/hppa2.0w-hp-hpux11.11/./libgfortran
/.libs -L/mnt/gnu/gcc/objdir-test/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
-L/mnt
/gnu/gcc/objdir-test/hppa2.0w-hp-hpux11.11/./libatomic/.libs
-B/mnt/gnu/gcc/objdir
-test/hppa2.0w-hp-hpux11.11/./libquadmath/.libs
-L/mnt/gnu/gcc/objdir-test/hppa2.0
w-hp-hpux11.11/./libquadmath/.libs
-L/mnt/gnu/gcc/objdir-test/hppa2.0w-hp-hpux11.1
1/./libquadmath/.libs -lm -o ./derived_constructor_comps_6.exe
PASS: gfortran.dg/derived_constructor_comps_6.f90   -O0  (test for excess
errors)
Setting LD_LIBRARY_PATH to
.:/mnt/gnu/gcc/objdir-test/hppa2.0w-hp-hpux11.11/./libg
fortran/.libs:/mnt/gnu/gcc/objdir-test/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/
mnt/gnu/gcc/objdir-test/hppa2.0w-hp-hpux11.11/./libatomic/.libs:/mnt/gnu/gcc/objdi
r-test/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/mnt/gnu/gcc/objdir-test/hppa2.0w
-hp-hpux11.11/./libquadmath/.libs:/mnt/gnu/gcc/objdir/gcc:.:/mnt/gnu/gcc/objdir-te
st/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/mnt/gnu/gcc/objdir-test/hppa2.0w-hp-
hpux11.11/./libgfortran/.libs:/mnt/gnu/gcc/objdir-test/hppa2.0w-hp-hpux11.11/./lib
atomic/.libs:/mnt/gnu/gcc/objdir-test/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/m
nt/gnu/gcc/objdir-test/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/mnt/gnu/gcc/objd
ir/gcc
spawn [open ...]
At line 80 of file
/mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/derived_constructor_comps_6.f90
Fortran runtime error: Attempt to DEALLOCATE unallocated 'tmpca'
FAIL: gfortran.dg/derived_constructor_comps_6.f90   -O0  execution test
PASS: gfortran.dg/derived_constructor_comps_6.f90   -O0   scan-tree-dump-times
original "__builtin_malloc" 15
PASS: gfortran.dg/derived_constructor_comps_6.f90   -O0   scan-tree-dump-times
original "__builtin_free" 33

[Bug fortran/69668] [4.9/5/6 Regression] Error reading namelist opened with DELIM='NONE'

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Feb 12 19:52:13 2016
New Revision: 233387

URL: https://gcc.gnu.org/viewcvs?rev=233387&root=gcc&view=rev
Log:
2016-02-12  Jerry DeLisle  

PR libgfortran/69668
* io/list_read.c (read_character): Remove code related to DELIM_NONE.

PR libgfortran/69668
* gfortran.dg/namelist_38.f90: Update test.
* gfortran.dg/namelist_84.f90: Update test.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/namelist_38.f90
trunk/gcc/testsuite/gfortran.dg/namelist_84.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c

[Bug other/69554] [6 Regression] Multi-location diagnostics writes too many lines

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #19 from David Malcolm  ---
Should be fixed as of r233386; marking this as resolved.

[Bug fortran/60526] [4.9/5/6 Regression] Accepts-invalid: Variable name same as type name

[dmalcolm at gcc dot gnu.org]

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

Bug 69554 Summary: [6 Regression] Multi-location diagnostics writes too many 
lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554

   What|Removed |Added

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

[Bug other/69554] [6 Regression] Multi-location diagnostics writes too many lines

[dmalcolm at gcc dot gnu.org]

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

--- Comment #18 from David Malcolm  ---
Author: dmalcolm
Date: Fri Feb 12 19:18:03 2016
New Revision: 233386

URL: https://gcc.gnu.org/viewcvs?rev=233386&root=gcc&view=rev
Log:
PR other/69554: avoid excessive source printing for widely-separated locations

gcc/ChangeLog:
PR other/69554
* diagnostic-show-locus.c (struct line_span): New struct.
(layout::get_first_line): Delete.
(layout::get_last_line): Delete.
(layout::get_num_line_spans): New member function.
(layout::get_line_span): Likewise.
(layout::print_heading_for_line_span_index_p): Likewise.
(layout::get_expanded_location): Likewise.
(layout::calculate_line_spans): Likewise.
(layout::m_first_line): Delete.
(layout::m_last_line): Delete.
(layout::m_line_spans): New field.
(layout::layout): Update comment.  Replace m_first_line and
m_last_line with m_line_spans, replacing their initialization
with a call to calculate_line_spans.
(diagnostic_show_locus): When printing source lines and
annotations, rather than looping over a single span
of lines, instead loop over each line_span within
the layout, with an inner loop over the lines within them.
Call the context's start_span callback when changing line spans.
* diagnostic.c (diagnostic_initialize): Initialize start_span.
(diagnostic_build_prefix): Break out the building of the location
part of the string into...
(diagnostic_get_location_text): ...this new function, rewriting
it from nested ternary expressions to a sequence of "if"
statements.
(default_diagnostic_start_span_fn): New function.
* diagnostic.h (diagnostic_start_span_fn): New typedef.
(diagnostic_context::start_span): New field.
(default_diagnostic_start_span_fn): New prototype.

gcc/fortran/ChangeLog:
PR other/69554
* error.c (gfc_diagnostic_start_span): New function.
(gfc_diagnostics_init): Initialize global_dc's start_span.

gcc/testsuite/ChangeLog:
PR other/69554
* gcc.dg/pr69554-1.c: New test.
* gfortran.dg/pr69554-1.F90: New test.
* gfortran.dg/pr69554-2.F90: New test.
* lib/gcc-dg.exp (proc dg-locus): New function.
* lib/gfortran-dg.exp (proc gfortran-dg-test): Update comment to
distinguish between the caret-printing and non-caret-printing
cases.  If caret-printing has been explicitly enabled, bail out
without attempting to fix up the output.


Added:
trunk/gcc/testsuite/gcc.dg/pr69554-1.c
trunk/gcc/testsuite/gfortran.dg/pr69554-1.F90
trunk/gcc/testsuite/gfortran.dg/pr69554-2.F90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic-show-locus.c
trunk/gcc/diagnostic.c
trunk/gcc/diagnostic.h
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/error.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/gcc-dg.exp
trunk/gcc/testsuite/lib/gfortran-dg.exp

[Bug driver/69779] [6 Regression] Invalid free in driver::finalize on s390x running libgccjit

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by r233385; marking as resolved.

[Note to self: whilst debugging this I ran into a valgrind bug on s390x with
the "popcnt" insn: https://bugzilla.redhat.com/show_bug.cgi?id=1306844 ]

[Bug driver/69779] [6 Regression] Invalid free in driver::finalize on s390x running libgccjit

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Author: dmalcolm
Date: Fri Feb 12 18:37:35 2016
New Revision: 233385

URL: https://gcc.gnu.org/viewcvs?rev=233385&root=gcc&view=rev
Log:
PR driver/69779: fix bogus cleanup code used by libgccjit affecting s390x

gcc/ChangeLog:
PR driver/69779
* gcc.c (driver::finalize): Fix cleanup of "specs".


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

[Bug rtl-optimization/69737] [5 Regression] FAIL: gcc.c-torture/execute/pr64682.c -O2 execution test

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Author: segher
Date: Fri Feb 12 18:32:21 2016
New Revision: 233384

URL: https://gcc.gnu.org/viewcvs?rev=233384&root=gcc&view=rev
Log:
combine: More distribute_notes trouble (PR69737)

PR64682 is a problem in distribute_notes, where it has trouble putting
a REG_DEAD note for a reg that is set twice in the right spot.  My fix
for that did the wrong thing for PR69567.  And then my attempted fix
for that one made PR64682 fail again.

Instead, let's just lose the note in such complicated cases, like we
already do in certain similar cases.


Backport from mainline
2016-02-11  Segher Boessenkool  

PR rtl-optimization/64682
PR rtl-optimization/69567
PR rtl-optimization/69737
* combine.c (distribute_notes) : If the register is set
in I2 as well, just lose it.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/combine.c

[Bug rtl-optimization/64682] [5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
Author: segher
Date: Fri Feb 12 18:32:21 2016
New Revision: 233384

URL: https://gcc.gnu.org/viewcvs?rev=233384&root=gcc&view=rev
Log:
combine: More distribute_notes trouble (PR69737)

PR64682 is a problem in distribute_notes, where it has trouble putting
a REG_DEAD note for a reg that is set twice in the right spot.  My fix
for that did the wrong thing for PR69567.  And then my attempted fix
for that one made PR64682 fail again.

Instead, let's just lose the note in such complicated cases, like we
already do in certain similar cases.


Backport from mainline
2016-02-11  Segher Boessenkool  

PR rtl-optimization/64682
PR rtl-optimization/69567
PR rtl-optimization/69737
* combine.c (distribute_notes) : If the register is set
in I2 as well, just lose it.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/combine.c

[Bug rtl-optimization/69567] PowerPC64: cstore optimisation produces bad code

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
Author: segher
Date: Fri Feb 12 18:32:21 2016
New Revision: 233384

URL: https://gcc.gnu.org/viewcvs?rev=233384&root=gcc&view=rev
Log:
combine: More distribute_notes trouble (PR69737)

PR64682 is a problem in distribute_notes, where it has trouble putting
a REG_DEAD note for a reg that is set twice in the right spot.  My fix
for that did the wrong thing for PR69567.  And then my attempted fix
for that one made PR64682 fail again.

Instead, let's just lose the note in such complicated cases, like we
already do in certain similar cases.


Backport from mainline
2016-02-11  Segher Boessenkool  

PR rtl-optimization/64682
PR rtl-optimization/69567
PR rtl-optimization/69737
* combine.c (distribute_notes) : If the register is set
in I2 as well, just lose it.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/combine.c

[Bug libstdc++/69782] [6 Regression] defining min() macro causes thousand of lines of error messages

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #5)
> That doesn't help for std::numeric_limits::min()

Martin corrected me, (numeric_limits::min)() will work.

[Bug libstdc++/69782] [6 Regression] defining min() macro causes thousand of lines of error messages

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Martin Sebor from comment #4)
> it can be less than trivial.  A fairly easy way to avoid having to deal with
> the problem in libstdc++ is to enclose every call to min and max in public
> libstdc++ headers in parentheses: z = (min)(x, y).

That doesn't help for std::numeric_limits::min()

[Bug driver/69265] Option suggestion provides a wrong hint

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

--- Comment #6 from David Malcolm  ---
Most of this is implemented as of r233382.

The remaining work is to add hints for Joined arguments (see comment #3).  I
have a patch for that, but it seems like more of a stage 1 thing; marking
target milestone as 7.0.

[Bug driver/69453] unrecognized command line option suggestions should take negation into account

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #6 from David Malcolm  ---
Should be fixed as of r233382; marking this one as resolved.

[Bug driver/69453] unrecognized command line option suggestions should take negation into account

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Fri Feb 12 17:39:27 2016
New Revision: 233382

URL: https://gcc.gnu.org/viewcvs?rev=233382&root=gcc&view=rev
Log:
PR driver/69265 and 69453: improved suggestions for various misspelled options

gcc/ChangeLog:
PR driver/69265
PR driver/69453
* gcc.c (driver::driver): Initialize m_option_suggestions.
(driver::~driver): Clean up m_option_suggestions.
(suggest_option): Convert to...
(driver::suggest_option): ...this, and split out into
driver::build_option_suggestions and find_closest_string.
(driver::build_option_suggestions): New function, from
first half of suggest_option.  Special-case
OPT_fsanitize_ and OPT_fsanitize_recover_, making use of
the sanitizer_opts array.  For options of enum types, add the
various enum values to the candidate strings.
(driver::handle_unrecognized_options): Remove "const".
* gcc.h (driver::handle_unrecognized_options): Likewise.
(driver::build_option_suggestions): New decl.
(driver::suggest_option): New decl.
(driver::m_option_suggestions): New field.
* opts-common.c (add_misspelling_candidates): New function.
* opts.c (sanitizer_opts): Remove decl of struct sanitizer_opts_s
and make non-static.
* opts.h (sanitizer_opts): New array decl.
(add_misspelling_candidates): New function decl.
* spellcheck.c (find_closest_string): New function.
* spellcheck.h (find_closest_string): New function decl.

gcc/testsuite/ChangeLog:
PR driver/69265
PR driver/69453
* gcc.dg/spellcheck-options-3.c: New test case.
* gcc.dg/spellcheck-options-4.c: New test case.
* gcc.dg/spellcheck-options-5.c: New test case.
* gcc.dg/spellcheck-options-6.c: New test case.
* gcc.dg/spellcheck-options-7.c: New test case.
* gcc.dg/spellcheck-options-8.c: New test case.
* gcc.dg/spellcheck-options-9.c: New test case.
* gcc.dg/spellcheck-options-10.c: New test case.


Added:
trunk/gcc/testsuite/gcc.dg/spellcheck-options-10.c
trunk/gcc/testsuite/gcc.dg/spellcheck-options-3.c
trunk/gcc/testsuite/gcc.dg/spellcheck-options-4.c
trunk/gcc/testsuite/gcc.dg/spellcheck-options-5.c
trunk/gcc/testsuite/gcc.dg/spellcheck-options-6.c
trunk/gcc/testsuite/gcc.dg/spellcheck-options-7.c
trunk/gcc/testsuite/gcc.dg/spellcheck-options-8.c
trunk/gcc/testsuite/gcc.dg/spellcheck-options-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcc.c
trunk/gcc/gcc.h
trunk/gcc/opts-common.c
trunk/gcc/opts.c
trunk/gcc/opts.h
trunk/gcc/spellcheck.c
trunk/gcc/spellcheck.h
trunk/gcc/testsuite/ChangeLog

[Bug driver/69265] Option suggestion provides a wrong hint

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Fri Feb 12 17:39:27 2016
New Revision: 233382

URL: https://gcc.gnu.org/viewcvs?rev=233382&root=gcc&view=rev
Log:
PR driver/69265 and 69453: improved suggestions for various misspelled options

gcc/ChangeLog:
PR driver/69265
PR driver/69453
* gcc.c (driver::driver): Initialize m_option_suggestions.
(driver::~driver): Clean up m_option_suggestions.
(suggest_option): Convert to...
(driver::suggest_option): ...this, and split out into
driver::build_option_suggestions and find_closest_string.
(driver::build_option_suggestions): New function, from
first half of suggest_option.  Special-case
OPT_fsanitize_ and OPT_fsanitize_recover_, making use of
the sanitizer_opts array.  For options of enum types, add the
various enum values to the candidate strings.
(driver::handle_unrecognized_options): Remove "const".
* gcc.h (driver::handle_unrecognized_options): Likewise.
(driver::build_option_suggestions): New decl.
(driver::suggest_option): New decl.
(driver::m_option_suggestions): New field.
* opts-common.c (add_misspelling_candidates): New function.
* opts.c (sanitizer_opts): Remove decl of struct sanitizer_opts_s
and make non-static.
* opts.h (sanitizer_opts): New array decl.
(add_misspelling_candidates): New function decl.
* spellcheck.c (find_closest_string): New function.
* spellcheck.h (find_closest_string): New function decl.

gcc/testsuite/ChangeLog:
PR driver/69265
PR driver/69453
* gcc.dg/spellcheck-options-3.c: New test case.
* gcc.dg/spellcheck-options-4.c: New test case.
* gcc.dg/spellcheck-options-5.c: New test case.
* gcc.dg/spellcheck-options-6.c: New test case.
* gcc.dg/spellcheck-options-7.c: New test case.
* gcc.dg/spellcheck-options-8.c: New test case.
* gcc.dg/spellcheck-options-9.c: New test case.
* gcc.dg/spellcheck-options-10.c: New test case.


Added:
trunk/gcc/testsuite/gcc.dg/spellcheck-options-10.c
trunk/gcc/testsuite/gcc.dg/spellcheck-options-3.c
trunk/gcc/testsuite/gcc.dg/spellcheck-options-4.c
trunk/gcc/testsuite/gcc.dg/spellcheck-options-5.c
trunk/gcc/testsuite/gcc.dg/spellcheck-options-6.c
trunk/gcc/testsuite/gcc.dg/spellcheck-options-7.c
trunk/gcc/testsuite/gcc.dg/spellcheck-options-8.c
trunk/gcc/testsuite/gcc.dg/spellcheck-options-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcc.c
trunk/gcc/gcc.h
trunk/gcc/opts-common.c
trunk/gcc/opts.c
trunk/gcc/opts.h
trunk/gcc/spellcheck.c
trunk/gcc/spellcheck.h
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org ---
Created attachment 37675
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37675&action=edit
tentative patch

[Bug libstdc++/69782] [6 Regression] defining min() macro causes thousand of lines of error messages

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
FWIW, while C++ doesn't allow programs to define min and max as macros, lots of
C code does it.  When that code happens to be in a header, including that
header in a C++ program causes all kinds of grief.  Sometimes, fixing the
header is easy.  Other times, for instance when the header is a system one, it
can be less than trivial.  A fairly easy way to avoid having to deal with the
problem in libstdc++ is to enclose every call to min and max in public
libstdc++ headers in parentheses: z = (min)(x, y).

[Bug rtl-optimization/69764] [5 Regression] ICE on x86_64-linux-gnu at -O0 (in decompose, at rtl.h:2107)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6 Regression] ICE on |[5 Regression] ICE on
   |x86_64-linux-gnu at -O0 (in |x86_64-linux-gnu at -O0 (in
   |decompose, at rtl.h:2107)   |decompose, at rtl.h:2107)

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

[Bug rtl-optimization/69764] [5/6 Regression] ICE on x86_64-linux-gnu at -O0 (in decompose, at rtl.h:2107)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb 12 16:49:44 2016
New Revision: 233381

URL: https://gcc.gnu.org/viewcvs?rev=233381&root=gcc&view=rev
Log:
PR rtl-optimization/69764
PR rtl-optimization/69771
* optabs.c (expand_binop_directly): For shift_optab_p, force
convert_modes with VOIDmode if xop1 has VOIDmode.

* c-c++-common/pr69764.c: New test.
* gcc.dg/torture/pr69771.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr69764.c
trunk/gcc/testsuite/gcc.dg/torture/pr69771.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/optabs.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/69771] [6 Regression] ICE on x86_64-linux-gnu at -O0 (in extract_insn, at recog.c:2287)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb 12 16:49:44 2016
New Revision: 233381

URL: https://gcc.gnu.org/viewcvs?rev=233381&root=gcc&view=rev
Log:
PR rtl-optimization/69764
PR rtl-optimization/69771
* optabs.c (expand_binop_directly): For shift_optab_p, force
convert_modes with VOIDmode if xop1 has VOIDmode.

* c-c++-common/pr69764.c: New test.
* gcc.dg/torture/pr69771.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr69764.c
trunk/gcc/testsuite/gcc.dg/torture/pr69771.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/optabs.c
trunk/gcc/testsuite/ChangeLog

[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
(In reply to ktkachov from comment #16)
> (In reply to Jakub Jelinek from comment #15)
> > Yeah, my preference is to back out the cse.c one-liner for GCC 6.
> 
> IMO the cse.c patch is the correct fix for the code quality regression seen
> on the gcc.target/arm/wmul-1.c and gcc.target/arm/wmul-2.c tests on arm when
> tuning for -mcpu=cortex-a9, which is a fairly popular arm target.

While it may be a correct fix, IMHO it is not appropriate for this late in the
release cycle.

> The patch didn't have a performance impact on SPEC2000 and SPEC2006 on arm,
> but I did see the adverse code quality effect from gcc.target/arm/wmul-1.c
> and gcc.target/arm/wmul-2.c on a popular embedded benchmark without it.
> 
> So reverting this would cause performance regressions on some normal integer
> code on arm (not using intrinsics).
> 
> How risky at this stage is it to do the define_subst fix for the AVX
> patterns?

It affects lots of patterns in the i?86 backend, just grep for 0C constraints,
especially the subst.md use adds it to most of the vector instructions even
when they don't have it explicitly.  So, it is very risky to change those now.

[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[vries at gcc dot gnu.org]

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

--- Comment #8 from vries at gcc dot gnu.org ---
I managed to trigger the test returning 0 from the command line, by running it
in parallel:
...
$ ( export LD_LIBRARY_PATH=$(pwd -P)/install/lib64; for cnt in $(seq 1 400); do
(./a.out ; echo $? ) > log.$cnt 2>&1 & done )
$ egrep  '^0$' log.* | wc -l
54
...

I can't be sure if that is the reason that the test is failing (by returning 0)
during running the testsuite, but it's certainly possible (I'm running it with
-j12).

So, I suspect that the test fails because pthread_create fails with EAGAIN due
to insufficient resources:
...
int
main ()
{
  pthread_t th;
  barrier_init (&barrier, 2);
  if (pthread_create (&th, NULL, tf, NULL))
return 0;
...

Indeed in the testcase we do not distinguish between:
- return 0, case pthread_create failed, and
- return 0 at end of main, -fsanitize=thread failed to catch the race
condition.

It would probably be good to print an error message when pthread_create fails,
such that when looking at the fail in the testlog, we can easily see that that
is the reason it failed, and not expect it to reproduce otherwise.

[Bug tree-optimization/69714] [5/6 Regression] ffmpeg crc.c test miscompiled

[bernds at gcc dot gnu.org]

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

--- Comment #22 from Bernd Schmidt  ---
Created attachment 37674
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37674&action=edit
Candidate testsuite addition

Here's a reduced version of the testcase. Could you verify that it passes on PA
(after the patch, or with -fno-expensive-optimizations before it)? There are
confusing numbers in the table in main, I've had to change some (but not all)
of them to match the actual output. I double checked with an actual ffmpeg
build.

[Bug c++/69787] class only emitted as declaration in DWARF

[tromey at gcc dot gnu.org]

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

Tom Tromey  changed:

   What|Removed |Added

Version|unknown |5.3.1

--- Comment #1 from Tom Tromey  ---
I forgot to mention: I'm using the system gcc from Fedora 23.

pokyo. g++ --version
g++ (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)

[Bug c++/69787] New: class only emitted as declaration in DWARF

[tromey at gcc dot gnu.org]

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

Bug ID: 69787
   Summary: class only emitted as declaration in DWARF
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37673
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37673&action=edit
reduced test case

This is a debug info issue reduced from a firefox bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1247769

This is similar to bug 12385, but different.


Consider the attached test case.
For this test we want to be able to see the debug info for
"TheOneWeWant".

If I compile the test with -g, I get the debug info:

 <1><52>: Abbrev Number: 6 (DW_TAG_class_type)
<53>   DW_AT_name: (indirect string, offset: 0x79): TheOneWeWant
<57>   DW_AT_byte_size   : 1
<58>   DW_AT_decl_file   : 1
<59>   DW_AT_decl_line   : 27
<5a>   DW_AT_sibling : <0x79>

However, if I compile with "-g -DFAIL", the class is only emitted
as a declaration, causing gdb to ignore it:

 <1><84>: Abbrev Number: 9 (DW_TAG_class_type)
<85>   DW_AT_name: (indirect string, offset: 0x79): TheOneWeWant
<89>   DW_AT_declaration : 1
<89>   DW_AT_sibling : <0xa1>


There doesn't seem to be any notable difference, to me, between the
success and fail cases here.  I think g++ ought to emit full debug info
for this class in both cases.

Also, it would be great if the rules for when debug info for a class
is emitted would be documented.  There are some flags documented
(-femit-class-debug-always and -fno-eliminate-unused-debug-types -- though
note these are separated widely in the info node, which is odd by itself);
and there is some information about other quasi-related things in the
"Vague Linkage" node; and one parenthetical mention in the "#pragma interface"
node.  In the current situation it's unclear to me what I can do in order
to get the debug info here.

[Bug c++/69753] [6 Regression] bogus: expected primary-expression before ‘>’ token

[ppalka at gcc dot gnu.org]

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

--- Comment #5 from Patrick Palka  ---
(In reply to Patrick Palka from comment #4)
> Is this actually bogus?
> 
> [over.call.func] says:
> 
> If the keyword this (9.3.2) is in scope and refers to class T, or a derived
> class of T, then the implied object argument is (*this). If the keyword this
> is not in scope or refers to another class, then a contrived object of type
> T becomes the implied object argument.
> 
> 
> So according to that, "auto guest = A::FromWebContents();" becomes "auto
> guest = this->A::FromWebContents();" right?
> 
> This makes "guest" dependent and so is actually "guest->As ();" is
> invalid.  It has it be "guest->template As ();"

(Sorry, my browser is not displaying textareas properly...)

Last line should say,

  This makes guest dependent and so guest->As() has to be written as
guest->template As();

[Bug c++/69753] [6 Regression] bogus: expected primary-expression before ‘>’ token

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #4 from Patrick Palka  ---
Is this actually bogus?

[over.call.func] says:

If the keyword this (9.3.2) is in scope and refers to class T, or a derived
class of T, then the implied object argument is (*this). If the keyword this is
not in scope or refers to another class, then a contrived object of type
T becomes the implied object argument.


So according to that, "auto guest = A::FromWebContents();" becomes "auto guest
= this->A::FromWebContents();" right?

This makes "guest" dependent and so is actually "guest->As ();" is invalid. 
It has it be "guest->template As ();"

[Bug target/69770] [ARM] -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

[cbaylis at gcc dot gnu.org]

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

--- Comment #2 from cbaylis at gcc dot gnu.org ---
Patch posted to https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00881.html

[Bug middle-end/69786] [6 Regression] FAIL: libgomp.c++/loop-11.C (internal compiler error)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Offending commit got reverted.

[Bug middle-end/69786] New: [6 Regression] FAIL: libgomp.c++/loop-11.C (internal compiler error)

[hjl.tools at gmail dot com]

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

Bug ID: 69786
   Summary: [6 Regression] FAIL: libgomp.c++/loop-11.C (internal
compiler error)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: kuganv at linaro dot org
  Target Milestone: ---

On ia32, r233362 caused:

FAIL: libgomp.c++/loop-11.C (internal compiler error)
FAIL: libgomp.c++/loop-11.C (test for excess errors)
FAIL: libgomp.c++/loop-8.C (internal compiler error)
FAIL: libgomp.c++/loop-8.C (test for excess errors)

../../../../../../gcc/libgomp/testsuite/libgomp.c++/loop-11.C: In function 'int
test1()':^M
../../../../../../gcc/libgomp/testsuite/libgomp.c++/loop-11.C:6:1: error:
excess use operand for stmt^M
1^M
if (1 == 64)^M
../../../../../../gcc/libgomp/testsuite/libgomp.c++/loop-11.C:6:1: internal
compiler error: verify_ssa failed^M
0x12ff4e9 verify_ssa(bool, bool)^M
../../../../gcc/gcc/tree-ssa.c:1039^M
0xf73422 execute_function_todo^M
../../../../gcc/gcc/passes.c:1965^M
0xf7249e do_per_function^M
../../../../gcc/gcc/passes.c:1645^M
0xf735ba execute_todo^M
../../../../gcc/gcc/passes.c:2010^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See  for instructions.^M

[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?

[ktkachov at gcc dot gnu.org]

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

--- Comment #16 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #15)
> Yeah, my preference is to back out the cse.c one-liner for GCC 6.

IMO the cse.c patch is the correct fix for the code quality regression seen on
the gcc.target/arm/wmul-1.c and gcc.target/arm/wmul-2.c tests on arm when
tuning for -mcpu=cortex-a9, which is a fairly popular arm target.

The patch didn't have a performance impact on SPEC2000 and SPEC2006 on arm, but
I did see the adverse code quality effect from gcc.target/arm/wmul-1.c and
gcc.target/arm/wmul-2.c on a popular embedded benchmark without it.

So reverting this would cause performance regressions on some normal integer
code on arm (not using intrinsics).

How risky at this stage is it to do the define_subst fix for the AVX patterns?

[Bug c++/69534] [6 Regression] openjade is miscompiled

[kdudka at redhat dot com]

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

Kamil Dudka  changed:

   What|Removed |Added

 CC||kdudka at redhat dot com

--- Comment #6 from Kamil Dudka  ---
(In reply to rguent...@suse.de from comment #5)
> Can you bisect to a file?

The cause seems to be incorrectly compiled code of the following method:

inline
void *Collector::allocateObject(bool hasFinalizer)
{
  if (freePtr_ == &allObjectsList_)
makeSpace();
  Object *tem = freePtr_;
  freePtr_ = freePtr_->next();
  tem->setColor(currentColor_);
  tem->hasFinalizer_ = hasFinalizer;
  if (hasFinalizer)
tem->moveAfter(&allObjectsList_);
  return tem;
}

If I move the method from Collector.h to Collector.cxx and make it non-inline,
the problem goes away because the value of hasFinalizer is no longer known at
compile time.

Otherwise, from the modules where Collector::allocateObject() is called with
hasFinalizer equal to zero (I inspected the assembler code generated out of
primitive.cxx with/without -fno-tree-dse), the optimizer correctly drops the
code:

  if (hasFinalizer)
tem->moveAfter(&allObjectsList_);

... but at the same time it incorrectly drops also the two assignments above
the condition:

  tem->setColor(currentColor_);
  tem->hasFinalizer_ = hasFinalizer;

Consequently one can see many uses of uninitialized values in valgrind's
output.  If I qualify the 'tem' pointer as volatile in order to suppress the
optimization, the code of openjade starts to work reliably, even if compiled
with default compilation flags, and with completely clean valgrind's output:

--- a/style/Collector.h
+++ b/style/Collector.h
@@ -138,11 +138,11 @@ void Collector::Object::moveAfter(Object *tail)
 inline
 void *Collector::allocateObject(bool hasFinalizer)
 {
   if (freePtr_ == &allObjectsList_)
 makeSpace();
-  Object *tem = freePtr_;
+  Object *volatile tem = freePtr_;
   freePtr_ = freePtr_->next();
   tem->setColor(currentColor_);
   tem->hasFinalizer_ = hasFinalizer;
   if (hasFinalizer)
 tem->moveAfter(&allObjectsList_);

Unless there is some undefined behavior in the code, this looks like a bug in
the optimizer.

[Bug debug/69785] c++filt can't demangle string or compiler produce wrong mangled string

[nikolay.piskun at roguewave dot com]

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

--- Comment #1 from Nikolay Piskun  ---
I can send a test program, but its rather long.

[Bug c++/64611] Using a << operator inside an overloaded << operator gives compile error

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #6 from Patrick Palka  ---
I can't reproduce this issue with gcc 5 or 6.

[Bug middle-end/69715] [4.9 regression] ICE: in store_bit_field_1, at expmed.c:839

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/69579] [4.9 Regression] gcc ICE at -O3 and __sigsetjmp with “tree check: expected ssa_name, have integer_cst in compute_optimized_partition_bases”

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||4.9.3

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

[Bug tree-optimization/69574] [4.9 Regression] gcc ICE at -O2 and -O3 on x86_64-linux-gnu in hide_evolution_in_other_loops_than_loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||4.9.3

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

[Bug tree-optimization/69574] [4.9 Regression] gcc ICE at -O2 and -O3 on x86_64-linux-gnu in hide_evolution_in_other_loops_than_loop

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Fri Feb 12 14:04:29 2016
New Revision: 233378

URL: https://gcc.gnu.org/viewcvs?rev=233378&root=gcc&view=rev
Log:
2016-02-12  Richard Biener  

Backport from mainline
2016-02-09  Richard Biener  

PR tree-optimization/69715
* tree-ssa.c (execute_update_addresses_taken): Mark non-decl
LHS on calls as non-rewritable.

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

2016-02-01  Richard Biener  

PR tree-optimization/69579
* tree-ssa-loop-ivcanon.c (propagate_constants_for_unrolling):
Do not propagate through abnormal PHI results.

* gcc.dg/setjmp-6.c: New testcase.

2016-02-01  Richard Biener  

PR tree-optimization/69574
* tree-chrec.c (hide_evolution_in_other_loops_than_loop): Instead
of asserting return chrec_dont_know.

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

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/setjmp-6.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr69574.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr69715.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-chrec.c
branches/gcc-4_9-branch/gcc/tree-ssa-loop-ivcanon.c
branches/gcc-4_9-branch/gcc/tree-ssa.c

[Bug middle-end/69715] [4.9 regression] ICE: in store_bit_field_1, at expmed.c:839

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Fri Feb 12 14:04:29 2016
New Revision: 233378

URL: https://gcc.gnu.org/viewcvs?rev=233378&root=gcc&view=rev
Log:
2016-02-12  Richard Biener  

Backport from mainline
2016-02-09  Richard Biener  

PR tree-optimization/69715
* tree-ssa.c (execute_update_addresses_taken): Mark non-decl
LHS on calls as non-rewritable.

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

2016-02-01  Richard Biener  

PR tree-optimization/69579
* tree-ssa-loop-ivcanon.c (propagate_constants_for_unrolling):
Do not propagate through abnormal PHI results.

* gcc.dg/setjmp-6.c: New testcase.

2016-02-01  Richard Biener  

PR tree-optimization/69574
* tree-chrec.c (hide_evolution_in_other_loops_than_loop): Instead
of asserting return chrec_dont_know.

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

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/setjmp-6.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr69574.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr69715.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-chrec.c
branches/gcc-4_9-branch/gcc/tree-ssa-loop-ivcanon.c
branches/gcc-4_9-branch/gcc/tree-ssa.c

[Bug tree-optimization/69579] [4.9 Regression] gcc ICE at -O3 and __sigsetjmp with “tree check: expected ssa_name, have integer_cst in compute_optimized_partition_bases”

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Fri Feb 12 14:04:29 2016
New Revision: 233378

URL: https://gcc.gnu.org/viewcvs?rev=233378&root=gcc&view=rev
Log:
2016-02-12  Richard Biener  

Backport from mainline
2016-02-09  Richard Biener  

PR tree-optimization/69715
* tree-ssa.c (execute_update_addresses_taken): Mark non-decl
LHS on calls as non-rewritable.

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

2016-02-01  Richard Biener  

PR tree-optimization/69579
* tree-ssa-loop-ivcanon.c (propagate_constants_for_unrolling):
Do not propagate through abnormal PHI results.

* gcc.dg/setjmp-6.c: New testcase.

2016-02-01  Richard Biener  

PR tree-optimization/69574
* tree-chrec.c (hide_evolution_in_other_loops_than_loop): Instead
of asserting return chrec_dont_know.

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

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/setjmp-6.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr69574.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr69715.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-chrec.c
branches/gcc-4_9-branch/gcc/tree-ssa-loop-ivcanon.c
branches/gcc-4_9-branch/gcc/tree-ssa.c

[Bug debug/69785] New: c++filt can't demangle string or compiler produce wrong mangled string

[nikolay.piskun at roguewave dot com]

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

Bug ID: 69785
   Summary: c++filt can't demangle string or compiler produce
wrong mangled string
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nikolay.piskun at roguewave dot com
  Target Milestone: ---

TotalView debugger emits demangling error, trying to demangle following string:

_ZN9__gnu_cxx13new_allocatorINSt8__detail10_Hash_nodeISt4pairIKiiELb09constructIS6_IRKSt21piecewise_construct_tSt5tupleIIRS4_EESC_IIEvPT_DpOT0_

c++filt can't demangle it either. Looks like the problem is in last "T0_" if
you just substitute it with v, then you get:
c++filt
_ZN9__gnu_cxx13new_allocatorINSt8__detail10_Hash_nodeISt4pairIKiiELb09constructIS6_IRKSt21piecewise_construct_tSt5tupleIIRS4_EESC_IIEvPT_DpOv
void __gnu_cxx::new_allocator, false> >::construct,
false>, std::tuple<>
> >(std::__detail::_Hash_node,
false>, std::tuple<>
>*, (void&&)...)

[Bug tree-optimization/69783] [6 Regression] Loop is not vectorized after r233212

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Ok, I have a local patch in my tree waiting for an excuse to check in that does

t.c:18:8: note: improved number of alias checks from 50 to 2

[Bug tree-optimization/69783] [6 Regression] Loop is not vectorized after r233212

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Created attachment 37672
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37672&action=edit
patch

[Bug tree-optimization/69783] [6 Regression] Loop is not vectorized after r233212

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Similar thing can be observed in PR69732.

[Bug tree-optimization/69783] [6 Regression] Loop is not vectorized after r233212

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-12
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

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

[Bug middle-end/69729] [6 regression] [CHKP] internal compiler error: Segmentation fault

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #6 from Ilya Enkovich  ---
Fixed

[Bug middle-end/69729] [6 regression] [CHKP] internal compiler error: Segmentation fault

[ienkovich at gcc dot gnu.org]

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

--- Comment #5 from Ilya Enkovich  ---
Author: ienkovich
Date: Fri Feb 12 13:17:28 2016
New Revision: 233376

URL: https://gcc.gnu.org/viewcvs?rev=233376&root=gcc&view=rev
Log:
gcc/

PR target/69729
* lto-streamer-out.c (lto_output): Use thunk.add_pointer_bounds_args
to correctly determine instrumentation thunks.

gcc/testsuite/

* g++.dg/lto/lto.exp: Include and init mpx.
* g++.dg/lto/pr69729_0.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr69729_0.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-out.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lto/lto.exp

[Bug c++/54430] [C++11] For-Loop: Scope of iterating variable begins too early

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||oszi at inf dot u-szeged.hu

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

[Bug c++/69784] Range-based for loop can't handle same variable name in range declaration and in range expression

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Already fixed on trunk.

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

[Bug middle-end/69729] [6 regression] [CHKP] internal compiler error: Segmentation fault

[ienkovich at gcc dot gnu.org]

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

--- Comment #4 from Ilya Enkovich  ---
Well, using thunk.add_pointer_bounds_args to determine intrumentation thunks in
this condition works fine for me.  Let's change the condition then.

[Bug c++/69784] Range-based for loop can't handle same variable name in range declaration and in range expression

[oszi at inf dot u-szeged.hu]

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

--- Comment #3 from Csaba Osztrogonác  ---
In WebKit project we had to submitted at least 2 workarounds due to this bug:
- https://bugs.webkit.org/show_bug.cgi?id=151622
- https://bugs.webkit.org/show_bug.cgi?id=154162

( side note: clang builds these sources without error. )

[Bug c++/69784] Range-based for loop can't handle same variable name in range declaration and in range expression

[oszi at inf dot u-szeged.hu]

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

--- Comment #2 from Csaba Osztrogonác  ---
If we explicitly add the type of element, we get a different error:

main.cpp:10:18: error: ‘begin’ was not declared in this scope
 for (int i : i)
  ^
main.cpp:10:18: note: suggested alternatives:
In file included from /usr/include/c++/5/string:51:0,
 from /usr/include/c++/5/bits/locale_classes.h:40,
 from /usr/include/c++/5/bits/ios_base.h:41,
 from /usr/include/c++/5/ios:42,
 from /usr/include/c++/5/ostream:38,
 from /usr/include/c++/5/iostream:39,
 from main.cpp:1:
/usr/include/c++/5/bits/range_access.h:87:5: note:   ‘std::begin’
 begin(_Tp (&__arr)[_Nm])
 ^
/usr/include/c++/5/bits/range_access.h:87:5: note:   ‘std::begin’

[Bug c++/69784] Range-based for loop can't handle same variable name in range declaration and in range expression

[oszi at inf dot u-szeged.hu]

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

Csaba Osztrogonác  changed:

   What|Removed |Added

Summary|Range-based for loop can|Range-based for loop can't
   ||handle same variable name
   ||in range declaration and in
   ||range expression

--- Comment #1 from Csaba Osztrogonác  ---
build log:
main.cpp: In function ‘int main()’:
main.cpp:10:20: error: use of ‘i’ before deduction of ‘auto’
 for (auto& i : i)
^

[Bug c++/69784] New: Range-based for loop can

[oszi at inf dot u-szeged.hu]

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

Bug ID: 69784
   Summary: Range-based for loop can
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oszi at inf dot u-szeged.hu
  Target Milestone: ---

#include 
#include 

using namespace std;

int main()
{
array i = {1,2,3,4,5};

for (auto& i : i)
{
cout << i <

[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.

[hector.oron at gmail dot com]

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

--- Comment #30 from Hector Oron  ---
(In reply to Steve Ellcey from comment #28)
> (In reply to Hector Oron from comment #27)
> > (In reply to Richard Biener from comment #25)
> > > Re-adding GCC 6 as regression, though graphviz is not gsoap.
> > 
> > Right, I initially thought it was the same issue, as it only happens on
> > mips, and both have a workaround of using -fno-ipa-sra.
> 
> Rather than the original patch from comment #13, I would try this follow-up
> mips.c change:
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00250.html
> 
> I think it is better but I am still not sure if it is what we want to do as
> a permanent fix.

That one worked for me. I was able to compile graphviz properly and dot is not
aborting anymore.

[Bug tree-optimization/43434] Missed vectorization: "not vectorized: data ref analysis": pointer incremented by a parameter

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Now that strided SLP is implemented we run into

t.c:10:3: note: versioning for alias required: can't determine dependence
between *s1_82 and MEM[(DCTELEM *)block_81 clique 1 base 1]
t.c:10:3: note: mark for run-time aliasing test between *s1_82 and *block_81
t.c:10:3: note: versioning not yet supported for non-constant step
t.c:10:3: note: bad data dependence.

that's because our restrict support doesn't yet handle this case.  Oops.

With that fixed we get the loop in diff_pixels_c vectorized.

For the loop in pix_sum_c our cost model decides that vectorization is not
profitable:

t.c:39:3: note: Cost model analysis:
  Vector inside of loop cost: 53
  Vector prologue cost: 1
  Vector epilogue cost: 5
  Scalar iteration cost: 48
  Scalar outside cost: 0
  Vector outside cost: 6
  prologue iterations: 0
  epilogue iterations: 0
t.c:39:3: note: cost model: the vector iteration cost = 53 divided by the
scalar iteration cost = 48 is greater or equal to the vectorization factor = 1.

the inner loop is already unrolled before vectorization.

[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug ipa/68672] [4.9/5 Regression] g++.dg/torture/pr68470.C: ICE: cannot update SSA form: statement uses released SSA name

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|hubicka at gcc dot gnu.org |jakub at gcc dot gnu.org
Summary|[4.9/5/6 Regression]|[4.9/5 Regression]
   |g++.dg/torture/pr68470.C:   |g++.dg/torture/pr68470.C:
   |ICE: cannot update SSA  |ICE: cannot update SSA
   |form: statement uses|form: statement uses
   |released SSA name   |released SSA name

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

[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD

[jakub at gcc dot gnu.org]

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

--- Comment #27 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb 12 11:59:00 2016
New Revision: 233375

URL: https://gcc.gnu.org/viewcvs?rev=233375&root=gcc&view=rev
Log:
PR ipa/69241
* ipa-split.c (split_function): If split part returns TREE_ADDRESSABLE
type by reference, force lhs on the call.

* g++.dg/ipa/pr69241-4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ipa/pr69241-4.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-split.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/68672] [4.9/5/6 Regression] g++.dg/torture/pr68470.C: ICE: cannot update SSA form: statement uses released SSA name

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb 12 11:57:54 2016
New Revision: 233374

URL: https://gcc.gnu.org/viewcvs?rev=233374&root=gcc&view=rev
Log:
PR ipa/68672
* ipa-split.c (split_function): Don't compute/use main_part_return_p.
Compute retval and retbnd early in all cases if split_part_return_p
and return_bb is not EXIT.  Remove all clobber stmts and reset
all debug stmts that refer to SSA_NAMEs defined in split part,
except if it is retval, in that case replace the old retval with the
lhs of the call to the split part.

* g++.dg/ipa/pr68672-1.C: New test.
* g++.dg/ipa/pr68672-2.C: New test.
* g++.dg/ipa/pr68672-3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ipa/pr68672-1.C
trunk/gcc/testsuite/g++.dg/ipa/pr68672-2.C
trunk/gcc/testsuite/g++.dg/ipa/pr68672-3.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-split.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/69783] [6 Regression] Loop is not vectorized after r233212

[ysrumyan at gmail dot com]

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

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

It needs to be compiled with -Ofast -funroll-loops on x86-64

[Bug tree-optimization/69783] New: [6 Regression] Loop is not vectorized after r233212

[ysrumyan at gmail dot com]

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

Bug ID: 69783
   Summary: [6 Regression] Loop is not vectorized after r233212
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com
  Target Milestone: ---

After changes in vect_prune_runtime_alias_test_list() a number of merging
ranges was significantly decreased:

  Before fix
improved number of alias checks from 50 to 3
  After fix
improved number of alias checks from 50 to 22
and loop is not vectorized since
number of versioning for alias run-time tests exceeds 10

[Bug c++/69753] [6 Regression] bogus: expected primary-expression before ‘>’ token

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Also seeing this.

[Bug libstdc++/69782] [6 Regression] defining min() macro causes thousand of lines of error messages

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Jonathan Wakely from comment #2)
> I assume clang does it by not having header guards in its __undef_min_max
> file, so that it can be re-included by any header and redo the #undefs.

Let's do the same, no?

> I'm almost tempted to make it #error not #warning, to teach people a lesson
> ;-)

Well, they will get an error if they use -Werror.

[Bug libstdc++/69782] [6 Regression] defining min() macro causes thousand of lines of error messages

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
This is undefined behaviour, really egregious undefined behaviour.

The code compiled before because  includes  which
does
#undef min
#undef max
to remove the silly macro before doing anything else. Now that  include
 those #undefs come too early to help.

I assume clang does it by not having header guards in its __undef_min_max file,
so that it can be re-included by any header and redo the #undefs.

I'm almost tempted to make it #error not #warning, to teach people a lesson ;-)

[Bug libstdc++/69782] [6 Regression] defining min() macro causes thousand of lines of error messages

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
The fix is easy in this case, just #include  after the macro
definition.

luminance-hdr-2.3.0/src/HdrCreation/robertson02.cpp 
From  
 30 #include "arch/math.h"  
 31 #include "arch/minmax.h"
 32 
 33 #include   

To 
 30 #include "arch/minmax.h"
 31 #include "arch/math.h"  
 32 
 33 #include 

[Bug libstdc++/69782] New: [6 Regression] defining min() macro causes thousand of lines of error messages

[trippels at gcc dot gnu.org]

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

Bug ID: 69782
   Summary: [6 Regression] defining min() macro causes thousand of
lines of error messages
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

markus@x4 /tmp % cat minmax.h
#include 
#ifndef min
#define min(a,b)(((a) < (b)) ? (a) : (b))
#endif
#include 

markus@x4 /tmp % g++ -c minmax.h 2>&1 | wc -l
1199

markus@x4 /tmp % clang++ -stdlib=libc++ -c minmax.h
clang-3.9: warning: treating 'c-header' input as 'c++-header' when in C++ mode,
this behavior is deprecated
In file included from minmax.h:5:
In file included from /usr/include/c++/v1/iostream:38:
In file included from /usr/include/c++/v1/ios:216:
In file included from /usr/include/c++/v1/__locale:15:
In file included from /usr/include/c++/v1/string:439:
In file included from /usr/include/c++/v1/algorithm:628:
In file included from /usr/include/c++/v1/memory:605:
In file included from /usr/include/c++/v1/limits:112:
/usr/include/c++/v1/__undef_min_max:16:2: warning: : macro min is incompatible
with C++. #undefing min [-W#warnings]
#warning: macro min is incompatible with C++.  #undefing min
 ^
1 warning generated.

[Bug tree-optimization/69776] [4.9/5/6 Regression] Wrong optimization with aliasing

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.4.7
   Target Milestone|--- |4.9.4
Summary|Wrong optimization with |[4.9/5/6 Regression] Wrong
   |aliasing|optimization with aliasing
  Known to fail||4.5.4, 4.6.4, 4.7.3, 4.8.5,
   ||4.9.3, 5.3.0

[Bug rtl-optimization/69771] [6 Regression] ICE on x86_64-linux-gnu at -O0 (in extract_insn, at recog.c:2287)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Richard Biener  ---
Same underlying issue as PR69764.

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

[Bug rtl-optimization/69764] [5/6 Regression] ICE on x86_64-linux-gnu at -O0 (in decompose, at rtl.h:2107)

[rguenth at gcc dot gnu.org]

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

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

[Bug tree-optimization/69776] Wrong optimization with aliasing

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
extern void *malloc (__SIZE_TYPE__);
extern void abort (void);

void __attribute__((noinline,noclone))
foo (int *pi)
{
  if (*pi != 1)
abort ();
}

int
main()
{
  void *p = malloc(sizeof (double));
  int *pi = p;
  double *pd = p;

  *pi = 1;
  int a = *pi;
  *pd = 0;
  *pi = a;
  foo (pi);

  return 0;
}


FRE removes *pi = a because it stores the same value as *pi = 1 which is
found via

  val = vn_reference_lookup (gimple_assign_lhs (stmt),
 gimple_vuse (stmt), VN_WALK, NULL);

and thus treats the *pi = a store as a load, losing the fact that it
cannot TBAA disambiguate against other stores.