[Bug target/68577] New: [6 Regression] ICE: in expand_direct_optab_fn, at internal-fn.c:2171

[trippels at gcc dot gnu.org]

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

Bug ID: 68577
   Summary: [6 Regression] ICE: in expand_direct_optab_fn, at
internal-fn.c:2171
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu

trippels@gcc2-power8 posix % cat sched_cpucount.i
int a, b;
void __sched_cpucount() {
  while (b) {
long l = b++;
a += __builtin_popcountl(l);
  }
}

trippels@gcc2-power8 posix % gcc -c -O3 sched_cpucount.i
sched_cpucount.i: In function ‘__sched_cpucount’:
sched_cpucount.i:5:10: internal compiler error: in expand_direct_optab_fn, at
internal-fn.c:2171
 a += __builtin_popcountl(l);
  ^~

0x105813d7 expand_direct_optab_fn
../../gcc/gcc/internal-fn.c:2171
0x1058205f expand_internal_call
../../gcc/gcc/internal-fn.c:2314
0x1058205f expand_internal_call(gcall*)
../../gcc/gcc/internal-fn.c:2322
0x10306a17 expand_call_stmt
../../gcc/gcc/cfgexpand.c:2550
0x10306a17 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3525
0x10306a17 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3688
0x10309d93 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5694
0x10310327 execute
../../gcc/gcc/cfgexpand.c:6309

[Bug tree-optimization/68549] [6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1669

[su at cs dot ucdavis.edu]

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

Zhendong Su  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

--- Comment #9 from Zhendong Su  ---
Here is another test case for the same ICE: 

$ 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 20151126 (experimental) [trunk revision 230945] (GCC) 
$ 
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn2’:
small.c:21:1: error: loop 3’s latch is missing
 }
 ^

small.c:21:1: error: loop 5’s latch is missing
small.c:21:1: error: loop 9’s latch is missing
small.c:21:1: internal compiler error: in verify_loop_structure, at
cfgloop.c:1669
0x715d18 verify_loop_structure()
../../gcc-trunk/gcc/cfgloop.c:1669
0x96de4e checking_verify_loop_structure
../../gcc-trunk/gcc/cfgloop.h:325
0x96de4e loop_optimizer_init(unsigned int)
../../gcc-trunk/gcc/loop-init.c:106
0x96df2a rtl_loop_init
../../gcc-trunk/gcc/loop-init.c:398
0x96df2a execute
../../gcc-trunk/gcc/loop-init.c:425
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


--


short a, d, f, h;
int b, c, e, g, i;

unsigned 
fn1 (int p1, int p2)
{
  return p2 > 1 || p1 >> p2 ? p1 : p2;
}

void
fn2 ()
{
  int j;
  g = f;
  while (h)
{
  j = a < 0 || (b = 2) ? a : 2;
  j && (i = fn1 (fn1 (h, e), 3));
  e = c && d;
}
}

