[Bug libgomp/68403] FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/loop-auto-1.c (internal compiler error)

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
Verified that the powerpc64le failures are gone as well.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Mon, 30 Nov 2015, rdiezmail-gcc at yahoo dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606
> 
> --- Comment #2 from R. Diez  ---
> A setting like LIBSTDCXX_EMERGENCY_EH_POOL_SIZE sounds good. However, an
> environment variable will not help me, it has to be a configuration option 
> when
> building the toolchain. I am writing embedded firmware with newlib, and, as 
> far
> as I know, there are no environment variables on start-up. You can set them in
> main() with setenv(), but that's too late, the emergency pool has already been
> initialised by then.
> 
> I would also like to specify a size of 0 to disable it completely. I need to
> save as much memory as I can. After all, even if the emergency pool is huge, 
> it
> can still  happen that it is not enough, so the exception-handling code must
> already deal with that case that the pool has no room left, maybe with 
> panic().
> In my case, if there is no malloc() space available to throw an exception, the
> system is not working properly anyway.

Yeah, but the whole issue is for being able to throw std::bad_alloc when
no memory is available...

> By the way, setting the size of some global emergency pool on start-up seems
> like a hack. You do not really know how big it should be, that depends for
> example on the number of threads you have, which is not known upfront.
> Reserving space per thread can help, but that's then a big waste if you have
> many threads. I suggest a special case in the unwind logic that can throw a
> particular out-of-memory exception like std::bad_alloc without allocating
> memory with malloc().

Unfortunately with C++11 and std::exception_ptr this became unmanagable.

> Whatever happened to the sensible way of allocating the exception on the 
> stack and copying it up the stack every time the stack unwinds? I don't 
> think that optimising the performance of the error-handling case is a 
> high priority, at least for most applications. At least for embedded 
> applications, allocating with malloc() when you throw is far worse. That 
> prevents, for example, throwing in interrupt context, where malloc() is 
> often not available.

See above - with std::exception_ptr you can throw an EH in thread1,
catch it and re-throw it from thread2...

Of course at some point you have to say "oh well.." but the standard
seems to not allow that.  Like marking certain exceptions
"non-addressable".

[Bug tree-optimization/68379] [6 Regression] BB vectorization: definition in block 13 follows the use for SSA_NAME

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
At least the PR68614 testcase started to ICE with r230020.

[Bug tree-optimization/68379] [6 Regression] BB vectorization: definition in block 13 follows the use for SSA_NAME

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Mine anyway.

[Bug gcov-profile/68603] FAIL: g++.dg/gcov/gcov-1.C

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||uweigand at gcc dot gnu.org

--- Comment #1 from Dominique d'Humieres  ---
Appeared between revisions r230978 (PASS) and r230984 (FAIL), see
https://gcc.gnu.org/ml/gcc-regression/2015-11/msg00817.html, likely r230979.

[Bug c++/68116] [6 Regression] ice in add_expr, at tree.c:7840

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
This seems to have gone with r230365 aka C++ delayed folding.
Shall we just add the testcase and close?

[Bug gcov-profile/68603] [6 Regression] FAIL: g++.dg/gcov/gcov-1.C

[arnez at linux dot vnet.ibm.com]

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

--- Comment #2 from Andreas Arnez  ---
Right, the regression is caused by r230979 -- sorry about that.  I've posted a
suggested fix:
  https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03502.html

[Bug tree-optimization/67921] [6 Regression] "internal compiler error: in build_polynomial_chrec, at tree-chrec.h:147" when using -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to bin.cheng from comment #7)
> Hmm, this issue could be simply because chrec_fold_multiply doesn't use
> sizetype as CHREC_RIGHT's type to build pointer type CHREC:
> 
> return build_polynomial_chrec
>   (CHREC_VARIABLE (op0),
>chrec_fold_multiply (type, CHREC_LEFT (op0), op1),
>chrec_fold_multiply (type, CHREC_RIGHT (op0), op1));
> 
> It should be fixed by using sizetype for pointer type CHREC node:
> 
> return build_polynomial_chrec
>   (CHREC_VARIABLE (op0),
>chrec_fold_multiply (type, CHREC_LEFT (op0), op1),
>chrec_fold_multiply (POINTER_TYPE_P (type) ? sizetype : type,
> CHREC_RIGHT (op0), op1));
> 
> I will test a patch.

Have you managed to test that change?

[Bug rtl-optimization/67778] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2297

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Started with r229685.  But as it is likely a RTL issue, most likely it has been
latent before.

[Bug tree-optimization/46032] openmp inhibits loop vectorization

[vries at gcc dot gnu.org]

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

--- Comment #23 from vries at gcc dot gnu.org ---
Author: vries
Date: Mon Nov 30 16:34:26 2015
New Revision: 231076

URL: https://gcc.gnu.org/viewcvs?rev=231076=gcc=rev
Log:
Handle BUILT_IN_GOMP_PARALLEL in ipa-pta

2015-11-30  Tom de Vries  

PR tree-optimization/46032
* tree-ssa-structalias.c (find_func_aliases_for_call_arg): New
function,
factored out of ...
(find_func_aliases_for_call): ... here.
(find_func_aliases_for_builtin_call, find_func_clobbers): Handle
BUILT_IN_GOMP_PARALLEL.
(ipa_pta_execute): Same.  Handle node->parallelized_function as a local
function.

* gcc.dg/pr46032.c: New test.

* testsuite/libgomp.c/pr46032.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr46032.c
trunk/libgomp/testsuite/libgomp.c/pr46032.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c
trunk/libgomp/ChangeLog

[Bug tree-optimization/68021] [6 Regression] ice in rewrite_use_nonlinear_expr with -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Even the #c4 testcase started to ICE with r228599 though.

[Bug tree-optimization/46032] openmp inhibits loop vectorization

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org

--- Comment #24 from vries at gcc dot gnu.org ---
patch with testcase committed, marking resolved-fixed.

[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly

[cbaylis at gcc dot gnu.org]

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

--- Comment #14 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Mon Nov 30 17:11:16 2015
New Revision: 231077

URL: https://gcc.gnu.org/viewcvs?rev=231077=gcc=rev
Log:
gcc/testsuite/ChangeLog:

2015-11-30  Charles Baylis  

PR target/63870
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_f16_indices_1.c
(f_vld2_lane_f16): Remove xfails for arm targets.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_f32_indices_1.c
(f_vld2_lane_f32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_f64_indices_1.c
(f_vld2_lane_f64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_p8_indices_1.c
(f_vld2_lane_p8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s16_indices_1.c
(f_vld2_lane_s16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s32_indices_1.c
(f_vld2_lane_s32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s64_indices_1.c
(f_vld2_lane_s64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s8_indices_1.c
(f_vld2_lane_s8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u16_indices_1.c
(f_vld2_lane_u16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u32_indices_1.c
(f_vld2_lane_u32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u64_indices_1.c
(f_vld2_lane_u64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u8_indices_1.c
(f_vld2_lane_u8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_f16_indices_1.c
(f_vld2q_lane_f16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_f32_indices_1.c
(f_vld2q_lane_f32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_f64_indices_1.c
(f_vld2q_lane_f64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_p8_indices_1.c
(f_vld2q_lane_p8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s16_indices_1.c
(f_vld2q_lane_s16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s32_indices_1.c
(f_vld2q_lane_s32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s64_indices_1.c
(f_vld2q_lane_s64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s8_indices_1.c
(f_vld2q_lane_s8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u16_indices_1.c
(f_vld2q_lane_u16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u32_indices_1.c
(f_vld2q_lane_u32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u64_indices_1.c
(f_vld2q_lane_u64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u8_indices_1.c
(f_vld2q_lane_u8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_f16_indices_1.c
(f_vld3_lane_f16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_f32_indices_1.c
(f_vld3_lane_f32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_f64_indices_1.c
(f_vld3_lane_f64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_p8_indices_1.c
(f_vld3_lane_p8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s16_indices_1.c
(f_vld3_lane_s16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s32_indices_1.c
(f_vld3_lane_s32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s64_indices_1.c
(f_vld3_lane_s64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s8_indices_1.c
(f_vld3_lane_s8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_u16_indices_1.c
(f_vld3_lane_u16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_u32_indices_1.c
(f_vld3_lane_u32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_u64_indices_1.c
(f_vld3_lane_u64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_u8_indices_1.c
(f_vld3_lane_u8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_f16_indices_1.c
(f_vld3q_lane_f16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_f32_indices_1.c
(f_vld3q_lane_f32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_f64_indices_1.c
(f_vld3q_lane_f64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_p8_indices_1.c
(f_vld3q_lane_p8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_s16_indices_1.c
(f_vld3q_lane_s16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_s32_indices_1.c
(f_vld3q_lane_s32): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_s64_indices_1.c
(f_vld3q_lane_s64): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_s8_indices_1.c
(f_vld3q_lane_s8): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_u16_indices_1.c
(f_vld3q_lane_u16): Ditto.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_u32_indices_1.c
(f_vld3q_lane_u32): Ditto.
* 

[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly

[cbaylis at gcc dot gnu.org]

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

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from cbaylis at gcc dot gnu.org ---
Now fixed on trunk, for both ARM and AArch64 targets.

[Bug middle-end/68621] [6 Regression] FAIL: gcc.dg/tree-ssa/ifc-8.c scan-tree-dump-times ifcvt "Applying if-conversion" 1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|[5 Regression] FAIL:|[6 Regression] FAIL:
   |gcc.dg/tree-ssa/ifc-8.c |gcc.dg/tree-ssa/ifc-8.c
   |scan-tree-dump-times ifcvt  |scan-tree-dump-times ifcvt
   |"Applying if-conversion" 1  |"Applying if-conversion" 1

[Bug middle-end/68595] [6 regression] ice in const_vector_mask_from_tree at expr.c:11455

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
That LGTM, but please let richi review it on gcc-patches if it works.

[Bug tree-optimization/68592] [6 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1403 with -fprofile-generate

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/68595] [6 regression] ice in const_vector_mask_from_tree at expr.c:11455

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
So, either we should keep what used to be in _Bool/bool type in scalar code as
0/-1 at all spots, or as 0/1 at all spots, or as non-zero vs. zero, but choose
consistently one of those and adjust all the ops accordingly.  Say in the last
case original bool ~x needs to be vectorized as x == 0.
So, is 0/-1 the best choice for all targets?

[Bug middle-end/68595] [6 regression] ice in const_vector_mask_from_tree at expr.c:11455

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #5)
> So, either we should keep what used to be in _Bool/bool type in scalar code
> as 0/-1 at all spots, or as 0/1 at all spots, or as non-zero vs. zero, but
> choose consistently one of those and adjust all the ops accordingly.  Say in
> the last case original bool ~x needs to be vectorized as x == 0.
> So, is 0/-1 the best choice for all targets?

It was chosen for compatibility with vector extensions which are based off
openCL.  And yes, all targets generate truth values that way IIRC as the
result can be used in AND/OR masking operations directly.

[Bug middle-end/68595] [6 regression] ice in const_vector_mask_from_tree at expr.c:11455

[ienkovich at gcc dot gnu.org]

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

--- Comment #7 from Ilya Enkovich  ---
Right, scalar value needs to be adjusted before building a vector.  This patch
should resolve the issue:

diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 687f982..6e4b046 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -1300,7 +1300,25 @@ vect_init_vector (gimple *stmt, tree val, tree type,
gimple_stmt_iterator *gsi)
 {
   if (!types_compatible_p (TREE_TYPE (type), TREE_TYPE (val)))
{
- if (CONSTANT_CLASS_P (val))
+ /* Scalar boolean value should be transformed into
+all zeros or all ones value before building a vector.  */
+ if (VECTOR_BOOLEAN_TYPE_P (type))
+   {
+ tree true_val = build_zero_cst (TREE_TYPE (type));
+ tree false_val = build_all_ones_cst (TREE_TYPE (type));
+
+ if (CONSTANT_CLASS_P (val))
+   val = integer_zerop (val) ? false_val : true_val;
+ else
+   {
+ new_temp = make_ssa_name (TREE_TYPE (type));
+ init_stmt = gimple_build_assign (new_temp, COND_EXPR,
+  val, true_val, false_val);
+ vect_init_vector_1 (stmt, init_stmt, gsi);
+ val = new_temp;
+   }
+   }
+ else if (CONSTANT_CLASS_P (val))
val = fold_convert (TREE_TYPE (type), val);
  else
{

[Bug c/68622] New: initialization of atomic objects emits unnecessary fences

[msebor at gcc dot gnu.org]

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

Bug ID: 68622
   Summary: initialization of atomic objects emits unnecessary
fences
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Gcc emits unnecessary fences for expressions involving objects of atomic types
that are not (yet) shared across threads.  For example, in the two functions
below, the objects are not shared with other threads and thus the assignments
to the atomic variables do not require any fences.  Such assignments are
commonplace when objects containing atomic variables are being initializing (as
in the second function).

In comparison, Clang emits no fences for the functions below.

$ cat t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -O2 -S -Wall
-Wextra -o/dev/tty t.c
int foo (void)
{
_Atomic int i;
i = 0;
return i;
}

struct S {
_Atomic int i;
int n;
char data[];
};

extern void* malloc (__SIZE_TYPE__);

struct S* bar (int n)
{
struct S *s = malloc (sizeof *s + n);
s->i = 0;
return s;
}
.file   "t.c"
.machine power8
.abiversion 2
.section".toc","aw"
.section".text"
.align 2
.p2align 4,,15
.globl foo
.type   foo, @function
foo:
sync
li 9,0
stw 9,-16(1)
sync
lwz 3,-16(1)
cmpw 7,3,3
bne- 7,$+4
isync
extsw 3,3
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size   foo,.-foo
.align 2
.p2align 4,,15
.globl bar
.type   bar, @function
bar:
0:  addis 2,12,.TOC.-0b@ha
addi 2,2,.TOC.-0b@l
.localentry bar,.-bar
mflr 0
addi 3,3,8
std 0,16(1)
stdu 1,-32(1)
bl malloc
nop
sync
li 10,0
addi 1,1,32
stw 10,0(3)
ld 0,16(1)
mtlr 0
blr
.long 0
.byte 0,0,0,1,128,0,0,0
.size   bar,.-bar
.ident  "GCC: (GNU) 6.0.0 20151125 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug ada/68590] [6 Regression] FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check"

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
(In reply to Eric Botcazou from comment #7)
> > Instead it originates from
> > 
> > (for cmp (ge le)
> > 
> >  (simplify  
> > 
> >   (cmp @0 @0)   
> > 
> >   (eq @0 @0)))
> > 
> > hmm.  Yes, we use @0 twice here.  But we also use a matching capture, sth
> > we (unfortunately) don't record (yet).  We _do_ have a load that we
> > compare so avoiding the redundant computation when we duplicate an
> > operand makes sense even when there is no side-effect present (that was
> > the objective of the change).  Simplifying
> > 
> >  (le  s1->length s1->length)
> > 
> > to
> > 
> >  (eq save_expr length> save_expr length>)
> > 
> > looks like a win.
> 
> I beg to differ, s1->length has no TREE_SIDE_EFFECTS so it's a pessimization.
> Having no TREE_SIDE_EFFECTS *precisely* means that you are free to reuse the
> object as-is in the same expression any number of times.

So the original compliant was that if we do that we pessimize code-gen
because we un-CSE a possibly large sub-expression.  So you say that any
tree-shared expr is only expanded once (as if it were wrapped in a save-expr)?

> > Now simplifying that down to
> > 
> >  (save_expr length>, 1)
> > 
> > is "correct" as well.  And we can't just drop random save_exprs here because
> > of the comment in save_expr:
> > 
> >   /* This expression might be placed ahead of a jump to ensure that the
> >  value was computed on both sides of the jump.  So make sure it isn't
> >  eliminated as dead.  */
> >   TREE_SIDE_EFFECTS (t) = 1;
> > 
> > not sure what this is refering to... it sounds confusing - if it was placed
> > there and did not have side-effects it better should have a user via a
> > data dependence.
> 
> Having TREE_SIDE_EFFECTS on SAVE_EXPRs is required for GENERIC folding (of
> course not if your ultimate objective is to kill GENERIC folding...) because
> if you have something like:
> 
>   COND_EXPR 
> 
> and want to turn it into:
> 
>   COND_EXPR 
> 
> the SAVE_EXPR  will create a variable that will be initialized once, in
> other words in only one of the arms and you don't know which one at compile
> time.  So you need to create a COMPOUND_EXPR:
> 
>   COMPOUND_EXPR , COND_EXPR  SAVE_EXPR  - op2>>
> 
> to make sure it is evaluated ahead of the branch and TREE_SIDE_EFFECTS is
> required to keep the first operand.

Oh, so fold is performing CSE here?  Shouldn't _that_ folding not set
TREE_SIDE_EFFECTS on the SAVE_EXPR?  Instead of forcing it on every user...

Btw, I can't find such transform in fold-const.c

> I'll note that the problematic change comes with neither a testcase nor a
> comment (and the original comment about TREE_SIDE_EFFECT is even still
> there) so it's little hard to understand where it comes from...

And may even test ok (testing a removal right now...)

[Bug target/68618] interrupt fails on ICE in some call cases with miamcu with -O2/3

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Target||x86
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-30
  Component|other   |target
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Works for me on hjl/interrupt/stage1 branch:

[hjl@gnu-6 gcc]$ cat x.c
struct interrupt_frame;

void (*foo1[1])(int a, int b);

void foo2(int c)
{
foo1[c](1,2);
}

static __attribute__((interrupt)) void my_isr(struct interrupt_frame *frame)
{
int c;
foo2(c);
}


int main()
{
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -m32 -miamcu -O3 -DU x.c -S
[hjl@gnu-6 gcc]$

[Bug ada/68590] [6 Regression] FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check"

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
The following avoids the issue in this PR

Index: gcc/match.pd
===
--- gcc/match.pd(revision 231065)
+++ gcc/match.pd(working copy)
@@ -1828,15 +1828,14 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)

 /* Simplify comparison of something with itself.  For IEEE
floating-point, we can only do some of these simplifications.  */
-(simplify
- (eq @0 @0)
- (if (! FLOAT_TYPE_P (TREE_TYPE (@0))
-  || ! HONOR_NANS (TYPE_MODE (TREE_TYPE (@0
-  { constant_boolean_node (true, type); }))
-(for cmp (ge le)
+(for cmp (eq ge le)
  (simplify
   (cmp @0 @0)
-  (eq @0 @0)))
+  (if (! FLOAT_TYPE_P (TREE_TYPE (@0))
+   || ! HONOR_NANS (TYPE_MODE (TREE_TYPE (@0
+   { constant_boolean_node (true, type); }
+   (if (cmp != EQ_EXPR)
+(eq @0 @0)
 (for cmp (ne gt lt)
  (simplify
   (cmp @0 @0)

[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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov 30 14:56:08 2015
New Revision: 231075

URL: https://gcc.gnu.org/viewcvs?rev=231075=gcc=rev
Log:
PR tree-optimization/68501
* target.def (builtin_reciprocal): Replace the 3 arguments with
a gcall * one, adjust description.
* targhooks.h (default_builtin_reciprocal): Replace the 3 arguments
with a gcall * one.
* targhooks.c (default_builtin_reciprocal): Likewise.
* tree-ssa-math-opts.c (pass_cse_reciprocals::execute): Use
targetm.builtin_reciprocal even on internal functions, adjust
the arguments and allow replacing an internal function with normal
built-in.
* config/i386/i386.c (ix86_builtin_reciprocal): Replace the 3 arguments
with a gcall * one.  Handle internal fns too.
* config/rs6000/rs6000.c (rs6000_builtin_reciprocal): Likewise.
* config/aarch64/aarch64.c (aarch64_builtin_reciprocal): Likewise.
* doc/tm.texi (builtin_reciprocal): Document.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/i386/i386.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/doc/tm.texi
trunk/gcc/target.def
trunk/gcc/targhooks.c
trunk/gcc/targhooks.h
trunk/gcc/tree-ssa-math-opts.c

[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

 Status|NEW |RESOLVED
 CC||mshawcroft at gcc dot gnu.org,
   ||rearnsha at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Jakub Jelinek  ---
Hopefully fixed for i?86/x86_64/rs6000.  On aarch64 I haven't wired this in the
builtin_reciprocal function, leaving that to aarch64 maintainers how they want
to handle it.

[Bug middle-end/68621] New: [5 Regression] FAIL: gcc.dg/tree-ssa/ifc-8.c scan-tree-dump-times ifcvt "Applying if-conversion" 1

[hjl.tools at gmail dot com]

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

Bug ID: 68621
   Summary: [5 Regression] FAIL: gcc.dg/tree-ssa/ifc-8.c
scan-tree-dump-times ifcvt "Applying if-conversion" 1
   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: venkataramanan.kumar at amd dot com
  Target Milestone: ---

r231057 caused:

FAIL: gcc.dg/tree-ssa/ifc-8.c scan-tree-dump-times ifcvt "Applying
if-conversion" 1

with

make check-gcc RUNTESTFLAGS="--target_board='unix{-m32\ -fpic}'
tree-ssa.exp=ifc-8.c"

on x86.

[Bug target/68618] interrupt fails on ICE in some call cases with miamcu with -O2/3

[vaalfreja at gmail dot com]

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

Yulia Koval  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Yulia Koval  ---
Works for me.

[Bug rtl-optimization/68623] New: lra doesn't check predicate after reloading an early clobber

[mrs at gcc dot gnu.org]

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

Bug ID: 68623
   Summary: lra doesn't check predicate after reloading an early
clobber
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mrs at gcc dot gnu.org
  Target Milestone: ---

lra doesn't check the predicate after reload an output register to ensure the
instruction remains valid. The predicate is the load_multiple_operation and it
ensures that the hard registers are sequential.  When the first output register
is the same as the address, then the input register must be reloaded.  The
output register cannot be, unless all the output registers are and then the
specific property embodied by load_multiple_operation would need to be
preserved.  Here is the pattern:

(define_insn "*ldmdi2"
 [(match_parallel 0 "load_multiple_operation"
   [(set (match_operand:DI 1 "a_hard_register_operand" "=")
 (mem:DI (match_operand:DI 2 "register_operand" "r")))
(set (match_operand:DI 3 "c1_hard_register_operand" "")
 (mem:DI (plus:DI (match_dup 2) (match_operand 4 "const_int_operand"
"KS10"])]
 ""
 "ldm\t%1,{%2,%3|0(%2),2}"
 [(set_attr "type" "ldm")
  (set_attr "count" "2")])

and the instruction after reload:

(insn 28 27 55 2 (parallel [
(set (reg:DI 27 $work1 [208])
(mem:DI (reg/v/f:DI 19 $a1 [orig:187 p ] [187]) [0  S8 A64]))
(set (reg:DI 20 $a2)
(mem:DI (plus:DI (reg/v/f:DI 19 $a1 [orig:187 p ] [187])
(const_int 8 [0x8])) [0  S8 A64]))
]) t.c:28 349 {*ldmdi2}
 (nil))

before reload, $a1 is set in the first set.  $a1 and $a2 are sequential.  The
predicate:

(define_predicate "load_multiple_operation"
  (match_code "parallel")
{
  int count = XVECLEN (op, 0);  
  int dest_regno;   
  rtx src_addr; 
  int i;

  /* Perform a quick check so we don't blow up below.  */
  if (count <= 1
  || GET_CODE (XVECEXP (op, 0, 0)) != SET
  || GET_CODE (SET_DEST (XVECEXP (op, 0, 0))) != REG
  || GET_CODE (SET_SRC (XVECEXP (op, 0, 0))) != MEM)
return 0;   

  dest_regno = REGNO (SET_DEST (XVECEXP (op, 0, 0)));   
  src_addr = XEXP (SET_SRC (XVECEXP (op, 0, 0)), 0);

  if (dest_regno >= FIRST_PSEUDO_REGISTER
  || (dest_regno + count) > FIRST_PSEUDO_REGISTER)
return 0;   


  /* Check, is base, or base + displacement.  */

  if (GET_CODE (src_addr) != REG)
return 0;   

  for (i = 1; i < count; i++)   
{
  rtx elt = XVECEXP (op, 0, i); 
  if (debugit) {
printf("i = %d\n",i);   
debug_rtx(elt); 
  }
  if (GET_CODE (elt) != SET
  || GET_CODE (SET_DEST (elt)) != REG
  || GET_MODE (SET_DEST (elt)) != DImode
  || REGNO (SET_DEST (elt)) != (unsigned) (dest_regno + i)
  || GET_CODE (SET_SRC (elt)) != MEM
  || GET_MODE (SET_SRC (elt)) != DImode
  || GET_CODE (XEXP (SET_SRC (elt), 0)) != PLUS
  || ! rtx_equal_p (XEXP (XEXP (SET_SRC (elt), 0), 0), src_addr)
  || GET_CODE (XEXP (XEXP (SET_SRC (elt), 0), 1)) != CONST_INT
  || INTVAL (XEXP (XEXP (SET_SRC (elt), 0), 1)) != i * 8)
return 0;   
}

  return 1; 
})

[Bug tree-optimization/68619] [6 Regression] error: loop with header 6 not in loop tree

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from Jeffrey A. Law  ---
r228739 may have been the trigger, but I think it's uncovering a latent bug in
DOM.  At first glance it looks like DOM is removing an edge when it simplifies
a conditional.  That in turn seems to expose two subloops that were previously
ignored because they were irreducible -- with the edge removed, those two
subloops become reducible.

Once the loops are reducible, the loop optimizer wants them to have proper loop
structures.  They don't and verify_loop_structure aborts. 

Richi had the suggestion that we should defer those particular CFG
manipulations in DOM, which has been on my TODO list.  That fixes this problem
(the CFG cleanup code will set LOOPS_NEED_FIXUP, which DOM avoids per Richi's
request). 

I've been wanted to analyze any unexpected side effects of doing that, so, now
seems to be the right time.

[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 #8 from Martin Reinecke  ---
I confirm that I can build again when provoding the ISL 0.15 sources withon the
gcc/ directory.

In order to save others some head-scratching, would it be possible to update
the ISL version check in the configuration machinery so that it gives a clear
error when encountering an ISL version that is too old?

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

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Confirmed with today's trunk.  Seems to be caused by the merge of the delayed
folding work (r230365).  Prior versions accept the code without an error.

[Bug middle-end/68565] [6 Regression] graphite : -O2 -floop-nest-optimize miscompile

[spop at gcc dot gnu.org]

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

--- Comment #2 from Sebastian Pop  ---
Author: spop
Date: Mon Nov 30 20:39:16 2015
New Revision: 231086

URL: https://gcc.gnu.org/viewcvs?rev=231086=gcc=rev
Log:
check for ISL generated code that leads to division by zero

we used to generate modulo and division by zero because ISL uses big numbers
which translate to zero in modulo arithmetic.  The patch also improves error
handling
and bails out early in case of wrong code gen.

PR tree-optimization/68565
* graphite-isl-ast-to-gimple.c (binary_op_to_tree): Early return on
codegen_error.  Fail when rhs of division operations is integer_zerop.
(ternary_op_to_tree): Early return on codegen_error.
(unary_op_to_tree): Same.
(nary_op_to_tree): Same.
(gcc_expression_from_isl_expr_op): Same.
(gcc_expression_from_isl_expression): Same.
(graphite_create_new_loop): On codegen_error continue generating
wrong code.
(graphite_create_new_loop_guard): Same.
(build_iv_mapping): Same.
(graphite_create_new_guard): Same.

* gfortran.dg/graphite/pr68565.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/graphite/pr68565.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/68565] [6 Regression] graphite : -O2 -floop-nest-optimize miscompile

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #3 from Sebastian Pop  ---
Fixed.  Thanks for the testcase!

[Bug tree-optimization/68624] New: wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)

[su at cs dot ucdavis.edu]

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

Bug ID: 68624
   Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu (in
64-bit mode)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O2
and -O3 in the 64-bit mode (but not in the 32-bit mode). 

This is a regression from 5.2.x. 

Perhaps to do with VRP as -fno-tree-vrp seems to fix the miscompilation. 


$ 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 20151130 (experimental) [trunk revision 231056] (GCC) 
$ 
$ gcc-trunk -m64 -Os small.c; ./a.out
$ gcc-trunk -m32 -O2 small.c; ./a.out
$ gcc-trunk -m64 -O2 -fno-tree-vrp small.c; ./a.out
$ gcc-5.2 -m64 -O2 small.c; ./a.out
$ 
$ gcc-trunk -m64 -O2 small.c
$ ./a.out
Aborted (core dumped)
$ 


-


int b, c, d, e = 1, f, g, h, j;

static int
fn1 ()
{
  int a = c;
  if (h)
return 9;
  g = (c || b) % e;
  if ((g || f) && b)
return 9;
  e = d;
  for (c = 0; c > -4; c--)
;
  if (d)
c--;
  j = c;
  return d;
}

int
main ()
{
  fn1 ();

  if (c != -4) 
__builtin_abort (); 

  return 0;
}

[Bug c/68612] Const-compatibility in C

[alexreg at gmail dot com]

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

--- Comment #4 from Alexander Regueiro  ---
Okay, I see. Going through the C Standards Committee is a very long,
bureaucratic, and fraught process – as I'm sure you're aware. Is there any
reason you wouldn't consider adding this as an extension to GCC, with a
simultaneous proposal to the C Standards Committee? Of course, you've added
numerous non-standard features to the C compiler for GCC in the past, so why
not this one? If you need more specific convincing, I'm happy to provide it!

[Bug c++/68604] typeid does not allow an id-expression that denotes a non-static data member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-01
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||6.0

--- Comment #1 from Martin Sebor  ---
I tend to agree that this is valid (A::i is a valid id-expression in an
unevaluated context), even though my somewhat dated version of Clang (3.8.0,
trunk 251144, from 2015-10-23) rejects the code with the same error as GCC (see
below).  AFAICT, this was made valid for sizeof via N2253, and the changes
there extend to the typeid expression as well:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2253.html

$ cat z.cpp && /build/llvm-trunk/bin/clang++ -S -Wall -Wextra -o /dev/null
z.cpp 
namespace std {
struct type_info {
virtual ~type_info () { }
};
}

struct A { int i; };

int main()
{
typeid (A::i);
}

z.cpp:11:16: error: invalid use of non-static data member 'i'
typeid (A::i);
~~~^
1 error generated.

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

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 CC||jason at redhat dot com
  Known to work||5.2.0

--- Comment #3 from Volker Reichelt  ---
You're right Martin, The bug indeed appeared with r230365.

[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres  ---
> Based on some checking on older systems I think that Apple switched to 
> llvm-dsymutil (part of LLVM source) on El Capitan.  Not sure about 
> Yosemite.  I tried darwin10's dsymutil and it does NOT produce any 
> warnings on the same set of object files.

The warnings come with Xcode 7* (for me on Yosemite).

[Bug c++/65198] [4.9 Regression] User-defined literal template inside generic lambda segfaults

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-01
 CC||msebor at gcc dot gnu.org
  Known to work|5.0 |5.1.0
Version|5.0 |4.9.3
 Ever confirmed|0   |1
  Known to fail||4.9.3

--- Comment #4 from Martin Sebor  ---
Both GCC 5.1.0 and 6.0 (today's trunk) compile the code without any errors. 
GCC 4.9.2 and 4.9.3 fail with the ICE in comment #3. Changing Version to
reflect that.

[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7

[nenad at intrepid dot com]

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

--- Comment #11 from Nenad Vukicevic  ---
On 11/24/2015 3:27 PM, iains at gcc dot gnu.org wrote:

> OK so it appears that we do have two issues;
>
> 1. that we're (incorrectly) calling dsymutil for "link only" cases where
> there's no LTO involved (and that seems to be a typo in the argument to
> post_ld_pass() on line 820).  We located the PR that gave rise to the change
> (61352) and will just double-check that we do not regress that with the 
> change.
>   Could you make the change locally and see if it makes the problem "go away"?
> (I note that it doesn't in any way fix #2).

I already tried this approach and the problem "goes away" as we simple 
do not execute dsymutil. But, the executable still contains symbols that 
will cause the warnings.  I think that this will match what clang is 
doing as the linker spec for darwin adds 'idsym' and 'dsym' depending on 
the source:

---
darwin.h
#define DSYMUTIL_SPEC \
"%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
 %{v} \
 %{gdwarf-2:%{!gstabs*:%{!g0: -idsym}}}\
 %{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: \
 %{gdwarf-2:%{!gstabs*:%{!g0: -dsym}}}"

#define LINK_COMMAND_SPEC LINK_COMMAND_SPEC_A DSYMUTIL_SPEC
---

and 'dsymutil' will be called if:

- source file is on the command line
- some object files have lto

and it will not be called if we link object files only.

collect2.c
---
static void
post_ld_pass (bool temp_file) {
   if (!(temp_file && flag_idsym) && !flag_dsym)
 return;

   do_dsymutil (output_file);
}
---

> 2. Some as yet unexplained issue with new dsymutil
> it's probable that if you can do something like:
>
> clang a.o b.o  z.o -g -o t
> dsymutil t
> and get errors - then the right thing is to file a radar (since that's really
> only using ld64 and dsymutil - which are both outside the GCC source base).

It would be hard in our case to come up with an example that can 
duplicate the problem.  To many libraries and prepossessed files, etc..

> It's possible that there's some fault  with symbols in the object files that
> doesn't somehow affect linking and doesn't trip up nm .. but adversely affects
> dsymutil - not sure I can exactly envision that right now.
Based on some checking on older systems I think that Apple switched to 
llvm-dsymutil (part of LLVM source) on El Capitan.  Not sure about 
Yosemite.  I tried darwin10's dsymutil and it does NOT produce any 
warnings on the same set of object files.

[Bug tree-optimization/68529] scev failed for while(i--)

[amker at gcc dot gnu.org]

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

--- Comment #7 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Dec  1 05:22:16 2015
New Revision: 231097

URL: https://gcc.gnu.org/viewcvs?rev=231097=gcc=rev
Log:

PR tree-optimization/68529
* tree-ssa-loop-niter.c (number_of_iterations_ne): Add new param.
Compute no-overflow information for control iv.
(number_of_iterations_lt, number_of_iterations_le): Add new param.
(number_of_iterations_cond): Pass new argument to above functions.

PR tree-optimization/68529
* gcc.dg/tree-ssa/pr68529-1.c: New test.
* gcc.dg/tree-ssa/pr68529-2.c: New test.
* gcc.dg/tree-ssa/pr68529-3.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr68529-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr68529-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr68529-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-niter.c

[Bug lto/68626] Compiling with "-flto -fuse-linker-plugin" gives libtool error

[john.frankish at outlook dot com]

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

--- Comment #6 from john.frankish at outlook dot com ---
Hmm, but binutils was configured with:

CC="gcc -flto -fuse-linker-plugin -mtune=generic -Os -pipe" CXX="g++ -flto
-fuse-linker-plugin -mtune=generic -Os -pipe" ../binutils-2.24.51/configure
--prefix=/usr/local --enable-shared --disable-werror --enable-lto
--with-mpc=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local
--with-cloog=/usr/local --with-isl=/usr/local --enable-plugins

[Bug lto/68626] Compiling with "-flto -fuse-linker-plugin" gives libtool error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Version|lto |4.9.1

--- Comment #7 from Andrew Pinski  ---
Next step use strace to debug why nm is not picking up the plugin.  It should
list a few open syscalls.

[Bug lto/68626] Compiling with "-flto -fuse-linker-plugin" gives libtool error

[john.frankish at outlook dot com]

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

--- Comment #8 from john.frankish at outlook dot com ---
Ah...

$strace nm test.o
...
lstat("/usr/local/bin/nm", {st_mode=S_IFLNK|0777, st_size=37, ...}) = 0
readlink("/usr/local/bin/nm", "/tmp/tcloop/binutils/usr/local/b"..., 4095) = 37
lstat("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=240, ...}) = 0
lstat("/tmp/tcloop", {st_mode=S_IFDIR|0775, st_size=2660, ...}) = 0
lstat("/tmp/tcloop/binutils", {st_mode=S_IFDIR|0755, st_size=26, ...}) = 0
lstat("/tmp/tcloop/binutils/usr", {st_mode=S_IFDIR|0755, st_size=28, ...}) = 0
lstat("/tmp/tcloop/binutils/usr/local", {st_mode=S_IFDIR|0755, st_size=85,
...}) = 0
lstat("/tmp/tcloop/binutils/usr/local/bin", {st_mode=S_IFDIR|0755, st_size=228,
...}) = 0
lstat("/tmp/tcloop/binutils/usr/local/bin/nm", {st_mode=S_IFREG|0755,
st_size=37088, ...}) = 0
openat(AT_FDCWD,
"/tmp/tcloop/binutils/usr/local/bin/../bin/../lib/bfd-plugins",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)

$ sudo cp /tmp/tcloop/binutils/usr/local/bin/nm /usr/local/bin
$ nm test.o
 T f

Is that the expected result?

In this distro, packages are loop mounted squashfs symlinked to the root file
system...

[Bug go/68477] error: type variant differs by TYPE_STRING_FLAG.

[ian at gcc dot gnu.org]

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

--- Comment #2 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Dec  1 04:45:53 2015
New Revision: 231096

URL: https://gcc.gnu.org/viewcvs?rev=231096=gcc=rev
Log:
PR go/68477
* go-gcc.cc (Gcc_backend::string_constant_expression): Don't set
TYPE_STRING_FLAG on a variant type.

Modified:
trunk/gcc/go/ChangeLog
trunk/gcc/go/go-gcc.cc

[Bug go/68477] error: type variant differs by TYPE_STRING_FLAG.

[ian at gcc dot gnu.org]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #3 from Ian Lance Taylor  ---
Fixed.  Thanks for reporting it.

[Bug go/68477] error: type variant differs by TYPE_STRING_FLAG.

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Dec  1 04:45:53 2015
New Revision: 231096

URL: https://gcc.gnu.org/viewcvs?rev=231096=gcc=rev
Log:
PR go/68477
* go-gcc.cc (Gcc_backend::string_constant_expression): Don't set
TYPE_STRING_FLAG on a variant type.

Modified:
trunk/gcc/go/ChangeLog
trunk/gcc/go/go-gcc.cc

--- Comment #3 from Ian Lance Taylor  ---
Fixed.  Thanks for reporting it.

[Bug lto/68626] Compiling with "-flto -fuse-linker-plugin" gives libtool error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |lto

--- Comment #3 from Andrew Pinski  ---
(In reply to john.frankish from comment #2)
> I believe /usr/local/lib/bfd-plugins/liblto_plugin.so (symlink to
> /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/liblto_plugin.so) is the
> correct location?

Can you do a quick test to see if nm/ld finds that?

That is compile the following with -c -flto -fuse-linker-plugin:
int f(void) { return 0; }
--- CUT ---
and run nm on the resulting object file?

[Bug tree-optimization/68625] New: [6 Regression] Segmentation fault in useless_type_conversion_p

[asolokha at gmx dot com]

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

Bug ID: 68625
   Summary: [6 Regression] Segmentation fault in
useless_type_conversion_p
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

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

gcc-6.0.0-alpha20151129 for x86_64-pc-linux-gnu segfaults when compiling the
attached (incorrect) testcase at -O2, -O3, or -Ofast.

% x86_64-pc-linux-gnu-gcc-6.0.0-alpha20151129 -w -c -O2 sqyrkevd.c 
sqyrkevd.c: In function 'z9':
sqyrkevd.c:5:1: internal compiler error: Segmentation fault
 z9(void)
 ^~

Partial backtrace:
#0  0x0089ad20 in useless_type_conversion_p(tree_node*, tree_node*) ()
#1  0x00cb4b50 in may_propagate_copy(tree_node*, tree_node*) ()
#2  0x00b4e641 in ?? ()
#3  0x0071f7f6 in merge_blocks(basic_block_def*, basic_block_def*) ()
#4  0x00b584c6 in ?? ()
#5  0x00b59119 in cleanup_tree_cfg() ()
#6  0x00a41575 in ?? ()
#7  0x00a41fcc in ?? ()
#8  0x00a4487e in execute_one_pass(opt_pass*) ()
#9  0x00a44e38 in ?? ()
#10 0x00a44e4a in ?? ()
#11 0x00a44e4a in ?? ()
#12 0x00a44e95 in execute_pass_list(function*, opt_pass*) ()
#13 0x0074e367 in cgraph_node::expand() ()
#14 0x0074fcd7 in ?? ()
#15 0x00752323 in symbol_table::finalize_compilation_unit() ()
#16 0x00b0fed2 in ?? ()
#17 0x005ba906 in toplev::main(int, char**) ()
#18 0x005bcb17 in main ()

I cannot reproduce it w/ the same snapshot for target
powerpc-e500v2-linux-gnuspe.

[Bug c/68626] Compiling with "-flto -fuse-linker-plugin" gives libtool error

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
> This can be fixed by using NM="gcc-nm", but as binutils was compiled with lto
> enabled,  it shouldn't be required?

Do you have the linker plugin in the correct location for ld/nm to find it?

[Bug c/68626] New: Compiling with "-flto -fuse-linker-plugin" gives libtool error

[john.frankish at outlook dot com]

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

Bug ID: 68626
   Summary: Compiling with "-flto -fuse-linker-plugin" gives
libtool error
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.frankish at outlook dot com
  Target Milestone: ---

Compiling some packages with "-flto -fuse-linker-plugin" gives a libtool error
during "make". Compiling the same package without "-flto -fuse-linker-plugin"
allows "make" to complete without errors. 

Using gcc-4.9.1/binutils-2.24.51 or gcc-5.2.0/binutils-2.25.1 

The problem seems to occur with a few 10's of packages (eg cogl-1.20.0), but
not with others (eg gnome-music-3.16.2). 

Using cogl-1.20.0 as an example: 

CC="gcc -flto -fuse-linker-plugin -mtune=generic -Os -pipe" CXX="g++ -flto
-fuse-linker-plugin -mtune=generic -Os -pipe -fno-exceptions -fno-rtti" 
./configure --prefix=/usr/local --disable-static --localstatedir=/var
--enable-gles1 --enable-gles2 --enable-cogl-gst=yes 

find . -name Makefile -type f -exec sed -i 's/-g -O2//g' {} \; 

make
... 
CC cogl-enum-types.lo
CCLD libcogl.la
../libtool: eval: line 1: syntax error: unexpected "|" 
Makefile:1507: recipe for target 'libcogl.la' failed
make[4]: *** [libcogl.la] Error 2 

This can be fixed by using NM="gcc-nm", but as binutils was compiled with lto
enabled, it shouldn't be required?

[Bug c/68626] Compiling with "-flto -fuse-linker-plugin" gives libtool error

[john.frankish at outlook dot com]

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

--- Comment #2 from john.frankish at outlook dot com ---
I believe /usr/local/lib/bfd-plugins/liblto_plugin.so (symlink to
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/liblto_plugin.so) is the
correct location?

[Bug lto/68626] Compiling with "-flto -fuse-linker-plugin" gives libtool error

[john.frankish at outlook dot com]

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

--- Comment #4 from john.frankish at outlook dot com ---
$echo 'int f(void) { return 0; }' > test.c
$ cc test.c -c -flto -fuse-linker-plugin
$ nm test.o
0001 C __gnu_lto_slim
0001 C __gnu_lto_v1

[Bug lto/68626] Compiling with "-flto -fuse-linker-plugin" gives libtool error

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to john.frankish from comment #4)
> $echo 'int f(void) { return 0; }' > test.c
> $ cc test.c -c -flto -fuse-linker-plugin
> $ nm test.o
> 0001 C __gnu_lto_slim
> 0001 C __gnu_lto_v1

Which means it is not using the plugin at all.  How did you configure binutils?
Did you configure binutils with --enable-plugins ?  If you did not, then bfd
will not use the plugins, though ld will.

[Bug lto/68626] Compiling with "-flto -fuse-linker-plugin" gives libtool error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
(In reply to john.frankish from comment #8)
> Ah...
> 
> $strace nm test.o
> ...
> lstat("/usr/local/bin/nm", {st_mode=S_IFLNK|0777, st_size=37, ...}) = 0
> readlink("/usr/local/bin/nm", "/tmp/tcloop/binutils/usr/local/b"..., 4095) =
> 37
> lstat("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=240, ...}) = 0
> lstat("/tmp/tcloop", {st_mode=S_IFDIR|0775, st_size=2660, ...}) = 0
> lstat("/tmp/tcloop/binutils", {st_mode=S_IFDIR|0755, st_size=26, ...}) = 0
> lstat("/tmp/tcloop/binutils/usr", {st_mode=S_IFDIR|0755, st_size=28, ...}) =
> 0
> lstat("/tmp/tcloop/binutils/usr/local", {st_mode=S_IFDIR|0755, st_size=85,
> ...}) = 0
> lstat("/tmp/tcloop/binutils/usr/local/bin", {st_mode=S_IFDIR|0755,
> st_size=228, ...}) = 0
> lstat("/tmp/tcloop/binutils/usr/local/bin/nm", {st_mode=S_IFREG|0755,
> st_size=37088, ...}) = 0
> openat(AT_FDCWD,
> "/tmp/tcloop/binutils/usr/local/bin/../bin/../lib/bfd-plugins",
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or
> directory)
> 
> $ sudo cp /tmp/tcloop/binutils/usr/local/bin/nm /usr/local/bin
> $ nm test.o
>  T f
> 
> Is that the expected result?
> 
> In this distro, packages are loop mounted squashfs symlinked to the root
> file system...

You need to install the linker script in relative to where binutils is
installed and not relative to where the symbol link is located.  So the correct
location for the linker script is in the
/tmp/tcloop/binutils/usr/local/bin/../bin/../lib/bfd-plugins directory.

[Bug ada/68590] [6 Regression] FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check"

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
> So the original compliant was that if we do that we pessimize code-gen
> because we un-CSE a possibly large sub-expression.

Then maybe the "possibly large sub-expression" should be taken into account.
We already try by means of skip_simple_arithmetic, but it's too simple.

> So you say that any tree-shared expr is only expanded once (as if it were 
> wrapped in a save-expr)?

No, it will be reexpanded if it has no TREE_SIDE_EFFECTS.  What I'm saying is
that you control it by means of TREE_SIDE_EFFECTS.

> Oh, so fold is performing CSE here?  Shouldn't _that_ folding not set
> TREE_SIDE_EFFECTS on the SAVE_EXPR?  Instead of forcing it on every user...

It's not just fold, it's the way SAVE_EXPR works in GENERIC.  You need to be
able to control when the variable is initialized at run time, otherwise it's a
recipe for disaster.

[Bug target/68627] New: [i386, AVX-512] Illegal insn generated while compiling spec2k6/437.leslie3d for KNL

[kyukhin at gcc dot gnu.org]

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

Bug ID: 68627
   Summary: [i386, AVX-512] Illegal insn generated while compiling
spec2k6/437.leslie3d for KNL
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kyukhin at gcc dot gnu.org
  Target Milestone: ---

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

Attached reduced testcase.

When -march=knl switch is passed, AVX-512 insn illegally generated.

$ gfortran -Ofast -mavx512f test.f -S
$ grep vbroadcastsd test.s | grep ymm
vbroadcastsd%xmm11, %ymm7

We need to force %zmm source for this broadcast and limit alternative to
at least AVX-512F

[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška  ---
(In reply to milan.plzik from comment #17)
> with gcc 5.2.0, I still get this error when e.g. compiling ChibiOS example:
> $ make
> Linking build/ch.elf
> lto1: internal compiler error: in add_symbol_to_partition_1, at
> lto/lto-partition.c:158
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> lto-wrapper: fatal error: arm-none-eabi-gcc returned 1 exit status
> compilation terminated.
> /usr/lib/gcc/arm-none-eabi/5.2.0/../../../../arm-none-eabi/bin/ld:
> lto-wrapper failed
> collect2: error: ld returned 1 exit status
> ../../../os/common/ports/ARMCMx/compilers/GCC/rules.mk:238: recipe for
> target 'build/ch.elf' failed
> make: *** [build/ch.elf] Error 1
> 
> $ arm-none-eabi-gcc -v
> Using built-in specs.
> COLLECT_GCC=arm-none-eabi-gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/5.2.0/lto-wrapper
> Target: arm-none-eabi
> Configured with: /build/arm-none-eabi-gcc/src/gcc-5.2.0/configure
> --target=arm-none-eabi --prefix=/usr --with-sysroot=/usr/arm-none-eabi
> --with-native-system-header-dir=/include --libexecdir=/usr/lib
> --enable-languages=c,c++ --enable-plugins --disable-decimal-float
> --disable-libffi --disable-libgomp --disable-libmudflap
> --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls
> --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld
> --with-system-zlib --with-newlib --with-headers=/usr/arm-none-eabi/include
> --with-python-dir=share/gcc-arm-none-eabi --with-gmp --with-mpfr --with-mpc
> --with-isl --with-libelf --enable-gnu-indirect-function
> --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
> --with-pkgversion='Arch Repository'
> --with-bugurl=https://bugs.archlinux.org/
> --with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r
> Thread model: single
> gcc version 5.2.0 (Arch Repository)

Hi.

Can you please provide a test-case which I can reproduce?

Thanks,
Martin

[Bug libitm/68591] trans-mem: missing transactional read in transaction when using -O1

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Just a random guess - it might be that TM uses TREE_ADDRESSABLE in some ways
to detect non-aliased memory (may_be_aliased?)  But of course you don't need
aliasing (pointers) to get multi-thread conflicts.

[Bug tree-optimization/68592] [6 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1403 with -fprofile-generate

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-30
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Other folks have requested a control to increase the EH emergency pool size
even more.  Would an environment like LIBSTDCXX_EMERGENCY_EH_POOL_SIZE=N suit
you,
possibly with a configure-time default?

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[mark at gcc dot gnu.org]

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

--- Comment #15 from Mark Wielaard  ---
(In reply to Andi Kleen from comment #14)
> I'm building a current Linux kernel with allyesconfig, and this new warning
> causes
> 1383(!) new warnings in the build.
> 
> I think this should be revisited and the warning be turned off again.

Could you post some examples?
Are they in your opinion all false positives?
Or is there a specific pattern to the ones you think are falsely flagged?
Note that you can always just specify -Wno-unused-const-variable if they are
real warnings, but you wish to ignore them.

[Bug ada/68590] [6 Regression] FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|FAIL:   |[6 Regression] FAIL:
   |gnat.dg/loop_optimization19 |gnat.dg/loop_optimization19
   |.adb scan-tree-dump-not |.adb scan-tree-dump-not
   |optimized "Index_Check" |optimized "Index_Check"

[Bug middle-end/68595] [6 regression] ice in const_vector_mask_from_tree at expr.c:11455

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0

--- Comment #2 from Richard Biener  ---
I will have a look.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.3

[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Mon Nov 30 08:24:06 2015
New Revision: 231058

URL: https://gcc.gnu.org/viewcvs?rev=231058=gcc=rev
Log:
2015-11-30  Richard Biener  

PR c/68162
* dwarf2out.c (gen_type_die_with_usage): Keep variant types
of arrays.

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

[Bug ada/68590] FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check"

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
I will have a look.

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

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-30
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
(In reply to Jakub Jelinek from comment #1)
> 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.

Yeah, I think we should be doing the first one (defining the optab
naturally and leaving the vectoriser to fix things up).  Working on
a patch...

[Bug c++/68615] New: Unhelpful location when missing a semi-colon on a function declaration at the end of a header

[redi at gcc dot gnu.org]

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

Bug ID: 68615
   Summary: Unhelpful location when missing a semi-colon on a
function declaration at the end of a header
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

# 1 "foo.cc"
# 1 "foo.h" 1
int f()
# 2 "foo.cc" 2

int main()
{
  f();
}


This gives:

foo.cc:3:1: error: expected initializer before ‘int’
 int main()
 ^

We fixed the case where we're missing ; after a class definition so the error
location is the end of the class, but for this case we still give the location
as the start of main. Ideally it would be:

foo.h:1:7: error: expected ‘;’ after function declaration


Related to Bug 56084, but that is about error recovery following the missing ;
and this is just about the location.

[Bug debug/53927] wrong value for DW_AT_static_link

[pmderodat at gcc dot gnu.org]

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

pmderodat at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||pmderodat at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |pmderodat at gcc dot 
gnu.org
   Target Milestone|--- |6.0

--- Comment #25 from pmderodat at gcc dot gnu.org ---
DW_AT_static_link is properly generated after revision 230968.

[Bug fortran/68600] Inlined MATMUL is too slow.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #6 from Dominique d'Humieres  ---
> I think you are seeing the effects of inefficiencies of assumed-shape arrays.
>
> If you want to use matmul on very small matrix sizes, it is best to
> use fixed-size explicit arrays.

Well, the problem is that MATMUL inlining is the default. IMO it should be
restricted to fixed-size explicit arrays (and small matrices?), at least for
the 6.1 version.

> Created attachment 36869 [details]
> Thomas program with a modified dgemm.
>
> The dgemm in this example is a stripped out version of an "optimized for 
> cache"
> version from netlib.org.  I stripped out a lot of the unused code.

It is probably too late for 6.1, but the results are quite impressive
(~30Gflops/s peak):

[Book15] f90/bug% gfc -Ofast timing/matmul_sys_8jd.f90
[Book15] f90/bug% a.out
 Size Loops  Matmul   dgemm Matmul  Matmul
  fixed explicitassumed  variable
explicit

=
220   0.969   0.104   0.360   0.368
420   5.821   0.774   1.381   1.049
820   5.415   2.970   2.316   2.342
   1620   6.455   4.917   2.738   3.225
   3220   7.332   5.964   2.893   4.117
   64 30757   5.565   7.277   2.785   3.830
  128  3829   4.790   7.982   2.981   4.384
  256   477   4.674   8.375   3.077   4.675
  51259   4.797   8.200   3.156   4.786
 1024 7   3.967   8.370   2.896   4.050
 2048 1   3.693   8.414   2.804   3.650
[Book15] f90/bug% gfc -Ofast -mavx timing/matmul_sys_8jd.f90
[Book15] f90/bug% a.out
 Size Loops  Matmul   dgemm Matmul  Matmul
  fixed explicitassumed  variable
explicit

=
220   0.956   0.106   0.372   0.469
420   7.805   0.715   1.334   1.462
820   7.520   3.222   2.292   3.482
   1620   3.001   6.406   2.671   4.917
   3220   8.886   8.530   2.900   6.136
   64 30757  10.203  10.998   2.677   6.770
  128  3829   6.742  13.367   2.831   6.774
  256   477   6.435  13.979   2.906   6.049
  51259   6.592  15.041   2.991   6.273
 1024 7   5.247  14.639   2.775   4.922
 2048 1   4.309  13.976   2.739   4.176

Note a problem when 16x16 matrices are inlined with -mavx (I'll investigate and
file a PR for it).

[Bug middle-end/68595] [6 regression] ice in const_vector_mask_from_tree at expr.c:11455

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||alan.hayward at arm dot com
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #3 from Richard Biener  ---
(gdb) p debug_tree (elt)
  constant -2>
(gdb) p debug_generic_expr (exp)
{ 0, -2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }

comes from BIT_NOT_EXPR on { -1, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1 }

from simplifying

mask__25.20_271 = ~{ -1, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1 };

where the vectorizer generated



  mask__21.18_69 = vect_vec_iv_.17_66 != vect_cst__68;
  _21 = c.2_33 != 0;
  mask__23.19_72 = mask__21.18_69 | vect_cst__71;

and unrolling exposes a lot of constants to go forward.  The vector_cst looks
suspicious:

  _44 = b.3_32 != 0;
  _70 = () _44;
  vect_cst__71 = {_70, _70, _70, _70, _70, _70, _70, _70, _70, _70, _70, _70,
_70, _70, _70, _70};

because the vector boolean result is clearly _not_ a scalar comparison
result just casted but it needs to cater for true to become -1.

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #16 from Markus Trippelsdorf  ---
I looked at some of the kernel warnings and they were legitimate.
The embedded guys, who care much about binary size, would benefit most
if these issues were fixed.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[rdiezmail-gcc at yahoo dot de]

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

--- Comment #2 from R. Diez  ---
A setting like LIBSTDCXX_EMERGENCY_EH_POOL_SIZE sounds good. However, an
environment variable will not help me, it has to be a configuration option when
building the toolchain. I am writing embedded firmware with newlib, and, as far
as I know, there are no environment variables on start-up. You can set them in
main() with setenv(), but that's too late, the emergency pool has already been
initialised by then.

I would also like to specify a size of 0 to disable it completely. I need to
save as much memory as I can. After all, even if the emergency pool is huge, it
can still  happen that it is not enough, so the exception-handling code must
already deal with that case that the pool has no room left, maybe with panic().
In my case, if there is no malloc() space available to throw an exception, the
system is not working properly anyway.

By the way, setting the size of some global emergency pool on start-up seems
like a hack. You do not really know how big it should be, that depends for
example on the number of threads you have, which is not known upfront.
Reserving space per thread can help, but that's then a big waste if you have
many threads. I suggest a special case in the unwind logic that can throw a
particular out-of-memory exception like std::bad_alloc without allocating
memory with malloc().

Whatever happened to the sensible way of allocating the exception on the stack
and copying it up the stack every time the stack unwinds? I don't think that
optimising the performance of the error-handling case is a high priority, at
least for most applications. At least for embedded applications, allocating
with malloc() when you throw is far worse. That prevents, for example, throwing
in interrupt context, where malloc() is often not available.

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[andi-gcc at firstfloor dot org]

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

--- Comment #17 from Andi Kleen  ---
There were a few false or useless ones (e.g. related to macros and specific
build configs).  I didn't look through them all, but various were semi
legitimate, but also very minor (small) so fixing it won't help much. I think
one or two of the ones I looked at may have been real bugs.

I still think the warning should not be in -Wall. thousand+ warnings in real
projects is just not acceptable.

[Bug tree-optimization/46032] openmp inhibits loop vectorization

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||missed-optimization, patch
   Severity|major   |enhancement

--- Comment #22 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03448.html

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[trippels at gcc dot gnu.org]

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

--- Comment #18 from Markus Trippelsdorf  ---
Here is an example:
...
static const struct pt_regs_offset x86_32_regoffset_table[] = {
REG_OFFSET_NAME_32("%ax",   eax),
REG_OFFSET_NAME_32("%cx",   ecx),
REG_OFFSET_NAME_32("%dx",   edx),
REG_OFFSET_NAME_32("%bx",   ebx),
REG_OFFSET_NAME_32("$stack",esp),   /* Stack address instead of %sp
*/
REG_OFFSET_NAME_32("%bp",   ebp),
REG_OFFSET_NAME_32("%si",   esi),
REG_OFFSET_NAME_32("%di",   edi),
REG_OFFSET_END,
};

static const struct pt_regs_offset x86_64_regoffset_table[] = {
REG_OFFSET_NAME_64("%ax",   rax),
REG_OFFSET_NAME_64("%dx",   rdx),
REG_OFFSET_NAME_64("%cx",   rcx),
REG_OFFSET_NAME_64("%bx",   rbx),
REG_OFFSET_NAME_64("%si",   rsi),
REG_OFFSET_NAME_64("%di",   rdi),
REG_OFFSET_NAME_64("%bp",   rbp),
REG_OFFSET_NAME_64("%sp",   rsp),
REG_OFFSET_NAME_64("%r8",   r8),
REG_OFFSET_NAME_64("%r9",   r9),
REG_OFFSET_NAME_64("%r10",  r10),
REG_OFFSET_NAME_64("%r11",  r11),
REG_OFFSET_NAME_64("%r12",  r12),
REG_OFFSET_NAME_64("%r13",  r13),
REG_OFFSET_NAME_64("%r14",  r14),
REG_OFFSET_NAME_64("%r15",  r15),
REG_OFFSET_END,
};

/* TODO: switching by dwarf address size */
#ifdef __x86_64__
#define regoffset_table x86_64_regoffset_table
#else
#define regoffset_table x86_32_regoffset_table
#endif
...
//use regoffset_table

[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|5.3 |5.4

[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
I'll wait for after GCC 5.3 for the backport.

[Bug target/68617] arm ice output_operand: invalid %-code for -march=armv6k + thumb

[chrbr at gcc dot gnu.org]

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

--- Comment #2 from chrbr at gcc dot gnu.org ---
unaligned_access flag now depend on TARGET_32BIT, which is sensitive to the
attribute target.
Should be made Save in arm.opt and handled in override_options_internal. But
this is still not enough to make the test pass.

[Bug other/68618] New: interrupt fails on ICE in some call cases with miamcu with -O2/3

[vaalfreja at gmail dot com]

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

Bug ID: 68618
   Summary: interrupt fails on ICE in some call cases with miamcu
with -O2/3
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vaalfreja at gmail dot com
  Target Milestone: ---

Reproduce:
bash-4.2$ cat ../i2.c
struct interrupt_frame;

void (*foo1[1])(int a, int b);

void foo2(int c)
{
foo1[c](1,2);
}

static __attribute__((interrupt)) void my_isr(struct interrupt_frame *frame)
{
int c;
foo2(c);
}


int main()
{
}
bash-4.2$ ./../gcc_trunk_64bit_old_interrupt/install/bin/gcc -m32 -miamcu -O3
-DU ../i2.c
../i2.c: In function ‘foo2’:
../i2.c:8:1: error: unable to find a register to spill
 }
 ^
../i2.c:8:1: error: this is the insn:
(call_insn/j 10 19 11 2 (call (mem:QI (reg/f:SI 91 [90]) [0 *_3 S1 A8])
(const_int 0 [0])) ../i2.c:7 662 {*sibcall}
 (expr_list:REG_DEAD (reg/f:SI 91 [90])
(expr_list:REG_DEAD (reg:SI 1 dx)
(expr_list:REG_DEAD (reg:SI 0 ax)
(expr_list:REG_CALL_DECL (nil)
(nil)
(expr_list:SI (use (reg:SI 0 ax))
(expr_list:SI (use (reg:SI 1 dx))
(nil
../i2.c:8:1: internal compiler error: in assign_by_spills, at
lra-assigns.c:1431
0xa6f4a8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
.././../TRUNK/gcc6/gcc/rtl-error.c:109
0x970019 assign_by_spills
.././../TRUNK/gcc6/gcc/lra-assigns.c:1431
0x970a53 lra_assign()
.././../TRUNK/gcc6/gcc/lra-assigns.c:1606
0x96c459 lra(_IO_FILE*)
.././../TRUNK/gcc6/gcc/lra.c:2344
0x922919 do_reload
.././../TRUNK/gcc6/gcc/ira.c:5392
0x922919 execute
.././../TRUNK/gcc6/gcc/ira.c:5563
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

This bug can be fixed with:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index cb6f8f4..b1523e0 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -5339,8 +5339,8 @@ ix86_set_current_function (tree fndecl)
 reinit_regs ();
   /* AX register is only preserved if there are no caller-saved
  registers.  */
-  else if (cfun->machine->no_caller_saved_registers
-  == call_used_regs[AX_REG])
+  else if ((cfun->machine->no_caller_saved_registers
+  == call_used_regs[AX_REG]) || TARGET_IAMCU)
 reinit_regs ();
 }

However, unconditional calling of reinit_regs is bad.

[Bug c/68619] New: error: loop with header 6 not in loop tree

[dcb314 at hotmail dot com]

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

Bug ID: 68619
   Summary: error: loop with header 6 not in loop tree
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

$ ../results/bin/gcc -O2 -c -w bug252.c
qwe_0.c: In function ‘func_6’:
qwe_0.c:195:10: error: loop with header 6 not in loop tree

qwe_0.c:195:10: internal compiler error: in verify_loop_structure, at
cfgloop.c:1639
0x7395d4 verify_loop_structure()
../../src/trunk/gcc/cfgloop.c:1639
0x9ec0a4 checking_verify_loop_structure
../../src/trunk/gcc/cfgloop.h:324
0x9ec0a4 loop_optimizer_init(unsigned int)
../../src/trunk/gcc/loop-init.c:106
0xd86fc4 init_reassoc
../../src/trunk/gcc/tree-ssa-reassoc.c:5049

Compiler is gcc trunk, dated 20151129.

[Bug other/68616] miscompilation in multi-threaded code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
arrive_and_wait is known to not clobber ptr and thus GCC can happily CSE ptr
over the call.  IPA reference computes this for non-address-taken global
statics.

It's hard to "fix" IPA reference here because it nowadays operates on the
IPA-ref list and IIRC there are no "may-ref-all" things we could inject here
for atomics.

OTOH IIRC nothing was "designed" to handle synchronization points but instead
the idea was to rely on aliasing barriers which as can be seen here is not
fully sufficient.  That said, do we have sth like a "barrier" detection?
Because a single atomic load or store certainly isn't one(?).

AFAICS only globals that don't have their address taken (thus statics without
LTO and some more with LTO) have this issue.  IPA-PTA might also compute
"interesting" mod/ref info if it were to handle the atomics in some way
(I never committed a patch that tried to improve things there because of
doubts of semantics...)

[Bug middle-end/68616] miscompilation in multi-threaded code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-30
  Component|other   |middle-end
 Ever confirmed|0   |1

[Bug c/68619] [6 Regression] error: loop with header 6 not in loop tree

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-30
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|error: loop with header 6   |[6 Regression] error: loop
   |not in loop tree|with header 6 not in loop
   ||tree
 Ever confirmed|0   |1

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

[Bug c/68619] [6 Regression] error: loop with header 6 not in loop tree

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

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

[Bug tree-optimization/68474] [6 Regression] ICE: in get_no_error_domain, at tree-call-cdce.c:699 with -funsafe-math-optimizations

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Testing a patch.

[Bug ada/68590] [6 Regression] FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check"

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
> Instead it originates from
> 
> (for cmp (ge le)
> 
>  (simplify  
> 
>   (cmp @0 @0)   
> 
>   (eq @0 @0)))
> 
> hmm.  Yes, we use @0 twice here.  But we also use a matching capture, sth
> we (unfortunately) don't record (yet).  We _do_ have a load that we
> compare so avoiding the redundant computation when we duplicate an
> operand makes sense even when there is no side-effect present (that was
> the objective of the change).  Simplifying
> 
>  (le  s1->length s1->length)
> 
> to
> 
>  (eq save_expr length> save_expr length>)
> 
> looks like a win.

I beg to differ, s1->length has no TREE_SIDE_EFFECTS so it's a pessimization.
Having no TREE_SIDE_EFFECTS *precisely* means that you are free to reuse the
object as-is in the same expression any number of times.

> Now simplifying that down to
> 
>  (save_expr length>, 1)
> 
> is "correct" as well.  And we can't just drop random save_exprs here because
> of the comment in save_expr:
> 
>   /* This expression might be placed ahead of a jump to ensure that the
>  value was computed on both sides of the jump.  So make sure it isn't
>  eliminated as dead.  */
>   TREE_SIDE_EFFECTS (t) = 1;
> 
> not sure what this is refering to... it sounds confusing - if it was placed
> there and did not have side-effects it better should have a user via a
> data dependence.

Having TREE_SIDE_EFFECTS on SAVE_EXPRs is required for GENERIC folding (of
course not if your ultimate objective is to kill GENERIC folding...) because if
you have something like:

  COND_EXPR 

and want to turn it into:

  COND_EXPR 

the SAVE_EXPR  will create a variable that will be initialized once, in
other words in only one of the arms and you don't know which one at compile
time.  So you need to create a COMPOUND_EXPR:

  COMPOUND_EXPR , COND_EXPR >

to make sure it is evaluated ahead of the branch and TREE_SIDE_EFFECTS is
required to keep the first operand.

I'll note that the problematic change comes with neither a testcase nor a
comment (and the original comment about TREE_SIDE_EFFECT is even still there)
so it's little hard to understand where it comes from...

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

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

  Attachment #36870|0   |1
is obsolete||

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Created attachment 36874
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36874=edit
proposed patch v2

Sorry, the previous version caused an uninitialised warning-turned-error
during bootstrap.

[Bug fortran/68600] Inlined MATMUL is too slow.

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #7 from Joost VandeVondele  
---
(In reply to Dominique d'Humieres from comment #6)
> Note a problem when 16x16 matrices are inlined with -mavx (I'll investigate
> and file a PR for it).

that's a good find!

I ran locally on haswell, and find these numbers, including openblas, and
libxsmm. 

./a.out
 Size Loops  Matmul   newmatmul dgemm-like 
dgemm
  fixed explicit  internal  libxsmm 
openblas

=
220   1.562   0.107   0.104   0.139
420   6.781   0.779   1.012   0.887
820   7.424   3.360   6.150   4.732
   1620   2.954   7.290  14.421  11.527
   3220  10.401  10.251  24.396  18.071
   64 30757  12.696  14.196  27.385  24.547
  128  3829   8.646  17.684  31.460  31.530
  256   477   7.834  19.123  37.457  37.471
  51259   8.064  19.473  40.738  40.755
 1024 7   8.334  19.475  40.931  41.112
 2048 1   3.042  19.157  41.225  41.279


so the 'newmatmul' code gets about 50% of peak. Inlined matmul is good up to
size 8/16, 16-64 libxsmm wins, >64 openblas is better. For the small sizes it
is mostly related to call eliminated overhead, I think.

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
This then requires somebody familiar with the PE-COFF symbol
visibility/overriding to adjust the mingw targetm.binds_local_p or arrange to
adjust decl_binds_to_current_def_p for mingw.

[Bug target/28115] possible bug in recog_memoized usage in rs6000.c??

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Nov 30 09:43:55 2015
New Revision: 231059

URL: https://gcc.gnu.org/viewcvs?rev=231059=gcc=rev
Log:
PR target/28115
* config/sparc/sparc.c (supersparc_adjust_cost): Fix thinko.
(sparc_adjust_cost): Add missing space.

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

[Bug driver/68463] Offloading fails when some objects are compiled with LTO and some without

[iverbin at gcc dot gnu.org]

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

iverbin at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-30
 CC||bernds at gcc dot gnu.org,
   ||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from iverbin at gcc dot gnu.org ---
> I presume the same issue exists for GCC 5.
Yes.

It seems that we can fix this issue by passing a new option to lto-wrapper,
which will contain a list of object files with offload (or a filename with the
list).  It also will allow to remove some hacky code from lto-wrapper, like
this
comparison: if (strncmp (argv[i], "-fresolution=", sizeof ("-fresolution=") ...

E.g., if there are 4 objects:
* obj1.o - non-LTO, offload;
* obj2.o - LTO, non-offload;
* obj3.o - non-LTO, non-offload;
* obj4.o - LTO, offload;

then linker plugin will claim only obj2.o and obj4.o, as it was intended.  So
it
will call lto-wrapper by passing obj2.o and obj4.o as argv.  But additionally
linker plugin will pass something like: -foffload_objects="obj1.o,obj4.o".
lto-wrapper will perform LTO on objects from argv as usually, and additionally
compile target images using offload IR from obj1.o and obj4.o.
The tables also should match, because host table will consist of: pieces from
all LTO objects with offload + pieces from non-LTO objects with offload.  Just
need to reorder offload_objects correspondingly before passing them to the
targer compiler (obj4.o,obj1.o).
However in this case both obj1.o and obj4.o cannot be surrounded by
crtoffload{begin,end}.o, because lto-wrapper cannot place crtoffload* before or
after obj1.o, because it is unclaimed.  But I guess this can be fixed by
something like linker script, which will place sections from crtoffload* at the
begin/end of the final joint section.

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

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Created attachment 36870
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36870=edit
proposed patch

Here's the patch I'm testing.  Adding the cost of the demotion
prevents vectorisation in the original testcase, but it vectorises
successfully with -fvect-cost-model=unlimited.  (We didn't
vectorise before the combined_fn series either.)

The patch also includes an SLP testcase.

[Bug fortran/59298] ICE when initialising PARAMETER array of derived-type (containing an array) using array constructor

[adam at aphirst dot karoo.co.uk]

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

--- Comment #6 from Adam Hirst  ---
As with another bug I keep in my Bookmarks, I just decided to check this again
and it seems that in 5.2.0 we're still getting the same behaviour.

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-5.2.0/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --with-default-libstdcxx-abi=gcc4-compatible
Thread model: posix
gcc version 5.2.0 (GCC)

[Bug tree-optimization/68379] [6 Regression] BB vectorization: definition in block 13 follows the use for SSA_NAME

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
The PR68614 testcase

int a, b[3], c[3][5];

void
fn1 ()
{
  int e;
  for (a = 2; a >= 0; a--)
for (e = 0; e < 4; e++)
  c[a][e] = b[a];
}

exposes the same issue in basic-block vectorization.  We fully unroll the
nest leaving a SLP group of size 3 for the b loads where each individual
load is used in a different SLP target (so the load isn't really grouped
which shows an opportunity for a cheap fix improving code-gen as well).

[Bug tree-optimization/68592] [6 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1403 with -fprofile-generate

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r230956.

[Bug target/68617] New: arm ice output_operand: invalid %-code for -march=armv6k + thumb

[chrbr at gcc dot gnu.org]

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

Bug ID: 68617
   Summary: arm ice output_operand: invalid %-code for
-march=armv6k + thumb
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrbr at gcc dot gnu.org
  Target Milestone: ---