[Bug tree-optimization/68549] [6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1669

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #10 from Markus Trippelsdorf  ---
Tom reverted the check in r30967. Closing.

[Bug tree-optimization/68549] [6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1669

[trippels at gcc dot gnu.org]

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

--- Comment #11 from Markus Trippelsdorf  ---
r230967 actually.

[Bug tree-optimization/68553] gcc.dg/vect/pr68445.c FAILs

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 27 08:31:44 2015
New Revision: 230993

URL: https://gcc.gnu.org/viewcvs?rev=230993&root=gcc&view=rev
Log:
2015-11-27  Richard Biener  

PR tree-optimization/68553
* tree-vect-slp.c (vect_get_mask_element): Remove.
(vect_transform_slp_perm_load): Implement in a simpler way.

* gcc.dg/vect/pr45752.c: Adjust.
* gcc.dg/vect/slp-perm-4.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr45752.c
trunk/gcc/testsuite/gcc.dg/vect/slp-perm-4.c
trunk/gcc/tree-vect-slp.c

[Bug c++/68578] New: [5 egression] ICE on invalid template declaration and instantiation

[yury.zaytsev at traveltainment dot de]

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

Bug ID: 68578
   Summary: [5 egression] ICE on invalid template declaration and
instantiation
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yury.zaytsev at traveltainment dot de
  Target Milestone: ---

[Bug target/68577] [6 Regression] ICE: in expand_direct_optab_fn, at internal-fn.c:2171

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c++/68578] [5 Regression] ICE on invalid template declaration and instantiation

[yury.zaytsev at traveltainment dot de]

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

--- Comment #1 from Yury V. Zaytsev  ---
Affected: GCC 5.2.1, unaffected: GCC 4.9.2 and reportedly trunk.

$ cat ice.i
template  struct bar foo; template <> struct foo<>:

$ g++-5 -std=c++14 -w ice.i
ice.i:1:56: internal compiler error: Segmentation fault
 template  struct bar foo; template <> struct foo<>:
^
$ g++-4.9 -std=c++14 -w ice.i 
ice.i:1:32: error: template declaration of 'bar foo'
 template  struct bar foo; template <> struct foo<>:
^
...

$ g++-4.9 --version
g++-4.9 (Ubuntu 4.9.2-0ubuntu1~12.04) 4.9.2

$ g++-5 --version
g++-5 (Ubuntu 5.2.1-23ubuntu1~12.04) 5.2.1 20151031

[Bug c/68573] [4.8/4.9/5/6 Regression] -ftree-vectorizer-verbose= discarded without notice

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
ftree-vectorizer-verbose=
Common Joined RejectNegative Ignore
Does nothing.  Preserved for backward compatibility.


Works as designed.  Use -fopt-info-vec.

[Bug c++/68578] [5 Regression] ICE on invalid template declaration and instantiation

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-27
 CC||trippels at gcc dot gnu.org
  Known to work||4.9.2, 6.0
 Ever confirmed|0   |1
  Known to fail||5.2.1

--- Comment #2 from Markus Trippelsdorf  ---
Confirmed.

[Bug middle-end/68570] [6 Regression] ICE on valid code at -O1, -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-27
 CC||rsandifo at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ICE on valid code at -O1,   |[6 Regression] ICE on valid
   |-O2 and -O3 on  |code at -O1, -O2 and -O3 on
   |x86_64-linux-gnu|x86_64-linux-gnu
 Ever confirmed|0   |1

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

[Bug bootstrap/68563] LTO bootstrap fails on aarch64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-27
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
This was reported on the ML as a valid error.  You should always use
--disable-werror when building with LTO.

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 27 08:59:55 2015
New Revision: 230999

URL: https://gcc.gnu.org/viewcvs?rev=230999&root=gcc&view=rev
Log:
PR c/63326
* c-parser.c (c_parser_compound_statement_nostart): If
last_label is true, use pragma_stmt instead of pragma_compound
as second c_parser_pragma argument.
(c_parser_omp_ordered, c_parser_omp_target_update,
c_parser_omp_target_enter_data, c_parser_omp_target_exit_data): Pass
false as second argument to c_parser_skip_to_pragma_eol after
diagnosing standalone directives used in pragma_stmt context.

* parser.c (cp_parser_statement): Clear in_compound after labels.

* gcc.dg/gomp/barrier-2.c (f2): Expect another error after label.
* c-c++-common/gomp/pr63326.c: New test.

* testsuite/libgomp.c/cancel-parallel-2.c (foo): Add semicolon
in between case label and OpenMP standalone directives.
* testsuite/libgomp.c++/cancel-parallel-2.C (foo): Likewise.

Added:
trunk/gcc/testsuite/c-c++-common/gomp/pr63326.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/gomp/barrier-2.c
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.c++/cancel-parallel-2.C
trunk/libgomp/testsuite/libgomp.c/cancel-parallel-2.c

[Bug lto/68560] [6 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |6.0

[Bug tree-optimization/68552] [5/6 Regression]: ICE in in expand_expr_real_2 with -O2 -ftree-vectorize

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 27 09:01:20 2015
New Revision: 231000

URL: https://gcc.gnu.org/viewcvs?rev=231000&root=gcc&view=rev
Log:
PR tree-optimization/68552
* optabs.c (expand_vec_perm_1): Move vec_shr handling from here...
(expand_vec_perm): ... here.  Do it regardless of vec_perm_const_optab
or whether v0 == v1.

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

[Bug tree-optimization/68552] [5/6 Regression]: ICE in in expand_expr_real_2 with -O2 -ftree-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
  Known to work||5.2.0

[Bug bootstrap/68563] LTO bootstrap fails on aarch64-linux-gnu

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> This was reported on the ML as a valid error.  You should always use
> --disable-werror when building with LTO.

Ok, will do.
In the meantime, should we fix these errors in libdecnumber then since they're
legitimate?

[Bug other/68498] Replace LOOPS_MAY_HAVE_MULTIPLE_LATCHES with LOOPS_HAVE_SINGLE_LATCH

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
See PR68549 and https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02633.html thread
for further information on loop flags. In particular PR68549 comment 6.

[Bug libgomp/68579] New: FAIL: libgomp.c/target-32.c execution test

[vries at gcc dot gnu.org]

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

Bug ID: 68579
   Summary: FAIL: libgomp.c/target-32.c execution test
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Doesn't fail all the time.

By copy-pasting compile and run commands from libgomp.log, and running
target-32.exe in a loop:
...
( LD_LIBRARY_PATH=... ; for i in $(seq 1 1000); do ./target-32.exe; s=$?; if [
$s -ne 0 ]; then echo $s; fi; done )
...

I get:
...
139
139
139
139
139
139
...

So a failure rate of 0.6%.

Used revision: r23099.

Target: x86_64-pc-linux-gnu
Configured with: configure --disable-bootstrap --enable-checking=yes,rtl
--enable-languages=c

[Bug c++/68309] [5/6 Regression] ICE: Segmentation fault

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The ICE (on #c2 with -std=c++1y) started with r211084.
Jason, is this something easily fixable for 5.3?

[Bug sanitizer/67941] [5/6 Regression] calls on function pointer from a captureless lambda cause ubsan warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug libgomp/68579] FAIL: libgomp.c/target-32.c execution test

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-27
 Ever confirmed|0   |1

--- Comment #1 from vries at gcc dot gnu.org ---
confirmed: https://gcc.gnu.org/ml/gcc-regression/2015-11/msg00799.html

[Bug libgomp/68579] FAIL: libgomp.c/target-32.c execution test

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
Backtrace:
...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x76f7a700 (LWP 6717)]
gomp_task_maybe_wait_for_dependencies (depend=depend@entry=0x76f79dd0)
at src/libgomp/task.c:1551
1551  if (next_task->kind == GOMP_TASK_WAITING)
(gdb) bt
#0  gomp_task_maybe_wait_for_dependencies (depend=depend@entry=0x76f79dd0)
at src/libgomp/task.c:1551
#1  0x7794b746 in
  GOMP_target_enter_exit_data (device=, mapnum=3,
   hostaddrs=0x76f79db0, sizes=0x6012e0
   <.omp_data_sizes.35>, kinds=0x6012d0
   <.omp_data_kinds.36>, flags=2,
   depend=0x76f79dd0)
at src/libgomp/target.c:1691
#2  0x00400ca9 in main._omp_fn ()
#3  0x77943cb6 in gomp_thread_start (xdata=)
at src/libgomp/team.c:119
#4  0x777169ca in start_thread () from /lib/libpthread.so.0
#5  0x7747245d in clone () from /lib/libc.so.6
#6  0x in ?? ()
...

This valgrind output suggests that next_task is NULL:
...
==13885== Process terminating with default action of signal 11 (SIGSEGV)
==13885==  Access not within mapped region at address 0x58
==13885==at 0x514E2FD: gomp_task_maybe_wait_for_dependencies (task.c:1551)
...

[Bug libgomp/68579] FAIL: libgomp.c/target-32.c execution test

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
Created attachment 36853
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36853&action=edit
valgrind output

[Bug ipa/68470] [4.9/5/6 Regression] Internal Compiler Error observed by g++-4.9.2 and a few other versions (reported to Debian)

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Ok, so the issue is the non-split part doesn't return but we keep and wire
the original return block (duplicated into the split part) into the
split-return
part of the main function.  That leaves us with stmts that have no defs for
their uses.  The following works for me.

Index: gcc/ipa-split.c
===
--- gcc/ipa-split.c (revision 230998)
+++ gcc/ipa-split.c (working copy)
@@ -1205,7 +1205,6 @@ split_function (basic_block return_bb, s
   edge e;
   edge_iterator ei;
   tree retval = NULL, real_retval = NULL, retbnd = NULL;
-  bool split_part_return_p = false;
   bool with_bounds = chkp_function_instrumented_p (current_function_decl);
   gimple *last_stmt = NULL;
   unsigned int i;
@@ -1246,12 +1245,16 @@ split_function (basic_block return_bb, s
args_to_pass.safe_push (arg);
   }

-  /* See if the split function will return.  */
+  /* See if the split function or the main part will return.  */
+  bool main_part_return_p = false;
+  bool split_part_return_p = false;
   FOR_EACH_EDGE (e, ei, return_bb->preds)
-if (bitmap_bit_p (split_point->split_bbs, e->src->index))
-  break;
-  if (e)
-split_part_return_p = true;
+{
+  if (bitmap_bit_p (split_point->split_bbs, e->src->index))
+   split_part_return_p = true;
+  else
+   main_part_return_p = true;
+}

   /* Add return block to what will become the split function.
  We do not return; no return block is needed.  */
@@ -1295,6 +1298,11 @@ split_function (basic_block return_bb, s
   else
 bitmap_set_bit (split_point->split_bbs, return_bb->index);

+  /* If the main part doesn't return pretend the return block wasn't
+ found for all of the following.  */
+  if (! main_part_return_p)
+return_bb = EXIT_BLOCK_PTR_FOR_FN (cfun);
+
   /* If RETURN_BB has virtual operand PHIs, they must be removed and the
  virtual operand marked for renaming as we change the CFG in a way that
  tree-inline is not able to compensate for.

[Bug c++/68312] [6 Regression] Memory leaks in cilkplus

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Fri Nov 27 09:36:20 2015
New Revision: 231001

URL: https://gcc.gnu.org/viewcvs?rev=231001&root=gcc&view=rev
Log:
Fix memory leak in cilk

PR c++/68312
* c-array-notation.c (fix_builtin_array_notation_fn):
Use release_vec_vec instead of vec::release.
(build_array_notation_expr): Likewise.
(fix_conditional_array_notations_1): Likewise.
(fix_array_notation_expr): Likewise.
(fix_array_notation_call_expr): Likewise.
PR c++/68312
* cp-array-notation.c (expand_sec_reduce_builtin):
Likewise.
(create_array_refs): Replace argument with const reference.
(expand_an_in_modify_expr): Likewise.
(cp_expand_cond_array_notations): Likewise.
(expand_unary_array_notation_exprs): Likewise.
PR c++/68312
* array-notation-common.c (cilkplus_extract_an_triplets):
Release vector of vectors.
* cilk.c (gimplify_cilk_spawn): Free allocated memory.
PR c++/68312
* vec.h (release_vec_vec): New function.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/array-notation-common.c
trunk/gcc/c-family/cilk.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-array-notation.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-array-notation.c
trunk/gcc/vec.h

[Bug c++/68578] [5 Regression] ICE on invalid template declaration and instantiation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.3

[Bug rtl-optimization/68506] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Fri Nov 27 09:49:38 2015
New Revision: 231003

URL: https://gcc.gnu.org/viewcvs?rev=231003&root=gcc&view=rev
Log:
[RTL-ifcvt] PR rtl-optimization/68506: Fix emitting order of insns in
IF-THEN-JOIN case

PR rtl-optimization/68506
* ifcvt.c (noce_try_cmove_arith): Try emitting the else basic block
first if emit_a exists or then_bb modifies 'b'.  Reindent if-else
blocks.

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


Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr68506.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ifcvt.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/68506] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Fixed. Thanks for the testcase

[Bug c++/67625] [4.9/5 Regression] some constexpr expressions rejected as enumerator value

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
Summary|[5 Regression] some |[4.9/5 Regression] some
   |constexpr expressions   |constexpr expressions
   |rejected as enumerator  |rejected as enumerator
   |value   |value

--- Comment #4 from Jakub Jelinek  ---
This regressed with my r207924, and got fixed with r230365 (aka delayed folding
merge).
Jason, any ideas about this?  Of course delayed folding is not backportable.

[Bug middle-end/68570] [6 Regression] ICE on valid code at -O1, -O2 and -O3 on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r229384.

[Bug sanitizer/68580] New: 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

Bug ID: 68580
   Summary: FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

I can't yet reproduce this failure on the command line.

Still, it seems to happen once in a while, for -O2 here:
https://gcc.gnu.org/ml/gcc-regression/2015-08/msg00147.html .

AFAIU, given the dg-shouldfail, the failure actually means that once in a while
the executable succeeds and fails to give the expected warning and runtime
error.

Expected warning (which is combined with return status 66):
...
==
WARNING: ThreadSanitizer: data race (pid=17100)
  Read of size 4 at 0x00601544 by thread T1:
#0 baz3 src/gcc/testsuite/c-c++-common/tsan/pr65400-1.c:46
(pr65400-1.exe+0x00400cbb)
#1 baz5 src/gcc/testsuite/c-c++-common/tsan/pr65400-1.c:61
(pr65400-1.exe+0x00400d71)
#2 tf src/gcc/testsuite/c-c++-common/tsan/pr65400-1.c:68
(pr65400-1.exe+0x00400d97)

  Previous write of size 4 at 0x00601544 by main thread:
#0 main src/gcc/testsuite/c-c++-common/tsan/pr65400-1.c:79
(pr65400-1.exe+0x00400e12)

  Location is global 'v' of size 4 at 0x00601544
(pr65400-1.exe+0x00601544)

  Thread T1 (tid=17102, running) created by main thread at:
#0 pthread_create src/libsanitizer/tsan/tsan_interceptors.cc:876
(libtsan.so.0+0x0002af04)
#1 main src/gcc/testsuite/c-c++-common/tsan/pr65400-1.c:77
(pr65400-1.exe+0x00400dea)

SUMMARY: ThreadSanitizer: data race
src/gcc/testsuite/c-c++-common/tsan/pr65400-1.c:46 in baz3
==
ThreadSanitizer: reported 1 warnings
...

[Bug tree-optimization/68576] scev failed for loop auto parallelize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-27
 CC||spop at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
I think the issue is that with respect to loop 4 the evolution is

_76 = { 1 + _373, + , 1 }_4

but with all the casting we end up with

(set_scalar_evolution
  instantiated_below = 5
  (scalar = _470)
  (scalar_evolution = {(unsigned long) stride.92_29 + (unsigned long)
offset.93_35, +, (unsigned long) stride.92_29}_1))
)

and instantiate_scev for the SCEV above fails.  Likewise for instantiate
below 10, only below 15 succeeds in the end.

[Bug c++/68581] New: ICE in build_conditional_expr_1 upon instantiation of a templated function with Cilk+ directives (valid code)

[yury.zaytsev at traveltainment dot de]

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

Bug ID: 68581
   Summary: ICE in build_conditional_expr_1 upon instantiation of
a templated function with Cilk+ directives (valid
code)
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yury.zaytsev at traveltainment dot de
  Target Milestone: ---

Affected: GCC 4.9.3, GCC 5.2.1.

The ICE only happens with -fcilkplus, without it everything is fine.

$ cat ice.i
#include 

struct x{};

template
void parallel() {
const auto &lambda = [] () {};
true ? lambda() : cilk_spawn lambda();
cilk_sync;
}

int main() {
parallel();
}

$ g++-5 -std=c++11 -fcilkplus ice.i 
ice.i: In instantiation of ‘void parallel() [with  =
x]’:
ice.i:13:17:   required from here
ice.i:8:10: internal compiler error: Segmentation fault
 true ? lambda() : cilk_spawn lambda();
  ^
0xa9aa9f crash_signal
../../src/gcc/toplev.c:383
0x5ec65d build_conditional_expr_1
../../src/gcc/cp/call.c:4739
0x5ed6ec build_conditional_expr(unsigned int, tree_node*, tree_node*,
tree_node*, int)
../../src/gcc/cp/call.c:5148
0x6890e3 build_x_conditional_expr(unsigned int, tree_node*, tree_node*,
tree_node*, int)
../../src/gcc/cp/typeck.c:6109
0x6130ed tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:15416
0x61a6f2 tsubst_expr
../../src/gcc/cp/pt.c:14553
0x619856 tsubst_expr
../../src/gcc/cp/pt.c:13964
0x619fe4 tsubst_expr
../../src/gcc/cp/pt.c:13950
0x61a63c tsubst_expr
../../src/gcc/cp/pt.c:14136
0x6193a7 instantiate_decl(tree_node*, int, bool)
../../src/gcc/cp/pt.c:20583
0x62e08b instantiate_pending_templates(int)
../../src/gcc/cp/pt.c:20700
0x649220 cp_write_global_declarations()
../../src/gcc/cp/decl2.c:4465

$ g++-4.9 -std=c++11 -fcilkplus ice.i 
ice.i: In instantiation of ‘void parallel() [with  =
x]’:
ice.i:13:17:   required from here
ice.i:8:10: internal compiler error: Segmentation fault
 true ? lambda() : cilk_spawn lambda();
  ^

$ g++-5 -std=c++11 ice.i 
ice.i: In function ‘void parallel()’:
ice.i:8:34: error: -fcilkplus must be enabled to use ‘_Cilk_spawn’
 true ? lambda() : cilk_spawn lambda();
  ^

$ g++-4.9 -std=c++11 ice.i
ice.i: In function ‘void parallel()’:
ice.i:8:34: error: -fcilkplus must be enabled to use ‘_Cilk_spawn’
 true ? lambda() : cilk_spawn lambda();
  ^

$ g++-5 --version
g++-5 (Ubuntu 5.2.1-23ubuntu1~14.04.2) 5.2.1 20151031

$ g++-4.9 --version
g++-4.9 (Ubuntu 4.9.3-5ubuntu1~14.04) 4.9.3

[Bug rtl-optimization/68536] LRA ICEs with new arm pattern

[yroux at gcc dot gnu.org]

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

Yvan Roux  changed:

   What|Removed |Added

 CC||yroux at gcc dot gnu.org

--- Comment #4 from Yvan Roux  ---
Hi Kyrill,

I don't manage to reproduce the ICE with the given testcase, the pattern my
build  generates is *mulsidi3adddi_v6 and not *mulsidi3siaddsi_round_v6 (I
compiled with -O2 -mcpu=cortex-a15).

[Bug c++/63693] ICE in resolve_typename_type

[yury.zaytsev at traveltainment dot de]

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

Yury V. Zaytsev  changed:

   What|Removed |Added

 CC||yury.zaytsev@traveltainment
   ||.de

--- Comment #6 from Yury V. Zaytsev  ---
Just stumbled upon this ICE in my code on GCC 5.2.1:

$ cat ice.i
template
void foo(T obj) {
using local_type = decltype(obj)::element_type::other_type
}

Do I understand it correctly that this will only be fixed for GCC 6.x, and not
for GCC 4.x/5.x?

Many thanks!

[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 #1 from vries at gcc dot gnu.org ---
(In reply to vries from comment #0)
> I can't yet reproduce this failure on the command line.

That includes 1 iterations of running the executable, for both -O2 and -O0.

[Bug libgomp/68579] FAIL: libgomp.c/target-32.c execution test

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 36854
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36854&action=edit
gcc6-pr68579.patch

Untested fix.

[Bug c++/67702] [4.9/5/6 Regression] Internal compiler error: Segmentation fault

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
This regressed with r217949.  Jason, any ideas on this?

[Bug rtl-optimization/68536] LRA ICEs with new arm pattern

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Hmm, I can definitely still reproduce based on today's trunk.
I'm using an arm-none-eabi compiler configured with
 --without-isl --with-float=hard --with-cpu=cortex-a15 --with-fpu=neon-vfpv4
--with-float=hard --enable-checking=yes

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

[dvyukov at google dot com]

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

Dmitry Vyukov  changed:

   What|Removed |Added

 CC||dvyukov at google dot com

--- Comment #2 from Dmitry Vyukov  ---
If you change types of:

int v;
int q;
int o;

to 'long long', does it fix the failure?

[Bug c/68582] New: -Wunused-function doesn't warn about unused static __attribute__((noreturn)) functions

[palves at redhat dot com]

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

Bug ID: 68582
   Summary: -Wunused-function doesn't warn about unused static
__attribute__((noreturn)) functions
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: palves at redhat dot com
  Target Milestone: ---

With:

 $ gcc6 -v:
 ...
 GNU C11 (GCC) version 6.0.0 20151117 (experimental) (x86_64-pc-linux-gnu)
 ...

This warns, as expected:

 $ cat not-used.c 
 void abort(void);
 static void foo (void) { abort (); }
 int main () {return 0;}
 $ gcc6 not-used.c -o not-used -Wunused-function 
 not-used.c:2:13: warning: ‘foo’ defined but not used [-Wunused-function]
  static void foo (void) { abort (); }
  ^~~

Adding __attribute__((noreturn)) to foo silences the warning:

 $ cat not-used.c 
 void abort(void);
 static __attribute__((noreturn)) void foo (void) { abort (); }
 int main () {return 0;}
 $ gcc6 not-used.c -o not-used -Wunused-function 
 $

Couldn't find this documented in the manual.

[Bug c/68582] -Wunused-function doesn't warn about unused static __attribute__((noreturn)) functions

[palves at redhat dot com]

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

--- Comment #1 from Pedro Alves  ---
Same thing with gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) [Fedora 20].

[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 #3 from vries at gcc dot gnu.org ---
(In reply to Dmitry Vyukov from comment #2)
> If you change types of:
> 
> int v;
> int q;
> int o;
> 
> to 'long long', does it fix the failure?

As long as I don't have a reliable way to reproduce the failure, I can't answer
that question.

[Bug ada/68564] ada fails to bootstrap on sparc64-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-27
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
You probably need to tweak gcc-interface/Makefile.in (Sparc Linux):

  ifeq ($(strip $(shell $(GCC_FOR_TARGET) $(GNATLIBCFLAGS)
-print-multi-os-directory)),../lib64)
LIBGNAT_TARGET_PAIRS = \
$(LIBGNAT_TARGET_PAIRS_COMMON) $(LIBGNAT_TARGET_PAIRS_64)
  else
LIBGNAT_TARGET_PAIRS = \
$(LIBGNAT_TARGET_PAIRS_COMMON) $(LIBGNAT_TARGET_PAIRS_32)
  endif

to make it pick the right system.ads file.

[Bug tree-optimization/68553] gcc.dg/vect/pr68445.c FAILs

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 27 11:17:51 2015
New Revision: 231006

URL: https://gcc.gnu.org/viewcvs?rev=231006&root=gcc&view=rev
Log:
2015-11-27  Richard Biener  

PR tree-optimization/68553
* tree-vect-slp.c (vect_create_mask_and_perm): Skip VEC_PERM_EXPR
generation for 1:1 permutations.
(vect_transform_slp_perm_load): Detect 1:1 permutations.

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

[Bug tree-optimization/68553] gcc.dg/vect/pr68445.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug bootstrap/68540] 6.0 build process broken on Linux Mint, potential include ordering problem

[mar...@mpa-garching.mpg.de]

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

--- Comment #1 from Martin Reinecke  ---
I should probably add that building the trunk was possible without any problems
on Linux Mint until about two weeks ago. Unfortunately I do not know yet how to
isolate the problematic commit ... will look into "git bisect" and post updates
if I have more information.

[Bug c++/68578] [5 Regression] ICE on invalid template declaration and instantiation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Seems this has regressed with r226657, but couldn't reproduce it after the
corresponding trunk commit on the trunk.

[Bug rtl-optimization/68536] LRA ICEs with new arm pattern

[yroux at gcc dot gnu.org]

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

--- Comment #6 from Yvan Roux  ---
(In reply to ktkachov from comment #5)
> Hmm, I can definitely still reproduce based on today's trunk.
> I'm using an arm-none-eabi compiler configured with
>  --without-isl --with-float=hard --with-cpu=cortex-a15 --with-fpu=neon-vfpv4
> --with-float=hard --enable-checking=yes

Ok, mine is on yesterday's trunk and arm-linux-gnueabihf, but I'll retry from
scratch.

[Bug tree-optimization/68343] FAIL: gcc.dg/graphite/fuse-{1,2}.c scan-tree-dumps

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed|2015-11-13 00:00:00 |2015-11-27
 CC||ktkachov at gcc dot gnu.org

--- Comment #7 from ktkachov at gcc dot gnu.org ---
I'm also seeing these fails on arm with ISL version 0.14

[Bug rtl-optimization/67477] [6 Regression] ICE in cselib_record_set, at cselib.c:2388

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-27
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
Cannot reproduce on trunk any more.

Not sure where it got fixed though.

[Bug middle-end/37150] basic-block vectorization misses some unrolled loops

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
(In reply to Joost VandeVondele from comment #15)
> Created attachment 29738 [details]
> maybe smaller testcase version ?
> 
> Attached is what I think is roughly the smallest kernel of this type that we
> have in the code. I checked this is at least partially vectorized with
> ifort, but not so with gfortran trunk. It is still not such a small
> testcase, I'm afraid.

With BB vectorization enhancement this still doesn't vectorize because the
four remaining stores in the function are not grouped.

The non-reduced testcase has the same issue.

I suppose to much scalarization has happened and we don't consider candidates
that do not end in a vector write to memory.

[Bug rtl-optimization/68250] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 27 12:12:35 2015
New Revision: 231009

URL: https://gcc.gnu.org/viewcvs?rev=231009&root=gcc&view=rev
Log:
PR rtl-optimization/68250
* gcc.c-torture/execute/pr68250.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr68250.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/68250] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 27 12:13:48 2015
New Revision: 231010

URL: https://gcc.gnu.org/viewcvs?rev=231010&root=gcc&view=rev
Log:
PR rtl-optimization/68250
* gcc.c-torture/execute/pr68250.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr68250.c
Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog

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

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
*** Bug 68250 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/68250] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/68583] New: [5/6 Regression] Missed if-conversion

[rguenth at gcc dot gnu.org]

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

Bug ID: 68583
   Summary: [5/6 Regression] Missed if-conversion
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

We don't if-convert

void foo (long *a)
{
  int i;
  for (i = 0; i < 100; i+=2)
{
  if (a[i] == 0)
{
  a[i+1] = 2;
  a[i] = 3;
}
  else
{
  a[i+1] = 3;
  a[i] = 4;
}
}
}

even though both a[i] and a[i+1] are written to unconditionally.  We only
keep a base_master to see if sth is writable but if we'd have separate
read-unconditionally and write-unconditionally flags from the master_dr
we could handle the above just fine.  That would require the master_dr
entry to be associated with two different predicates, one for
reads and writes (for read-or-written-unconditionally) and one for writes
only (for written-unconditionally).

PR56624 suggests this missed if-conversion is a regression which it is
as GCC 4.9 and GCC 5.1.0 happily if-convert it.

[Bug tree-optimization/68583] [5/6 Regression] Missed if-conversion

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-27
 CC||venkataramanan.kumar at amd 
dot co
   ||m
  Known to work||4.9.3, 5.1.0
   Target Milestone|--- |5.3
 Ever confirmed|0   |1
  Known to fail||5.2.0, 6.0

[Bug c/68582] -Wunused-function doesn't warn about unused static __attribute__((noreturn)) functions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-27
 Ever confirmed|0   |1

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

[Bug c/68582] -Wunused-function doesn't warn about unused static __attribute__((noreturn)) functions

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Probably because noreturn uses the volatile bit, TREE_THIS_VOLATILE:

  /* Warn about static fns or vars defined but not used.  */
  if (((warn_unused_function && TREE_CODE (decl) == FUNCTION_DECL)
   || (((warn_unused_variable && ! TREE_READONLY (decl))
|| (warn_unused_const_variable && TREE_READONLY (decl)))
   && TREE_CODE (decl) == VAR_DECL))
  && ! DECL_IN_SYSTEM_HEADER (decl)
...
  /* A volatile variable might be used in some non-obvious way.  */
  && ! TREE_THIS_VOLATILE (decl)

this flag check should be gated on VAR_DECLs.

[Bug bootstrap/64320] Missing config.h during findcomp.cc compilation

[gk at torproject dot org]

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

Georg Koppen  changed:

   What|Removed |Added

 CC||gk at torproject dot org

--- Comment #3 from Georg Koppen  ---
(In reply to Andreas Schwab from comment #2)
> Please try this patch:

This solves the issue for me.

[Bug bootstrap/68563] LTO bootstrap fails on aarch64-linux-gnu

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
LTO bootstrap on aarch64-linux with --disable-werror passes.

[Bug target/68577] [6 Regression] ICE: in expand_direct_optab_fn, at internal-fn.c:2171

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Bet this started with r230475 or so.
The problem is that these builtins are in scalar form always returning int, but
take some argument of wider bitsize.
The vectorizer thinks the target can handle narrowing conversion builtin, and
thus emits:
  vect_l.17_53 = [vec_unpack_lo_expr] vect_vec_iv_.15_49;
  vect_l.17_54 = [vec_unpack_hi_expr] vect_vec_iv_.15_49;
  vect__7.18_55 = POPCOUNT (vect_l.17_53, vect_l.17_54);
where vec_l.17 has V2DImode, and vect__7.18 has V4SImode.
But at least the power8 popcountv2di2 pattern takes a single V2DImode argument
(rather than 2 V2DImode arguments) and returns a V2DImode result, while the
caller expects one that takes two V2DImode arguments and produces 4 results in
V4SImode vector for that.

So, first of all, what do we expect from the backends, shall they implement
these popcount2 expanders for vector modes as returning the result in the
same mode as the single argument (then the vectorizer needs to be told about
that and needs to do the narrowing manually, do e.g. in the above case do
POPCOUNT on each V2DImode argument separately, then combine the two V2DImode
results as for long -> int vectorized conversion.  Or they need to do something
different, but then the question is if it should be called popcountv2di2 if it
actually takes 2 arguments rather than 1, etc.

[Bug target/68214] gcc.dg/cwsc1.c fails on arm-none-eabi

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
How was the compiler configured?
The testcases passes for me with a recent trunk.
Compiling it with a arm-none-eabi compiler with -march=armv4t -mthumb
-mfloat-abi=softfp (for example) gives:
main:
push{r4, lr}
sub sp, sp, #8
mov r3, sp
addsr4, r3, #7
ldr r3, .L5
ldr r3, [r3]
mov ip, r4
bl  .L7
cmp r0, r4
bne .L4
movsr0, #0
add sp, sp, #8
@ sp needed
pop {r4}
pop {r1}
bx  r1
.L4:
bl  abort
.L6:
.align  2
.L5:
.word   .LANCHOR0
.size   main, .-main
.global ptr
.data
.align  2
.set.LANCHOR0,. + 0
.type   ptr, %object
.size   ptr, 4
ptr:
.word   foo
.ident  "GCC: (unknown) 6.0.0 20151127 (experimental)"
.text
.code 16
.align  1
.L7:
bx  r3

[Bug target/68214] gcc.dg/cwsc1.c fails on arm-none-eabi

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-27
 Ever confirmed|0   |1

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Oh, it needs -mcpu=arm7tdmi -mthumb -mfloat-abi=soft -marm.
confirmed

[Bug bootstrap/68540] 6.0 build process broken on Linux Mint, potential include ordering problem

[mar...@mpa-garching.mpg.de]

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

--- Comment #2 from Martin Reinecke  ---
OK, the problematic commit appears to be:

Revision 230759 - Directory Listing
Added Mon Nov 23 14:23:59 2015 UTC (3 days, 23 hours ago) by dje

Correct graphite*.c ISL header file inclusion order.
* system.h: Don't poison calloc and strdup if USES_ISL is defined.
* graphite-dependences.c: Define USES_ISL.  Include ISL header files
after GCC header files and before graphite header files.
* graphite-dependences.c: Same.
* graphite-isl-ast-to-gimple.c: Same.
* graphite-optimize-isl.c: Same.
* graphite-poly.c: Same.
* graphite-scop-detection.c: Same.
* graphite-sese-to-poly.c: Same.
* graphite.c: Same.

[Bug ada/68564] ada fails to bootstrap on sparc64-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #2 from Matthias Klose  ---
Created attachment 36855
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36855&action=edit
patch

proposed patch; check for the multiarch string before checking for the
directory name.

[Bug fortran/68218] ALLOCATE with size given by a module function

[vehre at gcc dot gnu.org]

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

--- Comment #5 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Fri Nov 27 14:08:23 2015
New Revision: 231014

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

2015-11-27  Andre Vehreschild  

PR fortran/68218
* trans-array.c (gfc_array_init_size): Add gfc_evaluate_now() when
array spec in allocate is a function call.

gcc/testsuite/ChangeLog:

2015-11-27  Andre Vehreschild  

PR fortran/68218
* gfortran.dg/allocate_with_arrayspec_1.f90: New test.



Added:
   
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_arrayspec_1.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/68584] New: nested generic lambda with trailing return type cases compiler crash

[Gaetano.Checinski at gmail dot com]

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

Bug ID: 68584
   Summary: nested generic lambda with trailing return type cases
compiler crash
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Gaetano.Checinski at gmail dot com
  Target Milestone: ---

Created attachment 36856
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36856&action=edit
backtrace

the following code causes a crash:

//auto F = [](auto){return 1; };
auto call = [](auto/*int*/) {
  auto F = [](auto){return 1; };
  return [=](auto /*int*/ x) -> decltype( F(x) ) { return F(x);};
};

int main(){
  call(1);
}


It has been tested with g++-5.2 and g++-6.0(20151122).
Might be related to bugID:66135 and bugID:61814

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

[rguenth at gcc dot gnu.org]

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

Bug 68559 Summary: Excessive peeling for gaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68559

   What|Removed |Added

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

[Bug tree-optimization/68559] Excessive peeling for gaps

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/68559] Excessive peeling for gaps

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 27 14:17:28 2015
New Revision: 231015

URL: https://gcc.gnu.org/viewcvs?rev=231015&root=gcc&view=rev
Log:
2015-11-27  Richard Biener  

PR tree-optimization/68559
* tree-vect-data-refs.c (vect_analyze_group_access_1): Move
peeling for gap checks ...
* tree-vect-stmts.c (vectorizable_load): ... here and relax
for SLP.
* tree-vect-loop.c (vect_analyze_loop_2): Re-set
LOOP_VINFO_PEELING_FOR_GAPS before re-trying without SLP.

* gcc.dg/vect/slp-perm-4.c: Adjust again.
* gcc.dg/vect/pr45752.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr45752.c
trunk/gcc/testsuite/gcc.dg/vect/slp-perm-4.c
trunk/gcc/tree-vect-data-refs.c
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-stmts.c

[Bug c++/68584] nested generic lambda with trailing return type cases compiler crash

[Gaetano.Checinski at gmail dot com]

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

--- Comment #1 from Gaetano.Checinski at gmail dot com  ---
clang compiles this examples

[Bug c++/68585] New: [5/6 Regression] c++14 code accepted by 4.9 not accepted by 5 and 6

[doko at gcc dot gnu.org]

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

Bug ID: 68585
   Summary: [5/6 Regression] c++14 code accepted by 4.9 not
accepted by 5 and 6
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

is this code which shouldn't be accepted by 4.9?

$ cat tst.cc
#include 
#include 

struct Pos
{
  unsigned l,c,a;

  //fix g++
// constexpr Pos(unsigned l, unsigned c, unsigned a)
// : l(l), c(c), a(a)
// {}
};

template
constexpr std::array make_grid_position(std::integer_sequence)
{
  return std::array{Pos{Ints / 9, Ints % 9, (Ints / 9) / 3 * 3 +
(Ints % 9) / 3}...};
}

constexpr std::array make_grid_positions()
{
  return make_grid_position(std::make_index_sequence<9*9>{});
}

template
void generate_sudoku(T)
{
  constexpr std::array positions = make_grid_positions(); // fail
}

int main()
{
  constexpr std::array positions = make_grid_positions(); // ok
  generate_sudoku(1);
}

$ g++ -std=gnu++14 tst.cc 
tst.cc: In instantiation of 'void generate_sudoku(T) [with T = int]':
tst.cc:34:20:   required from here
tst.cc:28:66: error: 'std::array{std::__array_traits::_Type{Pos{0u, 0u, 0u}, Pos{0u, 1u, 0u}, Pos{0u, 2u, 0u}, Pos{0u, 3u,
1u}, Pos{0u, 4u, 1u}, Pos{0u, 5u, 1u}, Pos{0u, 6u, 2u}, Pos{0u, 7u, 2u},
Pos{0u, 8u, 2u}, Pos{1u, 0u, 0u}, Pos{1u, 1u, 0u}, Pos{1u, 2u, 0u}, Pos{1u, 3u,
1u}, Pos{1u, 4u, 1u}, Pos{1u, 5u, 1u}, Pos{1u, 6u, 2u}, Pos{1u, 7u, 2u},
Pos{1u, 8u, 2u}, Pos{2u, 0u, 0u}, Pos{2u, 1u, 0u}, Pos{2u, 2u, 0u}, Pos{2u, 3u,
1u}, Pos{2u, 4u, 1u}, Pos{2u, 5u, 1u}, Pos{2u, 6u, 2u}, Pos{2u, 7u, 2u},
Pos{2u, 8u, 2u}, Pos{3u, 0u, 3u}, Pos{3u, 1u, 3u}, Pos{3u, 2u, 3u}, Pos{3u, 3u,
4u}, Pos{3u, 4u, 4u}, Pos{3u, 5u, 4u}, Pos{3u, 6u, 5u}, Pos{3u, 7u, 5u},
Pos{3u, 8u, 5u}, Pos{4u, 0u, 3u}, Pos{4u, 1u, 3u}, Pos{4u, 2u, 3u}, Pos{4u, 3u,
4u}, Pos{4u, 4u, 4u}, Pos{4u, 5u, 4u}, Pos{4u, 6u, 5u}, Pos{4u, 7u, 5u},
Pos{4u, 8u, 5u}, Pos{5u, 0u, 3u}, Pos{5u, 1u, 3u}, Pos{5u, 2u, 3u}, Pos{5u, 3u,
4u}, Pos{5u, 4u, 4u}, Pos{5u, 5u, 4u}, Pos{5u, 6u, 5u}, Pos{5u, 7u, 5u},
Pos{5u, 8u, 5u}, Pos{6u, 0u, 6u}, Pos{6u, 1u, 6u}, Pos{6u, 2u, 6u}, Pos{6u, 3u,
7u}, Pos{6u, 4u, 7u}, Pos{6u, 5u, 7u}, Pos{6u, 6u, 8u}, Pos{6u, 7u, 8u},
Pos{6u, 8u, 8u}, Pos{7u, 0u, 6u}, Pos{7u, 1u, 6u}, Pos{7u, 2u, 6u}, Pos{7u, 3u,
7u}, Pos{7u, 4u, 7u}, Pos{7u, 5u, 7u}, Pos{7u, 6u, 8u}, Pos{7u, 7u, 8u},
Pos{7u, 8u, 8u}, Pos{8u, 0u, 6u}, Pos{8u, 1u, 6u}, Pos{8u, 2u, 6u}, Pos{8u, 3u,
7u}, Pos{8u, 4u, 7u}, Pos{8u, 5u, 7u}, Pos{8u, 6u, 8u}, Pos{8u, 7u, 8u},
Pos{8u, 8u, 8u}}}' is not a constant expression
   constexpr std::array positions = make_grid_positions(); // fail
  ^

[Bug fortran/68218] ALLOCATE with size given by a module function

[vehre at gcc dot gnu.org]

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

--- Comment #6 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Fri Nov 27 14:35:46 2015
New Revision: 231017

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

2015-11-27  Andre Vehreschild  

PR fortran/68218
* trans-array.c (gfc_array_init_size): Add gfc_evaluate_now() when
array spec in allocate is a function call.

gcc/testsuite/ChangeLog:

2015-11-27  Andre Vehreschild  

PR fortran/68218
* gfortran.dg/allocate_with_arrayspec_1.f90: New test.



Added:
   
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/allocate_with_arrayspec_1.f90
Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/trans-array.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/68570] [6 Regression] ICE on valid code at -O1, -O2 and -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
So, we have:
basic block 13, loop depth 1
 pred:   11
_24 = (int) m_23(D);
i_lsm.22_91 = _24;
i_lsm.23_92 = 1;
_43 = _24 <= 0;
_45 = (int) _43;
 succ:   14

basic block 14, loop depth 1
 pred:   19
 13
# prephitmp_42 = PHI 
# i_lsm.22_58 = PHI 
# i_lsm.23_60 = PHI 
if (prephitmp_42 != 0)
  goto ;
else
  goto ;
 succ:   20
 15

and #line 2164 "../../gcc/match.pd is applied, we get:
# prephitmp_42 = PHI 
# i_lsm.22_58 = PHI 
# i_lsm.23_60 = PHI 
if (_24 != 0)
  goto ;
else
  goto ;
 succ:   20
 15

which is wrong IL, as _24 is is used in a bb not dominated by its definition.
Perhaps it is optimized this way because match.pd sees that bb19 is unreachable
or something similar, lots of the conditions are folded into 1 != 0 or 0 != 0.

[Bug other/61233] Demangler crash (GDB PR 16957)

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
Author: trippels
Date: Fri Nov 27 14:48:21 2015
New Revision: 231020

URL: https://gcc.gnu.org/viewcvs?rev=231020&root=gcc&view=rev
Log:
PR other/61321 - demangler crash on casts in template parameters

The fix for bug 59195:

 [C++ demangler handles conversion operator incorrectly]
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59195

unfortunately makes the demangler crash due to infinite recursion, in
case of casts in template parameters.

For example, with:

 template struct A {};
 template  void function_temp(A) {}
 template void function_temp(A);

The 'function_temp' instantiation above mangles to:

  _Z13function_tempIiEv1AIXszcvT_Li999EEE

The demangler parses this as:

typed name
  template
name 'function_temp'
template argument list
  builtin type int
  function type
builtin type void
argument list
  template  (*)
name 'A'
template argument list
  unary operator
operator sizeof
unary operator
  cast
template parameter 0(**)
  literal
builtin type int
name '999'

And after the fix for 59195, due to:

 static void
 d_print_cast (struct d_print_info *dpi, int options,
   const struct demangle_component *dc)
 {
 ...
   /* For a cast operator, we need the template parameters from
  the enclosing template in scope for processing the type.  */
   if (dpi->current_template != NULL)
 {
   dpt.next = dpi->templates;
   dpi->templates = &dpt;
   dpt.template_decl = dpi->current_template;
 }

when printing the template argument list of A (what should be ""), the template parameter 0 (that is, "T_", the '**' above) now
refers to the first parameter of the the template argument list of the
'A' template (the '*' above), exactly what we were already trying to
print.  This leads to infinite recursion, and stack exaustion.  The
template parameter 0 should actually refer to the first parameter of
the 'function_temp' template.

Where it reads "for the cast operator" in the comment in d_print_cast
(above), it's really talking about a conversion operator, like:

  struct A { template  explicit operator U(); };

We don't want to inject the template parameters from the enclosing
template in scope when processing a cast _expression_, only when
handling a conversion operator.

The problem is that DEMANGLE_COMPONENT_CAST is currently ambiguous,
and means _both_ 'conversion operator' and 'cast expression'.

Fix this by adding a new DEMANGLE_COMPONENT_CONVERSION component type,
which does what DEMANGLE_COMPONENT_CAST does today, and making
DEMANGLE_COMPONENT_CAST just simply print its component subtree.

I think we could instead reuse DEMANGLE_COMPONENT_CAST and in
d_print_comp_inner still do:

 @@ -5001,9 +5013,9 @@ d_print_comp_inner (struct d_print_info *dpi, int
options,
d_print_comp (dpi, options, dc->u.s_extended_operator.name);
return;

 case DEMANGLE_COMPONENT_CAST:
   d_append_string (dpi, "operator ");
 - d_print_cast (dpi, options, dc);
 + d_print_conversion (dpi, options, dc);
   return;

leaving the unary cast case below calling d_print_cast, but seems to
me that spliting the component types makes it easier to reason about
the code.

g++'s testsuite actually generates three symbols that crash the
demangler in the same way.  I've added those as tests in the demangler
testsuite as well.

And then this fixes PR other/61233 too, which happens to be a
demangler crash originally reported to GDB, at:
https://sourceware.org/bugzilla/show_bug.cgi?id=16957

Bootstrapped and regtested on x86_64 Fedora 20.

Also ran this through GDB's testsuite.  GDB will require a small
update to use DEMANGLE_COMPONENT_CONVERSION in one place it's using
DEMANGLE_COMPONENT_CAST in its sources.

libiberty/
2015-11-27  Pedro Alves  

PR other/61321
PR other/61233
* demangle.h (enum demangle_component_type)
: New value.
* cp-demangle.c (d_demangle_callback, d_make_comp): Handle
DEMANGLE_COMPONENT_CONVERSION.
(is_ctor_dtor_or_conversion): Handle DEMANGLE_COMPONENT_CONVERSION
instead of DEMANGLE_COMPONENT_CAST.
(d_operator_name): Return a DEMANGLE_COMPONENT_CONVERSION
component if handling a conversion.
(d_count_templates_scopes, d_print_comp_inner): Handle
DEMANGLE_COMPONENT_CONVERSION.
(d_print_comp_inner): Handle DEMANGLE_COMPONENT_CONVERSION instead
of DEMANGLE_COMPONENT_CAST.
(d_print_cast): Rename as ...
(d_print_conversion): ... this.  Adjust comments.
(d_print_cast): Rewrite - simply print the left subcomponent.
* cp-demint.c (cplus_demangle_fill_component): Handle
DEMANGLE_COMPONENT_CONVERSION.

* testsuite/demangle-expected: Add tests.

Modified

[Bug other/59195] C++ demangler handles conversion operator incorrectly

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
Author: trippels
Date: Fri Nov 27 14:48:21 2015
New Revision: 231020

URL: https://gcc.gnu.org/viewcvs?rev=231020&root=gcc&view=rev
Log:
PR other/61321 - demangler crash on casts in template parameters

The fix for bug 59195:

 [C++ demangler handles conversion operator incorrectly]
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59195

unfortunately makes the demangler crash due to infinite recursion, in
case of casts in template parameters.

For example, with:

 template struct A {};
 template  void function_temp(A) {}
 template void function_temp(A);

The 'function_temp' instantiation above mangles to:

  _Z13function_tempIiEv1AIXszcvT_Li999EEE

The demangler parses this as:

typed name
  template
name 'function_temp'
template argument list
  builtin type int
  function type
builtin type void
argument list
  template  (*)
name 'A'
template argument list
  unary operator
operator sizeof
unary operator
  cast
template parameter 0(**)
  literal
builtin type int
name '999'

And after the fix for 59195, due to:

 static void
 d_print_cast (struct d_print_info *dpi, int options,
   const struct demangle_component *dc)
 {
 ...
   /* For a cast operator, we need the template parameters from
  the enclosing template in scope for processing the type.  */
   if (dpi->current_template != NULL)
 {
   dpt.next = dpi->templates;
   dpi->templates = &dpt;
   dpt.template_decl = dpi->current_template;
 }

when printing the template argument list of A (what should be ""), the template parameter 0 (that is, "T_", the '**' above) now
refers to the first parameter of the the template argument list of the
'A' template (the '*' above), exactly what we were already trying to
print.  This leads to infinite recursion, and stack exaustion.  The
template parameter 0 should actually refer to the first parameter of
the 'function_temp' template.

Where it reads "for the cast operator" in the comment in d_print_cast
(above), it's really talking about a conversion operator, like:

  struct A { template  explicit operator U(); };

We don't want to inject the template parameters from the enclosing
template in scope when processing a cast _expression_, only when
handling a conversion operator.

The problem is that DEMANGLE_COMPONENT_CAST is currently ambiguous,
and means _both_ 'conversion operator' and 'cast expression'.

Fix this by adding a new DEMANGLE_COMPONENT_CONVERSION component type,
which does what DEMANGLE_COMPONENT_CAST does today, and making
DEMANGLE_COMPONENT_CAST just simply print its component subtree.

I think we could instead reuse DEMANGLE_COMPONENT_CAST and in
d_print_comp_inner still do:

 @@ -5001,9 +5013,9 @@ d_print_comp_inner (struct d_print_info *dpi, int
options,
d_print_comp (dpi, options, dc->u.s_extended_operator.name);
return;

 case DEMANGLE_COMPONENT_CAST:
   d_append_string (dpi, "operator ");
 - d_print_cast (dpi, options, dc);
 + d_print_conversion (dpi, options, dc);
   return;

leaving the unary cast case below calling d_print_cast, but seems to
me that spliting the component types makes it easier to reason about
the code.

g++'s testsuite actually generates three symbols that crash the
demangler in the same way.  I've added those as tests in the demangler
testsuite as well.

And then this fixes PR other/61233 too, which happens to be a
demangler crash originally reported to GDB, at:
https://sourceware.org/bugzilla/show_bug.cgi?id=16957

Bootstrapped and regtested on x86_64 Fedora 20.

Also ran this through GDB's testsuite.  GDB will require a small
update to use DEMANGLE_COMPONENT_CONVERSION in one place it's using
DEMANGLE_COMPONENT_CAST in its sources.

libiberty/
2015-11-27  Pedro Alves  

PR other/61321
PR other/61233
* demangle.h (enum demangle_component_type)
: New value.
* cp-demangle.c (d_demangle_callback, d_make_comp): Handle
DEMANGLE_COMPONENT_CONVERSION.
(is_ctor_dtor_or_conversion): Handle DEMANGLE_COMPONENT_CONVERSION
instead of DEMANGLE_COMPONENT_CAST.
(d_operator_name): Return a DEMANGLE_COMPONENT_CONVERSION
component if handling a conversion.
(d_count_templates_scopes, d_print_comp_inner): Handle
DEMANGLE_COMPONENT_CONVERSION.
(d_print_comp_inner): Handle DEMANGLE_COMPONENT_CONVERSION instead
of DEMANGLE_COMPONENT_CAST.
(d_print_cast): Rename as ...
(d_print_conversion): ... this.  Adjust comments.
(d_print_cast): Rewrite - simply print the left subcomponent.
* cp-demint.c (cplus_demangle_fill_component): Handle
DEMANGLE_COMPONENT_CONVERSION.

* testsuite/demangle-expected: Add tests.

Modified

[Bug other/61321] demangler crash on casts in template parameters

[trippels at gcc dot gnu.org]

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

--- Comment #16 from Markus Trippelsdorf  ---
Author: trippels
Date: Fri Nov 27 14:48:21 2015
New Revision: 231020

URL: https://gcc.gnu.org/viewcvs?rev=231020&root=gcc&view=rev
Log:
PR other/61321 - demangler crash on casts in template parameters

The fix for bug 59195:

 [C++ demangler handles conversion operator incorrectly]
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59195

unfortunately makes the demangler crash due to infinite recursion, in
case of casts in template parameters.

For example, with:

 template struct A {};
 template  void function_temp(A) {}
 template void function_temp(A);

The 'function_temp' instantiation above mangles to:

  _Z13function_tempIiEv1AIXszcvT_Li999EEE

The demangler parses this as:

typed name
  template
name 'function_temp'
template argument list
  builtin type int
  function type
builtin type void
argument list
  template  (*)
name 'A'
template argument list
  unary operator
operator sizeof
unary operator
  cast
template parameter 0(**)
  literal
builtin type int
name '999'

And after the fix for 59195, due to:

 static void
 d_print_cast (struct d_print_info *dpi, int options,
   const struct demangle_component *dc)
 {
 ...
   /* For a cast operator, we need the template parameters from
  the enclosing template in scope for processing the type.  */
   if (dpi->current_template != NULL)
 {
   dpt.next = dpi->templates;
   dpi->templates = &dpt;
   dpt.template_decl = dpi->current_template;
 }

when printing the template argument list of A (what should be ""), the template parameter 0 (that is, "T_", the '**' above) now
refers to the first parameter of the the template argument list of the
'A' template (the '*' above), exactly what we were already trying to
print.  This leads to infinite recursion, and stack exaustion.  The
template parameter 0 should actually refer to the first parameter of
the 'function_temp' template.

Where it reads "for the cast operator" in the comment in d_print_cast
(above), it's really talking about a conversion operator, like:

  struct A { template  explicit operator U(); };

We don't want to inject the template parameters from the enclosing
template in scope when processing a cast _expression_, only when
handling a conversion operator.

The problem is that DEMANGLE_COMPONENT_CAST is currently ambiguous,
and means _both_ 'conversion operator' and 'cast expression'.

Fix this by adding a new DEMANGLE_COMPONENT_CONVERSION component type,
which does what DEMANGLE_COMPONENT_CAST does today, and making
DEMANGLE_COMPONENT_CAST just simply print its component subtree.

I think we could instead reuse DEMANGLE_COMPONENT_CAST and in
d_print_comp_inner still do:

 @@ -5001,9 +5013,9 @@ d_print_comp_inner (struct d_print_info *dpi, int
options,
d_print_comp (dpi, options, dc->u.s_extended_operator.name);
return;

 case DEMANGLE_COMPONENT_CAST:
   d_append_string (dpi, "operator ");
 - d_print_cast (dpi, options, dc);
 + d_print_conversion (dpi, options, dc);
   return;

leaving the unary cast case below calling d_print_cast, but seems to
me that spliting the component types makes it easier to reason about
the code.

g++'s testsuite actually generates three symbols that crash the
demangler in the same way.  I've added those as tests in the demangler
testsuite as well.

And then this fixes PR other/61233 too, which happens to be a
demangler crash originally reported to GDB, at:
https://sourceware.org/bugzilla/show_bug.cgi?id=16957

Bootstrapped and regtested on x86_64 Fedora 20.

Also ran this through GDB's testsuite.  GDB will require a small
update to use DEMANGLE_COMPONENT_CONVERSION in one place it's using
DEMANGLE_COMPONENT_CAST in its sources.

libiberty/
2015-11-27  Pedro Alves  

PR other/61321
PR other/61233
* demangle.h (enum demangle_component_type)
: New value.
* cp-demangle.c (d_demangle_callback, d_make_comp): Handle
DEMANGLE_COMPONENT_CONVERSION.
(is_ctor_dtor_or_conversion): Handle DEMANGLE_COMPONENT_CONVERSION
instead of DEMANGLE_COMPONENT_CAST.
(d_operator_name): Return a DEMANGLE_COMPONENT_CONVERSION
component if handling a conversion.
(d_count_templates_scopes, d_print_comp_inner): Handle
DEMANGLE_COMPONENT_CONVERSION.
(d_print_comp_inner): Handle DEMANGLE_COMPONENT_CONVERSION instead
of DEMANGLE_COMPONENT_CAST.
(d_print_cast): Rename as ...
(d_print_conversion): ... this.  Adjust comments.
(d_print_cast): Rewrite - simply print the left subcomponent.
* cp-demint.c (cplus_demangle_fill_component): Handle
DEMANGLE_COMPONENT_CONVERSION.

* testsuite/demangle-expected: Add tests.

Modifie

[Bug c++/68312] [6 Regression] Memory leaks in cilkplus

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed in trunk.

[Bug other/61233] Demangler crash (GDB PR 16957)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #4 from Markus Trippelsdorf  ---
fixed.

[Bug c++/68586] New: [6 Regression] Enum template parameter wrongly rejected

[reichelt at gcc dot gnu.org]

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

Bug ID: 68586
   Summary: [6 Regression] Enum template parameter wrongly
rejected
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid code snippet is wrongly rejected on trunk (6.0.0 20151122):


enum E { x = 1, y = x << 1 };

template struct A {};

A a;


bug.cc:5:4: error: invalid conversion from 'int' to 'E' [-fpermissive]
 A a;
^

During reduction from a larger testcase I had to tweak the settings
of the garbage collector (--param ggc-min-expand=0) to make it appear reliably.

[Bug other/61321] demangler crash on casts in template parameters

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #17 from Markus Trippelsdorf  ---
fixed.

[Bug c++/68427] GCC (G++) flunks legal ANSI-C code

[wam at hiwaay dot net]

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

--- Comment #6 from wam at hiwaay dot net ---
I see this is labelled as resolved. That is *NOT* true for me. All versions of
gcc on FreeBSD 9.3R that I have tried (4.8.5, 4.9.4, 5.2.0, 5.2.1) still
reproduce this bug as of today. I pkg-upgraded all versions last evening &
tried them this A.M. The header files are where they are supposed to be (&
where intel's ICC is able to find them), etc. Intel's ICC is able to compile
this stuff cleanly nightly under FC14 64-bit across my LAN, no problems. I am
stuck under FreeBSD until this gets fixed :-( 

[Bug bootstrap/68540] 6.0 build process broken on Linux Mint, potential include ordering problem

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-27
 CC||reichelt at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Volker Reichelt  ---
I have the same problem on an OpenSUSE 13.1 distribution.

[Bug sanitizer/68587] New: [6 Regression][UBSAN] ICE in expand_insn, at optabs.c:6974

[burnus at gcc dot gnu.org]

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

Bug ID: 68587
   Summary: [6 Regression][UBSAN] ICE in expand_insn, at
optabs.c:6974
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36857
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36857&action=edit
test.ii, compile with: g++ -Ofast -fsanitize=undefined

Very recently, GCC 6 compiled the big program - since today it fails with an
ICE.

Compile the reduced program with:
  g++ -Ofast -fsanitize=undefined -S test.ii


It fails here with:

test27.ii: In member function ‘int MSMeasurement::compareWithGrid(const
MSMeasurement&, const ECoordinate&, const ECoordinate&) const’:
test27.ii:128:28: internal compiler error: in expand_insn, at optabs.c:6974
 double fa=floor(a/g);
^

0xc2c143 expand_insn(insn_code, unsigned int, expand_operand*)
../../gcc/optabs.c:6974
0xb026a4 expand_direct_optab_fn
../../gcc/internal-fn.c:2147
0x91c69a expand_call_stmt
../../gcc/cfgexpand.c:2565
0x91c69a expand_gimple_stmt_1
../../gcc/cfgexpand.c:3525
0x91c69a expand_gimple_stmt
../../gcc/cfgexpand.c:3688
0x91f25a expand_gimple_basic_block
../../gcc/cfgexpand.c:5694
0x924b46 execute
../../gcc/cfgexpand.c:6309

[Bug sanitizer/68587] [6 Regression][UBSAN] ICE in expand_insn, at optabs.c:6974

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Target||x86_64-pc-linux-gnu
   Target Milestone|--- |6.0

[Bug c++/68588] New: GCC requires constexpr for template non-type parameter, even though constexpr conversion operator exists

[petr at kalinin dot nnov.ru]

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

Bug ID: 68588
   Summary: GCC requires constexpr for template non-type
parameter, even though constexpr conversion operator
exists
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petr at kalinin dot nnov.ru
  Target Milestone: ---

Consider the following code:

struct A {
constexpr operator int() { return 42; }
};

template 
void foo() {}

void bar(A a) {
foo();
}

int main() {
foo();

const int i = 42;
foo();  // (1)

A a{};

static_assert(i == a, "");
bar(a);
foo();  // error here
}

Clang 3.7 with c++14 accepts this, while gcc 5.2.0 with c++14 (by "g++
--std=c++14 b.cpp -o b") does not, producing the following message:

b.cpp: In function ‘int main()’:
b.cpp:22:9: error: the value of ‘a’ is not usable in a constant expression
 foo();  // error here
 ^
b.cpp:18:7: note: ‘a’ was not declared ‘constexpr’
 A a{};
   ^

This behavior of GCC seems at at least strange, as it allows "a" in
static_assert, as well in bar(), but not directly in foo. Moreover,
A::operator int() is declared constexpr and does not evaluate any class
members, therefore use of "a" should be converted constant expression.


This is from my question
http://stackoverflow.com/questions/33957274/type-conversion-at-template-non-type-argument-without-constexpr/33958291.
The last sentence here is reworded from Serge Ballesta's answer there.

[Bug target/68214] gcc.dg/cwsc1.c fails on arm-none-eabi

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
  Known to fail||6.0

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Mine.

[Bug c++/68588] GCC requires constexpr for template non-type parameter, even though constexpr conversion operator exists

[petr at kalinin dot nnov.ru]

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

--- Comment #1 from pkalinin  ---
[Attribution was incorrect, the last sentence is reworded from Columbo's
answer. Sorry.]

[Bug sanitizer/68587] [6 Regression][UBSAN] ICE in expand_insn, at optabs.c:6974

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
The options can be reduced to:
   g++ -O1 -ffast-math -fsanitize=null

[Bug sanitizer/68587] [6 Regression][UBSAN] ICE in expand_insn, at optabs.c:6974

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
has nothing to do with sanitizer. dup.

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

[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

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

[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0

[iains at gcc dot gnu.org]

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

--- Comment #33 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #32)
> reduced testcase:

..however this is not "our" bug, so there's no known reason to keep this PR
open, right?

.. if no-one objects by Monday 30th, then let's close it.

[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0

[mrs at gcc dot gnu.org]

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

--- Comment #34 from mrs at gcc dot gnu.org  ---
So, for bugs that aren't fixed, sometimes we work around them.  We can use this
bug to track things like the vendor bug status (fixed or not), and potential
workarounds.  Plus, we can list this bug in the documentation for _why_ the
compiler doesn't work.

[Bug c++/61039] Using a constexpr's address as a template variable produces an unnecessary warning

[Torsten at Robitzki dot de]

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

Torsten Robitzki  changed:

   What|Removed |Added

 CC||Torsten at Robitzki dot de

--- Comment #1 from Torsten Robitzki  ---
I see the same issue already with 4.8.4.

[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

[burnus at gcc dot gnu.org]

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

--- Comment #13 from Tobias Burnus  ---
(In reply to rsand...@gcc.gnu.org from comment #10)
> Series finally posted here:
>   https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03020.html

Part 05's gcc/genattrtab.c changes do not apply. (All other parts and the
chunks for other files in Part 05 do with some line-offset fuzzy.)

That's a bit surprising as git lists r229184 of 2015-10-22 as latest change for
that file while the patch set was posted on 2015-11-25. - Six of the
gcc/genattrtab.c chunks do not apply and none of them looks trivial.


For instance, the patch changes:
@@ -4770,6 +4804,7 @@ gen_insn_reserv (md_rtx_info *info)
   memset (&attr, 0, sizeof (attr));
   attr.name = DEF_ATTR_STRING (XSTR (def, 0));
   attr.loc = info->loc;
+  attr.type = AT_INSN;

   decl->name= DEF_ATTR_STRING (XSTR (def, 0));
   decl->default_latency = XINT (def, 1);


But in the trunk, I only see:
  4753  gen_insn_reserv (md_rtx_info *info)
  4754  {
  4755struct insn_reserv *decl = oballoc (struct insn_reserv);
  4756rtx def = info->def;
  4757
  4758decl->name= DEF_ATTR_STRING (XSTR (def, 0));
  4759decl->default_latency = XINT (def, 1);

[Bug bootstrap/68540] 6.0 build process broken on Linux Mint, potential include ordering problem

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||alalaw01 at gcc dot gnu.org,
   ||dje at gcc dot gnu.org,
   ||spop at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org

--- Comment #4 from Thomas Schwinge  ---
See also
.
 Unfortunately, one has to revert a number of patches before being able to
revert r230759.

[Bug tree-optimization/68501] [6 Regression] sqrt builtin is not used anymore

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 36858
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36858&action=edit
gcc6-pr68501.patch

Untested fix.  The problem is that the vector SQRT is now an internal call, and
in that case targetm.builtin_reciprocal is not called at all.