[Bug target/68701] [4.9/5/6 Regression] "gcc -m32 -finstrument-functions -ffixed-ebp" produces internal compiler error

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #6)
> > Yeah.  Or if neither -m{,no-}accumulate-outgoing-args is specified, perhaps
> > turn that on automatically instead if -ffixed-ebp and only error out if
> > explicit -mno-accumulate-outgoing-args?
> 
> IMO, this is a good idea.

Perhaps a warning should be emitted when switching
MASK_ACCUMULATE_OUTGOING_ARGS option automatically, again as is already the
case with stack probe (i386.c, around line 5294).

[Bug c++/68782] [6 regression] bad reference member formed with constexpr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/68785] [6 Regression] valgrind reports issues with folding on x86_64

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
I believe this can happen when native_encode_expr encodes less than the
requested number of bytes (thus the program invokes undefined behavior).  In
this case
we read 4 bytes from "" (an empty string).

I'm placing some asserts to see what the program does and where.

[Bug ada/66526] Use of uninitialized variables in g-expect.adb

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
Summary|Use of uninitialized|Use of uninitialized
   |variable|variables in g-expect.adb

--- Comment #2 from Eric Botcazou  ---
The warnings are still present on mainline.

[Bug target/68701] [4.9/5/6 Regression] "gcc -m32 -finstrument-functions -ffixed-ebp" produces internal compiler error

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Can I leave this PR to you?

[Bug tree-optimization/68775] spec2006 test case 465.tonto fails with the gcc 6.0 fortran compiler

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Can you try to bisect to an affected source file (just use -fno-tree-vectorize
on all but one) and there to whether it is basic-block or loop vectorization
(-fno-tree-loop-vectorize / -fno-tree-slp-vectorize) and specific
loop/basic-block with -fdbg-cnt=vect_slp:N or -fdbg-cnt=vect_loop:N?

Note that it seems that tonto also fails (since forever) with AVX2 on x86_64.

[Bug middle-end/68785] [6 Regression] valgrind reports issues with folding on x86_64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-08
 CC||rguenth at gcc dot gnu.org
  Component|target  |middle-end
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
So it folds

# VUSE <.MEM_30>
# rhs access alignment 32+0
_92 = MEM[(u32 *)path_7];

but path_7 is know to point to "".  location of the stmt above is
drivers/acpi/acpica/nsaccess.c:562:36  I guess that's

  *(u32 *)(void *)(_name) = *(u32 *)(void *)(path);

eventually jump-threaded from the

 if (!pathname) {



  num_segments = 0;
  this_node = acpi_gbl_root_node;
  path = "";

case .  Yeah, quite obvious.

We avoid doing the work to zero the "undefined" area given the program does
not invoke undefined behavior only if the uninitialized bits of the result
are not used (like masked out or so).

One could silence valgrind with some annotation I guess.

Patch to make it trigger as ICE:

Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c   (revision 231355)
+++ gcc/gimple-fold.c   (working copy)
@@ -5495,9 +5492,13 @@ fold_ctor_reference (tree type, tree cto
   && size <= MAX_BITSIZE_MODE_ANY_MODE)
 {
   unsigned char buf[MAX_BITSIZE_MODE_ANY_MODE / BITS_PER_UNIT];
-  if (native_encode_expr (ctor, buf, size / BITS_PER_UNIT,
- offset / BITS_PER_UNIT) > 0)
-   return native_interpret_expr (type, buf, size / BITS_PER_UNIT);
+  int elen;
+  if ((elen = native_encode_expr (ctor, buf, size / BITS_PER_UNIT,
+ offset / BITS_PER_UNIT)) > 0)
+   {
+ gcc_assert (elen >= size / BITS_PER_UNIT);
+ return native_interpret_expr (type, buf, size / BITS_PER_UNIT);
+   }
 }
   if (TREE_CODE (ctor) == CONSTRUCTOR)
 {

[Bug tree-optimization/68775] spec2006 test case 465.tonto fails with the gcc 6.0 fortran compiler

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #2 from Igor Zamyatin  ---

> 
> Note that it seems that tonto also fails (since forever) with AVX2 on x86_64.

Hmmm, at what optset are you seeing the failure?

[Bug tree-optimization/68695] [6 Regression] Performance regression related to ssa patch / ifcvt

[krebbel at gcc dot gnu.org]

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

--- Comment #16 from Andreas Krebbel  ---
(In reply to Dominik Vogt from comment #15)
> Providing that macro does fix the problem:
> 
> #define PROMOTE_MODE(MODE,UNSIGNEDP,TYPE) \
>   if (GET_MODE_CLASS (MODE) == MODE_INT   \
>   && GET_MODE_SIZE (MODE) < (TARGET_ZARCH ? 8 : 4)) \
> (MODE) = TARGET_ZARCH ? DImode : SImode;
> 
> But is it a good idea to define it in the first place?

We do not define this for S/390 since we have plenty of instructions able to
deal with smaller modes in registers. Defining this would prevent GCC from make
use of these.

Another problem is that on S/390 we more often require explicit
sign/zero-extend instructions to perform promotions.

In the case above one value is promoted to adhere to the ABI while the other
isn't to make best use of the instruction set. We could try to do some
measurements with the PROMOTE_MODE macro defined but I expect regressions with
that. We probably would need something to estimate the cost of adding
promotions.

[Bug ada/65102] gnat-style.texi warning from including fdl.texi

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #7 from Eric Botcazou  ---
> On the machine where I do my ada builds atm, I don't see this warning. I
> don't see any changes in the relevant source files since filing this issue,
> so I'm not sure why it has disappeared for me.

Indeed, navigating the info file on mainline still shows the issue.  Can you
apply the patch?  It was approved by Gerald (modulo a minor point) and Arno.

[Bug ada/65102] gnat-style.texi warning from including fdl.texi

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  ---
> Can you paste the gcc-patches ml link that contains the approval? I haven't
> seen it.

You replied to it though, see comment #3.  No need to ask again for approval
when someone said "Okay" and just requested an additional comment.

[Bug tree-optimization/68787] New: fipa-pta to interpret restrict

[vries at gcc dot gnu.org]

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

Bug ID: 68787
   Summary: fipa-pta to interpret restrict
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider this test-case:
...
static void __attribute__((noinline, noclone))
bar (int *a, int * b)
{
  *a = 1;
  *b = 2;
  *a = *a + 1;
}

void
foo (int *__restrict__ a, int *__restrict__ b)
{
  bar (a, b);
}
...

This example is not optimized with -fipa-pta. The interprocedural points-to
analysis ignores restrict atm.

[Bug ada/65102] gnat-style.texi warning from including fdl.texi

[vries at gcc dot gnu.org]

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

--- Comment #8 from vries at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #7)
> It was approved by Gerald (modulo a minor point).

Can you paste the gcc-patches ml link that contains the approval? I haven't
seen it.

[Bug sanitizer/68777] [UBSAN] Spurious warning with C++11 lambdas ("member call on null pointer")

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Yes.  My gcc-5 branch was out of date.

Thus fixed.

[Bug tree-optimization/68640] foo restrict propagated to foo._omp_fn.0

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org

--- Comment #8 from vries at gcc dot gnu.org ---
patch: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00820.html

[Bug tree-optimization/68695] [6 Regression] Performance regression related to ssa patch / ifcvt

[vogt at linux dot vnet.ibm.com]

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

--- Comment #17 from Dominik Vogt  ---
Lookin gat some other test program I've immediately seen cases that introduce
sign extension instructions in code that worked without them before.

[Bug target/68701] [4.9/5/6 Regression] "gcc -m32 -finstrument-functions -ffixed-ebp" produces internal compiler error

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Uroš Bizjak from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > As main needs dynamic stack realignment, I wonder if we just shouldn't error
> > out on trying to compile it with -ffixed-ebp.
> 
> It is still possible to compile with -maccumulate-outgoing-args. Perhaps we
> can error out with the advice that -ffixed-ebp requires -m-o-a option, as is
> already the case with stack probing?

Yeah.  Or if neither -m{,no-}accumulate-outgoing-args is specified, perhaps
turn that on automatically instead if -ffixed-ebp and only error out if
explicit -mno-accumulate-outgoing-args?

[Bug tree-optimization/68786] New: Aligned masked store is generated for unaligned pointer

[ienkovich at gcc dot gnu.org]

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

Bug ID: 68786
   Summary: Aligned masked store is generated for unaligned
pointer
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ienkovich at gcc dot gnu.org
  Target Milestone: ---

Here is a testcase:

double *a;
int b;

void
test (void)
{
  for (; b; b++)
if (b < 7)
  a[b] = 1.0;
}

Produced assembler for that loop when compiled for AVX-512:

>gcc  -O2 -ftree-vectorize -march=skylake-avx512 small.i -S

.L4:
vpcmpd  $2, %zmm2, %zmm0, %k1
addl$1, %r8d
vpaddd  %zmm3, %zmm0, %zmm0
vmovupd %zmm1, (%rsi){%k1}
kshiftrw$8, %k1, %k1
vmovapd %zmm1, 64(%rsi){%k1}
subq$-128, %rsi
cmpl%edx, %r8d
jb  .L4

We have two store using the same base.  One of them is unaligned and another
one is aligned.

The difference comes from GIMPLE.  Here is a vectorized loop:

  :
  # vect_vec_iv_.11_71 = PHI 
  # ivtmp.26_87 = PHI <0(5), ivtmp.26_6(6)>
  # ivtmp.28_7 = PHI 
  vectp.15_82 = (vector(8) double *) ivtmp.28_7;
  vect_vec_iv_.11_72 = vect_vec_iv_.11_71 + { 16, 16, 16, 16, 16, 16, 16, 16,
16, 16, 16, 16, 16, 16, 16, 16 };
  mask__24.12_74 = vect_vec_iv_.11_71 <= { 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6,
6, 6, 6, 6 };
  mask_patt_28.14_76 = [vec_unpack_lo_expr] mask__24.12_74;
  mask_patt_28.14_77 = [vec_unpack_hi_expr] mask__24.12_74;
  MASK_STORE (vectp.15_82, 0B, mask_patt_28.14_76, { 1.0e+0, 1.0e+0, 1.0e+0,
1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0 });
  _25 = ivtmp.28_7 + 64;
  _88 = (vector(8) double *) _25;
  MASK_STORE (_88, 0B, mask_patt_28.14_77, { 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0,
1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0 });
  ivtmp.26_6 = ivtmp.26_87 + 1;
  ivtmp.28_8 = ivtmp.28_7 + 128;
  if (ivtmp.26_6 < bnd.8_31)
goto ;

Pointers used for masked stores have different SSA_NAME_PTR_INFO

For vectp.15_82 we have

{pt = {anything = 0, nonlocal = 1, escaped = 1, ipa_escaped = 0, null = 0,
vars_contains_nonlocal = 0, vars_contains_escaped = 0,
vars_contains_escaped_heap = 0, vars = 0x77c13160}, align = 8, misalign =
0}

For _88 we have

{pt = {anything = 0, nonlocal = 1, escaped = 1, ipa_escaped = 0, null = 0,
vars_contains_nonlocal = 0, vars_contains_escaped = 0,
vars_contains_escaped_heap = 0, vars = 0x77c13160}, align = 0, misalign =
0}

Zero alignment here for _88 causes TYPE_ALIGN to be used for the second
MASK_STORE.  TYPE_ALIGN for vector types is its size and therefore we get
incorrect aligned memory access.

[Bug target/68785] New: [6 Regression] valgrind reports issues with folding on x86_64

[trippels at gcc dot gnu.org]

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

Bug ID: 68785
   Summary: [6 Regression] valgrind reports issues with folding on
x86_64
   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
  Target Milestone: ---
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu

I configured gcc with --enable-valgrind-annotations and built the 
Linux kernel under valgrind on a compile farm machine on x86_64.

The following issue popped up a few times:

==40045== Conditional jump or move depends on uninitialised value(s)
==40045==at 0xD6F632: get_int_cst_ext_nunits(tree_node*,
generic_wide_int const&) (wide-int.h:795)
==40045==by 0xD90B52: wide_int_to_tree(tree_node*,
generic_wide_int const&) (tree.c:1432)
==40045==by 0x808EB4: native_interpret_expr(tree_node*, unsigned char
const*, int) (fold-const.c:7305)
==40045==by 0x871C03: fold_ctor_reference(tree_node*, tree_node*, unsigned
long, unsigned long, tree_node*) (gimple-fold.c:5500)
==40045==by 0x8721C9: fold_const_aggregate_ref_1(tree_node*, tree_node*
(*)(tree_node*)) (gimple-fold.c:5616)
==40045==by 0x87311F: gimple_fold_stmt_to_constant_1(gimple*, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*)) (gimple-fold.c:5095)
==40045==by 0xBEE645: evaluate_stmt(gimple*) (tree-ssa-ccp.c:1214)
==40045==by 0xBEFA0A: visit_assignment(gimple*, tree_node**)
(tree-ssa-ccp.c:2290)
==40045==by 0xBEFAD7: ccp_visit_stmt(gimple*, edge_def**, tree_node**)
(tree-ssa-ccp.c:2368)
==40045==by 0xC7E82C: simulate_stmt(gimple*) (tree-ssa-propagate.c:331)
==40045==by 0xC80385: ssa_propagate(ssa_prop_result (*)(gimple*,
edge_def**, tree_node**), ssa_prop_result (*)(gphi*))
(tree-ssa-propagate.c:509)
==40045==by 0xBE83E4: (anonymous namespace)::pass_ccp::execute(function*)
(tree-ssa-ccp.c:2408)
==40045== 
==40045== Conditional jump or move depends on uninitialised value(s)
==40045==at 0xD90EEB: wide_int_to_tree(tree_node*,
generic_wide_int const&) (tree.c:1473)
==40045==by 0x808EB4: native_interpret_expr(tree_node*, unsigned char
const*, int) (fold-const.c:7305)
==40045==by 0x871C03: fold_ctor_reference(tree_node*, tree_node*, unsigned
long, unsigned long, tree_node*) (gimple-fold.c:5500)
==40045==by 0x8721C9: fold_const_aggregate_ref_1(tree_node*, tree_node*
(*)(tree_node*)) (gimple-fold.c:5616)
==40045==by 0x87311F: gimple_fold_stmt_to_constant_1(gimple*, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*)) (gimple-fold.c:5095)
==40045==by 0xBEE645: evaluate_stmt(gimple*) (tree-ssa-ccp.c:1214)
==40045==by 0xBEFA0A: visit_assignment(gimple*, tree_node**)
(tree-ssa-ccp.c:2290)
==40045==by 0xBEFAD7: ccp_visit_stmt(gimple*, edge_def**, tree_node**)
(tree-ssa-ccp.c:2368)
==40045==by 0xC7E82C: simulate_stmt(gimple*) (tree-ssa-propagate.c:331)
==40045==by 0xC80385: ssa_propagate(ssa_prop_result (*)(gimple*,
edge_def**, tree_node**), ssa_prop_result (*)(gphi*))
(tree-ssa-propagate.c:509)
==40045==by 0xBE83E4: (anonymous namespace)::pass_ccp::execute(function*)
(tree-ssa-ccp.c:2408)
==40045==by 0xA10CAC: execute_one_pass(opt_pass*) (passes.c:2336)
==40045== 
==40045== Conditional jump or move depends on uninitialised value(s)
==40045==at 0xD90E67: wide_int_to_tree(tree_node*,
generic_wide_int const&) (tree.c:1492)
==40045==by 0x808EB4: native_interpret_expr(tree_node*, unsigned char
const*, int) (fold-const.c:7305)
==40045==by 0x871C03: fold_ctor_reference(tree_node*, tree_node*, unsigned
long, unsigned long, tree_node*) (gimple-fold.c:5500)
==40045==by 0x8721C9: fold_const_aggregate_ref_1(tree_node*, tree_node*
(*)(tree_node*)) (gimple-fold.c:5616)
==40045==by 0x87311F: gimple_fold_stmt_to_constant_1(gimple*, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*)) (gimple-fold.c:5095)
==40045==by 0xBEE645: evaluate_stmt(gimple*) (tree-ssa-ccp.c:1214)
==40045==by 0xBEFA0A: visit_assignment(gimple*, tree_node**)
(tree-ssa-ccp.c:2290)
==40045==by 0xBEFAD7: ccp_visit_stmt(gimple*, edge_def**, tree_node**)
(tree-ssa-ccp.c:2368)
==40045==by 0xC7E82C: simulate_stmt(gimple*) (tree-ssa-propagate.c:331)
==40045==by 0xC80385: ssa_propagate(ssa_prop_result (*)(gimple*,
edge_def**, tree_node**), ssa_prop_result (*)(gphi*))
(tree-ssa-propagate.c:509)
==40045==by 0xBE83E4: (anonymous namespace)::pass_ccp::execute(function*)
(tree-ssa-ccp.c:2408)
==40045==by 0xA10CAC: execute_one_pass(opt_pass*) (passes.c:2336)
==40045== 
==40045== Conditional jump or move depends on uninitialised value(s)
==40045==at 0xD90D13: wide_int_to_tree(tree_node*,

[Bug target/68701] [4.9/5/6 Regression] "gcc -m32 -finstrument-functions -ffixed-ebp" produces internal compiler error

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Uroš Bizjak from comment #4)
> > (In reply to Jakub Jelinek from comment #3)
> > > As main needs dynamic stack realignment, I wonder if we just shouldn't 
> > > error
> > > out on trying to compile it with -ffixed-ebp.
> > 
> > It is still possible to compile with -maccumulate-outgoing-args. Perhaps we
> > can error out with the advice that -ffixed-ebp requires -m-o-a option, as is
> > already the case with stack probing?
> 
> Yeah.  Or if neither -m{,no-}accumulate-outgoing-args is specified, perhaps
> turn that on automatically instead if -ffixed-ebp and only error out if
> explicit -mno-accumulate-outgoing-args?

IMO, this is a good idea.

[Bug target/68785] [6 Regression] valgrind reports issues with folding on x86_64

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Created attachment 36952
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36952=edit
unreduced testcase

Here's a reproducer:

trippels@CFARM-IUT-TLSE3 linux % valgrind --track-origins=yes
--trace-children=yes /home/trippels/gcc_test/usr/local/bin/gcc -O3 -c
nsaccess.i
...
==67322== Conditional jump or move depends on uninitialised value(s)
==67322==at 0xD6F632: get_int_cst_ext_nunits(tree_node*,
generic_wide_int const&) (wide-int.h:795)
==67322==by 0xD90B52: wide_int_to_tree(tree_node*,
generic_wide_int const&) (tree.c:1432)
==67322==by 0x808EB4: native_interpret_expr(tree_node*, unsigned char
const*, int) (fold-const.c:7305)
==67322==by 0x871C03: fold_ctor_reference(tree_node*, tree_node*, unsigned
long, unsigned long, tree_node*) (gimple-fold.c:5500)
==67322==by 0x8721C9: fold_const_aggregate_ref_1(tree_node*, tree_node*
(*)(tree_node*)) (gimple-fold.c:5616)
==67322==by 0x87311F: gimple_fold_stmt_to_constant_1(gimple*, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*)) (gimple-fold.c:5095)
==67322==by 0xBEE645: evaluate_stmt(gimple*) (tree-ssa-ccp.c:1214)
==67322==by 0xBEFA0A: visit_assignment(gimple*, tree_node**)
(tree-ssa-ccp.c:2290)
==67322==by 0xBEFAD7: ccp_visit_stmt(gimple*, edge_def**, tree_node**)
(tree-ssa-ccp.c:2368)
==67322==by 0xC7E82C: simulate_stmt(gimple*) (tree-ssa-propagate.c:331)
==67322==by 0xC80385: ssa_propagate(ssa_prop_result (*)(gimple*,
edge_def**, tree_node**), ssa_prop_result (*)(gphi*))
(tree-ssa-propagate.c:509)
==67322==by 0xBE83E4: (anonymous namespace)::pass_ccp::execute(function*)
(tree-ssa-ccp.c:2408)
==67322==  Uninitialised value was created by a stack allocation
==67322==at 0x870CED: fold_ctor_reference(tree_node*, tree_node*, unsigned
long, unsigned long, tree_node*) (gimple-fold.c:5468)
...

[Bug c++/68784] New: deductible parameter type still requires explicit reference cast, e.g., std::thread

[xuancong84 at gmail dot com]

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

Bug ID: 68784
   Summary: deductible parameter type still requires explicit
reference cast, e.g., std::thread
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xuancong84 at gmail dot com
  Target Milestone: ---

G++ compiler is weaker than MSVC on this point.
The following piece of code is compilable using MSVC but not in g++

include 
#include 
#include 

using namespace std;

void thread_add(unordered_map& ht, int from, int to)
{
for(int i = from; i <= to; ++i)
ht.insert(unordered_map::value_type(i, 0));
}

void main()
{
unordered_map ht;
thread t[2];

t[0] = thread(thread_add, ht, 0, 9);
t[1] = thread(thread_add, ht, 10, 19);

t[0].join();
t[1].join();

std::cout << "size: " << ht.size() << std::endl;
}

error: no type named ‘type’ in ‘class std::result_of ...


g++ require explicit reference cast:
t[0] = thread(thread_add, ref(ht), 0, 9);


However, this is unnecessary because it can be easily deduced from the
definition of the thread_add function whether to pass in a newly created copy
or a reference to the existing copy.

I hope the compiler can be improved to resolve all these deducible parameter
types so that programmers do not need to explicitly write the reference cast
std::ref() every time, like what has been done in MSVC.

[Bug target/68701] [4.9/5/6 Regression] "gcc -m32 -finstrument-functions -ffixed-ebp" produces internal compiler error

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #3)
> As main needs dynamic stack realignment, I wonder if we just shouldn't error
> out on trying to compile it with -ffixed-ebp.

It is still possible to compile with -maccumulate-outgoing-args. Perhaps we can
error out with the advice that -ffixed-ebp requires -m-o-a option, as is
already the case with stack probing?

[Bug tree-optimization/66142] Loop is not vectorized because not sufficient support for GOMP_SIMD_LANE

[ysrumyan at gmail dot com]

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

--- Comment #23 from Yuri Rumyantsev  ---
Richard,

Do we have any chance to vectorize attached test-case using GCC6 compiler?

[Bug tree-optimization/66142] Loop is not vectorized because not sufficient support for GOMP_SIMD_LANE

[ysrumyan at gmail dot com]

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

--- Comment #24 from Yuri Rumyantsev  ---
Richard,

Do we have any chance to vectorize attached test-case using GCC6 compiler?

[Bug tree-optimization/68776] [6 regression] gcc.dg/vect/vect-widen-mult-const-[su]16.c failures since r226675

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/68779] [5.3 Regression] HPPA/PARISC 32-bit Linux kernel build triggers multiple ICEs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug sanitizer/68777] [UBSAN] Spurious warning with C++11 lambdas ("member call on null pointer")

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Isn't this PR67941 and thus already fixed in GCC 5.3?

[Bug tree-optimization/68766] [6 regression] internal compiler error: in expand_LOOP_VECTORIZED, at internal-fn.c:1905

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #5 from Ilya Enkovich  ---
Fixed

[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES

[rguenth at gcc dot gnu.org]

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

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

Can ARM people please evaluate the attached?  It simply prefers load/store-lane
over SLP.  I'd like to know whether there are cases this is undesirable and
whether this patch causes some loops not to be vectorized at all (because I got
the load/store-lane supported test wrong).

Caveats may be that SLP may require no unrolling and load/store-lane always
does and thus with a statically known loop trip count the vectorization would
not be done with load/store-lanes.  Likewise the minimum required iterations
for the not-known case may cause the vectorized variant be skipped always
if the loop trip count is small in practice.  Likewise the extra peeling
required
for gaps may have the same effect (though with gaps the SLP variant will always
require eventually expensive permutes).

Thus caveats may apply mainly for low loop iteration counts (only decidable
at runtime in most cases).

The patch is a heuristic, possible improvements include looking at a
statically known loop trip count as well as at the actual permutation
required for SLP (may be none).  In the context of ARM load/store-lane
I know nothing about costs.

Eventually we should do the same for cases that regular interleaving
can handle if SLP requires permutations.

[Bug ada/65102] gnat-style.texi warning from including fdl.texi

[vries at gcc dot gnu.org]

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

--- Comment #11 from vries at gcc dot gnu.org ---
(In reply to vries from comment #10)
> We better ask Gerard what he meant.

https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00823.html

[Bug ada/65102] gnat-style.texi warning from including fdl.texi

[vries at gcc dot gnu.org]

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

--- Comment #10 from vries at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #9)
> > Can you paste the gcc-patches ml link that contains the approval? I haven't
> > seen it.
> 
> You replied to it though, see comment #3.

So you mean this at https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01184.html :
...
> Can you approve the fdl part?

Let's assume I can.  Okay.
...

To me the thought never occurred that this could be an approval. I read it as
just a figure of speech.

But indeed, I agree it's ambiguous. We better ask Gerard what he meant.

[Bug target/68701] [4.9/5/6 Regression] "gcc -m32 -finstrument-functions -ffixed-ebp" produces internal compiler error

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|uros at gcc dot gnu.org|
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #9 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #8)
> Can I leave this PR to you?
OK.

[Bug c++/68784] deductible parameter type still requires explicit reference cast, e.g., std::thread

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Wang Xuancong from comment #2)
> All standards are made by people. No standard is perfect. If a standard
> causes more inconvenience to the users, then it is considered sub-optimal
> and has room for improvement.

The behaviour mandated by the standard is by design, it is not a defect.

> Thus, unless you can give me a counter example that automatic parameter
> resolution can cause problems in some cases, I would consider the standard
> is not good enough, and will probably be fixed in some future C++ standards.

GCC's Bugzilla is not the right place to learn how C++ works.

It has nothing to do with deduction or "automatic parameter resolution", the
error is because you cannot bind a non-const reference to an rvalue, similar to
calling:

thread_add(unordered_map(), 0, 9);

This fails because you can't bind a temporary to the reference parameter (MSVC
gets this right).

The standard requires std::thread to copy its arguments for safety reasons, to
avoid silently forming dangling references to stack variables, MSVC gets that
part right too. If you want a reference you must request it explicitly.

If you actually run your program after compiling it with MSVC you will see it
prints:

size: 0

because 'ht' is never modified, because the threads insert into *copies* of the
map, not the original. So even with MSVC your program doesn't do what you think
it does. The standard requires you to use std::ref if you really want to create
a thread with a reference to your variable.

The standard also requires the copied arguments to be forwarded as rvalues, to
avoid surprising behaviour due to functions that take references modifying
copies not the original objects. MSVC gets this wrong, and allows the copies to
bind to lvalue reference parameters, and then your new threads modify the
copies not the original, even though you think you've bound a reference.

> But since g++ is indeed following the standard, it should not be considered
> as a bug for now, formally speaking.

It's not a bug in any sense at all. The bug is in MSVC, I suggest you discuss
it with Microsoft.

[Bug sanitizer/64820] Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0)" (0x0, 0x0) if ssp is enabled.

[chefmax at gcc dot gnu.org]

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

--- Comment #9 from Maxim Ostapenko  ---
Author: chefmax
Date: Tue Dec  8 11:34:28 2015
New Revision: 231405

URL: https://gcc.gnu.org/viewcvs?rev=231405=gcc=rev
Log:
2015-12-08  Maxim Ostapenko  

Backport from mainline.
2015-03-16  Max Ostapenko  

PR sanitizer/64820

gcc/
* cfgexpand.c (align_base): New function.
(alloc_stack_frame_space): Call it.
(expand_stack_vars): Align prev_frame to be sure
data->asan_vec elements aligned properly.

gcc/testsuite/
* c-c++-common/asan/pr64820.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/pr64820.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/cfgexpand.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/66142] Loop is not vectorized because not sufficient support for GOMP_SIMD_LANE

[rguenther at suse dot de]

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

--- Comment #25 from rguenther at suse dot de  ---
On Tue, 8 Dec 2015, ysrumyan at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66142
> 
> --- Comment #23 from Yuri Rumyantsev  ---
> Richard,
> 
> Do we have any chance to vectorize attached test-case using GCC6 compiler?

No, I don't see any.

[Bug target/67973] All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  ---
(In reply to m...@gcc.gnu.org from comment #2)
> Ah, found it, use the GNU assembler.  Maybe a little tricky, as one day,
> even that will be removed.  At that point, I think we just reject the
> -gstabs option.  The other option, is to just reject that now on darwin14+
> (or wherever it no longer works).

I believe every static approach is doomed to fail: why not just add a configure
test like this:

* first check if the configured assembler can assemble a trivial .stabs line

* if this fails, try again if it works with -Q added

* if this fails, too, disable both DBX_DEBUGGING_INFO and remove DBX_DEBUG from
  PREFERRED_DEBUGGING_TYPE

This should allow us to support Stabs while possible, but reject the
corresponding
options once the assembler cannot handle them.

  Rainer

[Bug target/67973] All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
(In reply to Rainer Orth from comment #4)
> (In reply to m...@gcc.gnu.org from comment #2)
> > Ah, found it, use the GNU assembler.  Maybe a little tricky, as one day,
> > even that will be removed.  At that point, I think we just reject the
> > -gstabs option.  The other option, is to just reject that now on darwin14+
> > (or wherever it no longer works).
> 
> I believe every static approach is doomed to fail: why not just add a
> configure
> test like this:
> 
> * first check if the configured assembler can assemble a trivial .stabs line
> 
> * if this fails, try again if it works with -Q added
> 
> * if this fails, too, disable both DBX_DEBUGGING_INFO and remove DBX_DEBUG
> from
>   PREFERRED_DEBUGGING_TYPE
> 
> This should allow us to support Stabs while possible, but reject the
> corresponding
> options once the assembler cannot handle them.

agreed on the ideal of using config - if someone has time to implement it.
We probably need to generate a config define to indicate that we've found this
case - because we will also need some specs magic to ensure that "-Q" is _only_
forced for -gstabs* otherwise folks will lose the ability to assemble AVX,
which I suspect is far more interesting to most people than support for
debugging on darwin8 ;-)

[Bug c/48088] -Werror=frame-larger-than=100 does not work as expected

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec  8 13:26:35 2015
New Revision: 231406

URL: https://gcc.gnu.org/viewcvs?rev=231406=gcc=rev
Log:
PR c/48088
PR c/68657
* common.opt (Wframe-larger-than=): Add Warning.
* opts.h (control_warning_option): Add ARG argument.
* opts-common.c (cmdline_handle_error): New function.
(read_cmdline_option): Use it.
(control_warning_option): Likewise.  Add ARG argument.
If non-NULL, decode it if needed and pass through
to handle_generated_option.  Handle CLVC_ENUM like
CLVC_BOOLEAN.
* opts.c (common_handle_option): Adjust control_warning_option
caller.
(enable_warning_as_error): Likewise.
c-family/
* c.opt (Wfloat-conversion, Wsign-conversion): Add Warning.
* c-pragma.c (handle_pragma_diagnostic): Adjust
control_warning_option caller.
ada/
* gcc-interface/trans.c (Pragma_to_gnu): Adjust
control_warning_option caller.
testsuite/
* c-c++-common/pr68657-1.c: New test.
* c-c++-common/pr68657-2.c: New test.
* c-c++-common/pr68657-3.c: New test.
* gcc.dg/cpp/warn-normalized-3.c: Use
-Werror=normalized=nfc instead of -Werror=normalized=
in dg-options.

Added:
trunk/gcc/testsuite/c-c++-common/pr68657-1.c
trunk/gcc/testsuite/c-c++-common/pr68657-2.c
trunk/gcc/testsuite/c-c++-common/pr68657-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/trans.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-pragma.c
trunk/gcc/c-family/c.opt
trunk/gcc/common.opt
trunk/gcc/opts-common.c
trunk/gcc/opts.c
trunk/gcc/opts.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/cpp/warn-normalized-3.c

[Bug c++/68784] deductible parameter type still requires explicit reference cast, e.g., std::thread

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Your version of MSVC does not follow the standard. std::thread copies its
arguments and forwards them as rvalues, so an lvalue cannot bind to the
non-const reference parameter. That's why you need to use std::ref.

[Bug driver/68788] New: -Wa doesn't work with -flto

[jon at beniston dot com]

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

Bug ID: 68788
   Summary: -Wa doesn't work with -flto
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jon at beniston dot com
  Target Milestone: ---

It seems it isn't possible to use the -Wa option to pass options to the
assembler when -flto is used.

E.g.

gcc -Wa,--my-option

works OK, but when using:

gcc -flto -Wa,--my-option -v

I can see that --my-option isn't passed to the assembler.

It seems this was mentioned on the mailing list a while ago:

https://gcc.gnu.org/ml/gcc-help/2013-04/msg00081.html

There's nothing in the docs to suggest this shouldn't work:

https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Assembler-Options.html#Assembler-Options

[Bug rtl-optimization/68721] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r231110.  I'll have a look.

[Bug c++/68784] deductible parameter type still requires explicit reference cast, e.g., std::thread

[ville.voutilainen at gmail dot com]

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

--- Comment #5 from Ville Voutilainen  ---
And to add insult to injury, msvc accepts binding lvalue reference to
temporaries, and chances are that their thread constructor does what it does
partly because of that non-conforming core language extension.

[Bug target/67973] All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> agreed on the ideal of using config - if someone has time to implement it.

I may give it a shot if I find some time.  Darwin testresults are hard
to read right now with so many failures on 10.11.

> We probably need to generate a config define to indicate that we've found this
> case - because we will also need some specs magic to ensure that "-Q" is 
> _only_
> forced for -gstabs* otherwise folks will lose the ability to assemble AVX,
> which I suspect is far more interesting to most people than support for
> debugging on darwin8 ;-)

Good point: I'd have forgotten about that.

Rainer

[Bug ipa/68790] [5/6 Regression] gcc.c-torture/execute/20050713-1.c FAILs with -O0 -fipa-icf

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-08
 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |5.4
Summary|[5/6 Regression]|[5/6 Regression]
   |gcc.c-torture/execute/20050 |gcc.c-torture/execute/20050
   |713-1.c FAILs with -O0  |713-1.c FAILs with -O0
   |-fipa-pta   |-fipa-icf
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Probably should be looked at for latent issues and forced disabled
at -O0.

[Bug target/67973] All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Dominique d'Humieres  ---
>> > agreed on the ideal of using config - if someone has time to implement it.
>>
>> I may give it a shot if I find some time.  Darwin testresults are hard
>> to read right now with so many failures on 10.11.
>
> The only goal of the patch in comment 0 is to reduce the noise.

Once this would go in, a proper solution will never happen ;-)
Honestly, I believe the user experience of gcc accepting -gstabs* and
creating output that causes assembler errors is bad, so better fix it at
the source.

Rainer

[Bug testsuite/68632] FAIL: gcc.target/arm/lto/pr65837 c_lto_pr65837_0.o assemble, -flto -mfpu=neon

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-08
   Assignee|unassigned at gcc dot gnu.org  |thopre01 at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/68786] Aligned masked store is generated for unaligned pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-08
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
The zero comes from bump_vector_ptr I think, a missed optimization.  So the
issue is that we don't properly use an unaligned type, likely when we expand:

static void
expand_mask_store_optab_fn (internal_fn, gcall *stmt, convert_optab optab)
{
  struct expand_operand ops[3];
  tree type, lhs, rhs, maskt;
  rtx mem, reg, mask;

  maskt = gimple_call_arg (stmt, 2);
  rhs = gimple_call_arg (stmt, 3);
  type = TREE_TYPE (rhs);
  lhs = fold_build2 (MEM_REF, type, gimple_call_arg (stmt, 0),
 gimple_call_arg (stmt, 1));


it just uses 'type' from rhs but that is just the value being stored.  type
needs to be adjusted with build_aligned_type () for the alignment of the
access.

[Bug rtl-optimization/68755] [4.9/5 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
It might help if we transform such "obvious" out-of-bound accesses to
__builtin_trap (or unreachable even).  Not too early of course beacuse
then we lose -Warray-bound diagnostics.

[Bug c++/68784] deductible parameter type still requires explicit reference cast, e.g., std::thread

[xuancong84 at gmail dot com]

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

--- Comment #2 from Wang Xuancong  ---
All standards are made by people. No standard is perfect. If a standard causes
more inconvenience to the users, then it is considered sub-optimal and has room
for improvement.

Thus, unless you can give me a counter example that automatic parameter
resolution can cause problems in some cases, I would consider the standard is
not good enough, and will probably be fixed in some future C++ standards.

But since g++ is indeed following the standard, it should not be considered as
a bug for now, formally speaking.

[Bug sanitizer/64820] Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0)" (0x0, 0x0) if ssp is enabled.

[chefmax at gcc dot gnu.org]

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

--- Comment #10 from Maxim Ostapenko  ---
Should be fixed on gcc-4_9-branch.

[Bug tree-optimization/68716] libgomp c.exp with -fipa-pta failures

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
Created attachment 36956
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36956=edit
patch to be tested

[Bug c++/68049] template instantiation involving may_alias defines symbol twice

[kretz at kde dot org]

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

--- Comment #1 from Matthias Kretz  ---
Is there anything I can do to help finding a resolution to this issue? It's a
rather annoying issue for my SIMD code.

[Bug target/67973] All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> > agreed on the ideal of using config - if someone has time to implement it.
>
> I may give it a shot if I find some time.  Darwin testresults are hard
> to read right now with so many failures on 10.11.

The only goal of the patch in comment 0 is to reduce the noise.

[Bug c/68657] [6 Regression] "gcc -Werror=sign-conversion test.i" shows invalid: -Wsign-conversion is not an option that controls warnings

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec  8 13:26:35 2015
New Revision: 231406

URL: https://gcc.gnu.org/viewcvs?rev=231406=gcc=rev
Log:
PR c/48088
PR c/68657
* common.opt (Wframe-larger-than=): Add Warning.
* opts.h (control_warning_option): Add ARG argument.
* opts-common.c (cmdline_handle_error): New function.
(read_cmdline_option): Use it.
(control_warning_option): Likewise.  Add ARG argument.
If non-NULL, decode it if needed and pass through
to handle_generated_option.  Handle CLVC_ENUM like
CLVC_BOOLEAN.
* opts.c (common_handle_option): Adjust control_warning_option
caller.
(enable_warning_as_error): Likewise.
c-family/
* c.opt (Wfloat-conversion, Wsign-conversion): Add Warning.
* c-pragma.c (handle_pragma_diagnostic): Adjust
control_warning_option caller.
ada/
* gcc-interface/trans.c (Pragma_to_gnu): Adjust
control_warning_option caller.
testsuite/
* c-c++-common/pr68657-1.c: New test.
* c-c++-common/pr68657-2.c: New test.
* c-c++-common/pr68657-3.c: New test.
* gcc.dg/cpp/warn-normalized-3.c: Use
-Werror=normalized=nfc instead of -Werror=normalized=
in dg-options.

Added:
trunk/gcc/testsuite/c-c++-common/pr68657-1.c
trunk/gcc/testsuite/c-c++-common/pr68657-2.c
trunk/gcc/testsuite/c-c++-common/pr68657-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/trans.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-pragma.c
trunk/gcc/c-family/c.opt
trunk/gcc/common.opt
trunk/gcc/opts-common.c
trunk/gcc/opts.c
trunk/gcc/opts.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/cpp/warn-normalized-3.c

[Bug tree-optimization/68786] Aligned masked store is generated for unaligned pointer

[ienkovich at gcc dot gnu.org]

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

--- Comment #1 from Ilya Enkovich  ---
Looks like an old bug.  We may see the same problem on avx2 using older
compiler.  Here is a test for GCC5:

double *a;
long long c;
int *d;

void
test (void)
{
  int b;
  for (b = 0; b < 1024; b++)
{
  d[b] = 1;
  if (c > a[b])
a[b] = 1.0;
}
}

>gcc  -O2 -ftree-vectorize -march=haswell small.i -S -fdump-rtl-final

In small.i.final dump:

(insn:TI 91 85 89 5 (set (mem:V4DF (plus:DI (reg:DI 0 ax [orig:151 ivtmp.36 ]
[151])
(const_int 32 [0x20])) [3 MEM[(double *)_18]+0 S32 A256])
(unspec:V4DF [
(reg:V4DI 22 xmm1 [169])
(reg:V4DF 24 xmm3 [179])
(mem:V4DF (plus:DI (reg:DI 0 ax [orig:151 ivtmp.36 ] [151])
(const_int 32 [0x20])) [3 MEM[(double *)_18]+0 S32
A256])
] UNSPEC_MASKMOV)) small.i:13 4457 {avx_maskstorepd256}
 (expr_list:REG_DEAD (reg:V4DI 22 xmm1 [169])
(nil)))
(insn:TI 89 91 93 5 (set (mem:V4DF (reg:DI 0 ax [orig:151 ivtmp.36 ] [151]) [3
MEM[(double *)vectp_pretmp.18_75]+0 S32 A64])
(unspec:V4DF [
(reg:V4DI 23 xmm2 [173])
(reg:V4DF 24 xmm3 [179])
(mem:V4DF (reg:DI 0 ax [orig:151 ivtmp.36 ] [151]) [3
MEM[(double *)vectp_pretmp.18_75]+0 S32 A64])
] UNSPEC_MASKMOV)) small.i:13 4457 {avx_maskstorepd256}
 (expr_list:REG_DEAD (reg:V4DI 23 xmm2 [173])
(nil)))

Again we have different alignment.  For avx2 it doesn't matter because we don't
have aligned and unaligned variants of maskmov.  In case of regular stores
alignment is correct.  The oldest compiler I tried was 20140625.

[Bug tree-optimization/68775] spec2006 test case 465.tonto fails with the gcc 6.0 fortran compiler

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Tue, 8 Dec 2015, izamyatin at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68775
> 
> Igor Zamyatin  changed:
> 
>What|Removed |Added
> 
>  CC||izamyatin at gmail dot com
> 
> --- Comment #2 from Igor Zamyatin  ---
> 
> > 
> > Note that it seems that tonto also fails (since forever) with AVX2 on 
> > x86_64.
> 
> Hmmm, at what optset are you seeing the failure?

As said it was an error on my side (modified sources ...).

[Bug target/68701] [4.9/5/6 Regression] "gcc -m32 -finstrument-functions -ffixed-ebp" produces internal compiler error

[henric at bergenwall dot com]

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

--- Comment #11 from henric at bergenwall dot com ---
I have noted that the compilation works with any 2 out of the 3 gcc-flags!

> gcc -finstrument-functions -ffixed-ebp a.c -> successfully compiles!
> gcc -m32 -ffixed-ebp a.c   -> successfully compiles!
> gcc -m32 -finstrument-functions a.c-> successfully compiles!

> gcc -m32 -finstrument-functions -ffixed-ebp a.c -> fails with internal error


Given that -ffixed-ebp works individually with both -finstrument-functions and
-m32, but not together, maybe it is tricky to error out on -ffixed-ebp, not
destroying something that already works?


Btw, in the company that I work for (>100.000 employees worldwide), we have
legacy code that relies on -ffixed-ebp, so please don't be too aggressive when
if you decide to error out on compilation with -ffixed-ebp.

[Bug rtl-optimization/68755] [4.9/5 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Markus Trippelsdorf from comment #7)
> --param=allow-store-data-races=1 fixes the issue.
> With --param=allow-store-data-races=0 even 4.9 generates wrong code.

That sounds backwards btw.

It's predictive commoning performing the code motion but the load
is still guarded by the header copy check (so it's a valid transform).

Only sth at the RTL optimization stage then hoists the load before the
if.  AFAIK it's ifcvt2 and -fno-if-conversion2 fixes it.

[Bug target/68701] [4.9/5/6 Regression] "gcc -m32 -finstrument-functions -ffixed-ebp" produces internal compiler error

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #7)
> (In reply to Uroš Bizjak from comment #6)
> > > Yeah.  Or if neither -m{,no-}accumulate-outgoing-args is specified, 
> > > perhaps
> > > turn that on automatically instead if -ffixed-ebp and only error out if
> > > explicit -mno-accumulate-outgoing-args?
> > 
> > IMO, this is a good idea.
> 
> Perhaps a warning should be emitted when switching
> MASK_ACCUMULATE_OUTGOING_ARGS option automatically, again as is already the
> case with stack probe (i386.c, around line 5294).

Something like following patch:

--cut here--
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 231398)
+++ config/i386/i386.c  (working copy)
@@ -5296,6 +5296,15 @@ ix86_option_override_internal (bool main_args_p,
   opts->x_target_flags |= MASK_ACCUMULATE_OUTGOING_ARGS;
 }

+  if (fixed_regs[BP_REG]
+  && !(opts->x_target_flags & MASK_ACCUMULATE_OUTGOING_ARGS))
+{
+  if (opts_set->x_target_flags & MASK_ACCUMULATE_OUTGOING_ARGS)
+   warning (0, "fixed ebp register requires %saccumulate-outgoing-args%s",
+prefix, suffix);
+  opts->x_target_flags |= MASK_ACCUMULATE_OUTGOING_ARGS;
+}
+
   /* Figure out what ASM_GENERATE_INTERNAL_LABEL builds as a prefix.  */
   {
 char *p;
--cut here--

This problem can also be triggered with stack realignment, e.g. "-ffixed-ebp
-mstackrealign" on 32 and 64-bit targets with following test case:

--cut here--
typedef float V __attribute__((vector_size(16)));

void bar (V a)
{
  volatile V b = a;
}
--cut here--

So, to avoid problems, I think that "-ffixed-ebp" should unconditionally enable
M_A_O_A on all targets, with a warning, as proposed in the above patch.

[Bug target/68701] [4.9/5/6 Regression] "gcc -m32 -finstrument-functions -ffixed-ebp" produces internal compiler error

[ubizjak at gmail dot com]

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

--- Comment #12 from Uroš Bizjak  ---
(In reply to henric from comment #11)
> I have noted that the compilation works with any 2 out of the 3 gcc-flags!
> 
> > gcc -finstrument-functions -ffixed-ebp a.c -> successfully compiles!
> > gcc -m32 -ffixed-ebp a.c   -> successfully compiles!
> > gcc -m32 -finstrument-functions a.c-> successfully compiles!
> 
> > gcc -m32 -finstrument-functions -ffixed-ebp a.c -> fails with internal error
> 
> 
> Given that -ffixed-ebp works individually with both -finstrument-functions
> and -m32, but not together, maybe it is tricky to error out on -ffixed-ebp,
> not destroying something that already works?

Please try adding -maccumulate-outgoing-args. Using this option, your code
should always compile OK.

> Btw, in the company that I work for (>100.000 employees worldwide), we have
> legacy code that relies on -ffixed-ebp, so please don't be too aggressive
> when if you decide to error out on compilation with -ffixed-ebp.

The code *will* compile, but a warning that -maccumulate-outgoing-args was
enabled to satisfy -ffixed-ebp will be emitted during compilation.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
This broke PR68721.

[Bug c++/68789] [5/6 Regression] ICE in tsubst_copy

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-08
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |5.4
 Ever confirmed|0   |1

[Bug testsuite/68629] FAIL: c-c++-common/attr-simd-3.c

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-08
   Assignee|unassigned at gcc dot gnu.org  |thopre01 at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug ipa/68790] New: [5/6 Regression] gcc.c-torture/execute/20050713-1.c FAILs with -O0 -fipa-pta

[zsojka at seznam dot cz]

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

Bug ID: 68790
   Summary: [5/6 Regression] gcc.c-torture/execute/20050713-1.c
FAILs with -O0 -fipa-pta
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 36954
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36954=edit
reduced testcase

Output:
$ gcc -fipa-icf testcase.c
$ ./a.out
Aborted

This seems to fail at various targets.

Tested revisions:
trunk r231247 - FAIL
5-branch r231055 - FAIL
5.3.0 - FAIL
5.2.0 - OK

[Bug lto/68791] Segfault during link/compilation after update.

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org
  Component|c++ |lto
   Severity|blocker |normal

--- Comment #1 from Markus Trippelsdorf  ---
Have you rebuild all the object files with 5.3? If not run "make clean"
and try again.

[Bug rtl-optimization/68721] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Oops, sorry, started already with r231108.
During fnsplit, we have split_bbs { 6 }, return_bb is 7, 6 is the only
predecessor of 7, and has successor edges to itself and to 7.
The effect of the r231108 change is:
 Removing basic block 8
+Removing basic block 7
 Removing basic block 9
-Merging blocks 6 and 7
...
   :
   fn1.part.0 ();
-  return 
+  return;

which is wrong; after fnsplit, the fn1 function doesn't return (has just some
abort) unless it calls fn1.part.0 (), but if that function returns (it does in
the testcase), then it should return the correct value.
fn1.part.0 is conditional endless loop, otherwise return.

[Bug rtl-optimization/68721] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #4 from Richard Biener  ---
Mine then.

[Bug c++/68789] New: [5/6 Regression] ICE in tsubst_copy

[jakub at gcc dot gnu.org]

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

Bug ID: 68789
   Summary: [5/6 Regression] ICE in tsubst_copy
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36953
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36953=edit
rh1288991.ii

Starting with r211084 the following testcase ICEs with -std=c++14 in
tsubst_copy.  Before that the testcase has been rejected.

[Bug driver/68788] -Wa doesn't work with -flto

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Duplicate of pr47785.

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

[Bug driver/47785] GCC with -flto does not pass options to the assembler

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||jon at beniston dot com

--- Comment #8 from Dominique d'Humieres  ---
*** Bug 68788 has been marked as a duplicate of this bug. ***

[Bug fortran/68778] Missing default initialization of finalized derived types type(C_PTR) component in subroutines

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #4 from Dominique d'Humieres  ---
If I compile the test with -fsanitize=address, I get

 TEST2: ASSOCIATED? (EXPECT: F) T

from 4.9.3 up to trunk (6.0). Val grind complains about

==72498== Syscall param write(buf) points to uninitialised byte(s)
==72498==at 0x1004D1C22: write (in /usr/lib/system/libsystem_kernel.dylib)
==72498==by 0x1000E93B9: raw_write (in
/opt/gcc/gcc6w/lib/libgfortran.3.dylib)
==72498==by 0x1000E93B9: raw_write (in
/opt/gcc/gcc6w/lib/libgfortran.3.dylib)
==72498==by 0x1009F783F: ???
==72498==  Address 0x1009f7cb0 is 32 bytes inside a block of size 512 alloc'd
==72498==at 0x18EA1: malloc (vg_replace_malloc.c:303)
==72498==by 0x1000147E4: _gfortrani_xmalloc (in
/opt/gcc/gcc6w/lib/libgfortran.3.dylib)
==72498==by 0x1076F: ???
==72498==by 0x1000F04DC: _gfortrani_fbuf_init (in
/opt/gcc/gcc6w/lib/libgfortran.3.dylib)
==72498==by 0x3FFF: ???
==72498==by 0x1009F783F: ???
==72498==by 0x107FF: ???
==72498==by 0x10013882F: ??? (in /opt/gcc/gcc6w/lib/libgfortran.3.dylib)
==72498==by 0x7FFF5FC38597: ??? (in /usr/lib/dyld)
==72498==by 0x1000E8A44: _gfortrani_init_units (in
/opt/gcc/gcc6w/lib/libgfortran.3.dylib)
==72498==by 0x10010479F: backtrace_initialize (in
/opt/gcc/gcc6w/lib/libgfortran.3.dylib)
==72498==by 0x1001047B7: init (in /opt/gcc/gcc6w/lib/libgfortran.3.dylib)

[Bug c++/68791] New: Segfault during link/compilation after update.

[jenda.plhak at gmail dot com]

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

Bug ID: 68791
   Summary: Segfault during link/compilation after update.
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jenda.plhak at gmail dot com
  Target Milestone: ---

Created attachment 36955
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36955=edit
Output of compile command with -v -save-temps

This morning my Ubuntu 14.04 offered me an update of gcc package. I installed
it quite willingly since GNU guys usually know what they are doing. However
when I tried to compile my work project, as usual, I got following error:

lto1: internal compiler error: Segmentation fault
0x91c6cf crash_signal
../../src/gcc/toplev.c:383
0x8265bd lto_file_decl_data_get_var_decl
../../src/gcc/lto-streamer.h:1222
0x8265bd lto_input_tree_ref(lto_input_block*, data_in*, function*, LTO_tags)
../../src/gcc/lto-streamer-in.c:400
0x82673d lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
../../src/gcc/lto-streamer-in.c:1442
0x5c3dd0 lto_read_decls
../../src/gcc/lto/lto.c:1990
0x5c56ce lto_file_finalize
../../src/gcc/lto/lto.c:2249
0x5c56ce lto_create_files_from_ids
../../src/gcc/lto/lto.c:2259
0x5c56ce lto_file_read
../../src/gcc/lto/lto.c:2300
0x5c56ce read_cgraph_and_symbols
../../src/gcc/lto/lto.c:3005
0x5c56ce lto_main()
../../src/gcc/lto/lto.c:3475

System is Ubuntu 14.04.
Output of version (-v) is attached.

temp files were not generated, probably because of the segfault. We are getting
no warnings while compiling the object files or during the link. Full list of
flags and other stuff we pass while compiling object files:

g++ -std=c++14 -DFORMAT_STRING_EXCEPT -Ilibs -Isrc -I/usr/include/jsoncpp
`pkg-config --cflags libosrm` -I`pg_config --includedir` -Wall -Wextra
-Wformat=2 -Wcast-qual -Wpointer-arith -Wstrict-aliasing "-DGIT_REV=\"`git
rev-parse HEAD`\"" -c -g3 -O0

Full command that triggers the segfault:

g++ -Llibs/webstor build/d/o/bin/jp.o build/d/o/binary_write.o
build/d/o/logger.o build/d/o/s3.o build/d/o/s3stream.o
build/d/o/signalhandler.o build/d/o/socket.o build/d/o/unzip.o build/d/o/util.o
build/d/o/csa/cook.o build/d/o/csa/diff.o build/d/o/csa/json.o
build/d/o/csa/meta.o build/d/o/csa/partition.o build/d/o/csa/preprocess.o
build/d/o/csa/preprocess_diff.o build/d/o/csa/profile_p.o
build/d/o/csa/profile_query.o build/d/o/csa/query_p.o build/d/o/csa/raw.o
build/d/o/csa/time.o build/d/o/csa/timetable.o build/d/o/csa_tester/benchmark.o
build/d/o/csa_tester/inspect.o build/d/o/csa_tester/json.o
build/d/o/csa_tester/main.o build/d/o/csa_tester/prepare.o
build/d/o/csa_tester/prettify.o build/d/o/csa_tester/random_requests.o
build/d/o/csa_tester/read.o build/d/o/csa_tester/test.o
build/d/o/csa_tester/test_valid.o build/d/o/gtfs/csv.o
build/d/o/gtfs/read_data.o build/d/o/gtfs/read_data_ctx.o
build/d/o/gtfs/steps.o build/d/o/traffic_db/read_data.o
build/d/o/traffic_db/read_data_ctx.o build/d/o/traffic_db/step_7.o
build/d/o/traffic_db/steps.o build/d/o/jp/barrier.o build/d/o/jp/error.o
build/d/o/jp/future_bag.o build/d/o/jp/future_pool.o build/d/o/jp/log.o
build/d/o/jp/portals.o build/d/o/jp/stringf.o build/d/o/jp/util.o
build/d/o/jp/bin/get_settings.o build/d/o/jp/bin/key_defs.o
build/d/o/jp/bin/main.o build/d/o/jp/bin/main_client.o
build/d/o/jp/bin/main_data.o build/d/o/jp/bin/main_explorer.o
build/d/o/jp/bin/main_loop.o build/d/o/jp/bin/main_osrm.o
build/d/o/jp/bin/main_search.o build/d/o/jp/cache/cache.o
build/d/o/jp/cache/db_storage.o build/d/o/jp/cache/memory_storage.o
build/d/o/jp/config/config.o build/d/o/jp/config/read.o
build/d/o/jp/config/value.o build/d/o/jp/data/coords_db.o
build/d/o/jp/data/gtfs_source.o build/d/o/jp/data/osrm_footpath_loader.o
build/d/o/jp/data/redis_notifier.o build/d/o/jp/data/service.o
build/d/o/jp/data/stream_saver.o build/d/o/jp/data/traffic_db_source.o
build/d/o/jp/data/transfers_pipe.o build/d/o/jp/explorer/command_processor.o
build/d/o/jp/explorer/pretty_print.o build/d/o/jp/osrm/files_loader.o
build/d/o/jp/osrm/files_watcher.o build/d/o/jp/osrm/redis_client.o
build/d/o/jp/osrm/redis_server.o build/d/o/jp/osrm/redis_watcher.o
build/d/o/jp/osrm/s3_loader.o build/d/o/jp/osrm/service.o
build/d/o/jp/pq/connection.o build/d/o/jp/redis/blpoper.o
build/d/o/jp/redis/poller.o build/d/o/jp/redis/re_ctx.o
build/d/o/jp/redis/rpusher.o build/d/o/jp/redis/rsetter.o
build/d/o/jp/search/filter.o build/d/o/jp/search/redis_client.o
build/d/o/jp/search/redis_server.o build/d/o/jp/search/redis_watcher.o
build/d/o/jp/search/service.o build/d/o/jp/search/stream_loader.o
build/d/o/jp/tz/read_iana.o build/d/o/docopt/docopt.o build/d/o/hash/md5.o
-lwebstor -lssl -lcurl -lxml2 -lpthread -lboost_date_time  
-lboost_regex -lboost_system 

[Bug c++/68784] deductible parameter type still requires explicit reference cast, e.g., std::thread

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Wang Xuancong from comment #0)
> g++ require explicit reference cast:
> t[0] = thread(thread_add, ref(ht), 0, 9);

With that change your program has a data race due to modifying the same object
in two separate threads, which leads to undefined behaviour. You should get a
good book and read it carefully.

[Bug libstdc++/68792] New: Review doxygen output and don't install useless things

[redi at gcc dot gnu.org]

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

Bug ID: 68792
   Summary: Review doxygen output and don't install useless things
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: redi at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Currently with doxygen 1.8.9 the output for libstdc++ creates loads of useless
man-pages for implementation details that should not be in the public API docs:

std::tr2::__detail.3
std::_List_iterator.3

These should either be suppressed, or deleted after they are generated.

(with doxygen 1.8.10 we get a man page per header, which is even worse, but
that's a separate issue)

(See Bug 39868 for a different issue we had previously.)

[Bug target/67973] All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
> Once this would go in, a proper solution will never happen ;-)
> Honestly, I believe the user experience of gcc accepting -gstabs* and
> creating output that causes assembler errors is bad, so better fix it at
> the source.

Indeed!

[Bug target/68793] Bad optimization by split-wide-type on NEON

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #4 from ktkachov at gcc dot gnu.org ---
The testcase doesn't compile for me.
Did you mean the below?
#include 

typedef unsigned int uint;

void RGBA2BGRA_neon64(const uint* src, uint* dst, uint count)
{
uint i = 0;
for (; i < count - 7; i += 8) {
uint8x8x4_t tmp = vld4_u8((const uint8_t*)(src + i));
uint8x8x4_t tmp2 = { tmp.val[2], tmp.val[1], tmp.val[0], tmp.val[3] };
vst4_u8((uint8_t*)(dst + i), tmp2);
}
for (; i < count; ++i) {
dst[i] = src[i] & 0x00ff00ff;
uint tmp = src[i] & 0xff00ff00;
dst[i] |= (tmp << 16) | (tmp >> 16);
}
}

void RGBA2BGRA_neon128(const uint* src, uint* dst, uint count)
{
uint i = 0;
for (; i < count - 15; i += 16) {
uint8x16x4_t tmp = vld4q_u8((const uint8_t*)(src + i));
uint8x16x4_t tmp2 = {tmp.val[2], tmp.val[1], tmp.val[0], tmp.val[3]};
vst4q_u8((uint8_t*)(dst + i), tmp2);
}
for (; i < count; ++i) {
dst[i] = src[i] & 0x00ff00ff;
uint tmp = src[i] & 0xff00ff00;
dst[i] |= (tmp << 16) | (tmp >> 16);
}
}

Can you please try a trunk compiler?
I indeed get the extra umovs with a GCC 5 compiler but latest trunk at -O2
-mcpu=generic for me generates the good code for that loop:
ld4 {v4.16b - v7.16b}, [x6]
orr v0.16b, v6.16b, v6.16b
orr v1.16b, v5.16b, v5.16b
orr v2.16b, v4.16b, v4.16b
orr v3.16b, v7.16b, v7.16b
st4 {v0.16b - v3.16b}, [x3]

[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Tue, 8 Dec 2015, alalaw01 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707
> 
> --- Comment #6 from alalaw01 at gcc dot gnu.org ---
> Well, I can confirm that the patch generates load-lanes/store-lanes instead of
> SLP, all over the (vect) testsuite. All execution tests are passing :) so it
> *may* just be a case of updating a lot of scan-tree-dump tests but we'll need
> to do at least some performance evaluation, watch this space.

Eh ;)  From discussion on IRC it seems that we should retain SLP
if the SLP code wouldn't need any permutation (and then we can also
include some special-casing of very low-trip loops).  I'll update the patch
tomorrow also trying to handle the interleaving case (to make testing
effects on my side easier).

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Done.

[Bug tree-optimization/68786] Aligned masked store is generated for unaligned pointer

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
For normal vectorized stores, the alignment is preserved through the
MEM_REF/TARGET_MEM_REF type, e.g.
5991  TREE_TYPE (data_ref)
5992= build_aligned_type (TREE_TYPE (data_ref),
5993  align * BITS_PER_UNIT);
but for masked loads/stores we don't have that available, all we record is
the pointer (what we put as TREE_OPERAND (mem_ref, 0)), which can have
arbitrary type, and the aliasing pointer (with always zero constant).
The alignment info we record through:
  set_ptr_info_alignment (get_ptr_info (dataref_ptr), align,
  misalign);
Unfortunately, it seems that this way we rely on the optimizers not to lose the
alignment in the points to info, otherwise get_object_alignment_2 assumes the
pointer is fully aligned.
In *.vect it is still preserved:
  # PT = nonlocal escaped
  # ALIGN = 8, MISALIGN = 0
  vectp_pretmp.14_77 = vectp_pretmp.14_74 + 32;
  # USE = anything
  # CLB = anything
  MASK_STORE (vectp_pretmp.14_77, 0B, mask__ifc__37.13_72, vect_cst__73);
but then comes ivopts and turns that into:
  _36 = ivtmp.32_7 + 32;
  # PT = nonlocal escaped
  _37 = (vector(4) double *) _36;
  # PT = nonlocal escaped
  # ALIGN = 8, MISALIGN = 0
  vectp_pretmp.14_77 = _37;
  # USE = anything
  # CLB = anything
  MASK_STORE (vectp_pretmp.14_77, 0B, mask__ifc__37.13_72, vect_cst__73);
and then dom3 turns this into:
  _36 = ivtmp.32_7 + 32;
  # PT = nonlocal escaped
  _37 = (vector(4) double *) _36;
  # PT = nonlocal escaped
  # ALIGN = 8, MISALIGN = 0
  vectp_pretmp.14_77 = _37;
  # USE = anything
  # CLB = anything
  MASK_STORE (_37, 0B, mask__36.12_70, { 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0 });
and the points to info is there already only on a SSA_NAME that has zero uses.

So, I think that we need to store the original alignment from the vectorization
time somewhere else, so it is not an optimization to have that info preserved.
As the second argument of MASK_{LOAD,STORE} ifn is always 0, and all it matters
is the type on it, perhaps we could stick the alignment in that argument in
there?  I.e. call get_object_alignment for the original load/store during
tree-if-conversion.c, in the vectorizer store:
  misalign ? misalign & -misalign : align
as INTEGER_CST with the type we were using on the 0 pointer now, and then
during expansion use build_int_cst (TREE_TYPE (gimple_call_arg (stmt, 1)), 0)
instead of gimple_call_arg (stmt, 1), and the actual value use to
build_aligned_type from the rhs type.  Richard, are you ok with that
representation?

And then of course is the optimization question, that it is bad that the points
to / alignment info is lost due to what ivopts and following optimization
passes perform.  Should we have some late ccp pass that recomputes it, or teach
ivopts to to add alignment/points to info to the stuff it creates, or teach
some optimizations that if they replace one pointer with another defined in the
same bb and the old one has more precise points to info (or similarly for
integers and value ranges) that it could stick that better info onto the other
SSA_NAME?

[Bug c++/68784] deductible parameter type still requires explicit reference cast, e.g., std::thread

[xuancong84 at gmail dot com]

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

--- Comment #6 from Wang Xuancong  ---
You are right! I have tested myself. MSVC outputs 0 instead of crashing
(crashing is what we expected), it is accepting compilation but not doing the
job correctly, that it passes a temporarily created copy of the object instead
of the reference of the original object.

Since g++ gives a compilation error, but MSVC accepts the syntax but fails
silently. So in the end, g++ still better than MSVC, I take back my original
claim.

However, I do not agree with "the standard requires std::thread to copy its
arguments for safety reasons, to avoid silently forming dangling references to
stack variables". Not all programmers are ignorant. Whether to pass in the
reference of the original object or the temporarily created object, can be made
clear by the programmer when they specify the arguments for the thread
function, e.g.,
void thread_add(unordered_map& ht, int from, int to);
void thread_add(unordered_map ht, int from, int to);

The programmers should know what they are doing, and the difference between the
above two thread function declarations. And they should also know that all
local objects are stored on the stack, if the function returns, all local
objects are destructed. Thus, the thread creator function can return only after
all threads finished, if the thread function will ever access the creator
function's local objects.

[Bug target/68674] ARM attribute target neon warning: incompatible implicit declaration of built-in function

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
I can't reproduce the ICE with the testcase.
My arm-none-eabi with -mcpu=cortex-a9 -mfloat-abi=hard  -mfpu=neon -O2
generates:
.cpu cortex-a9
.eabi_attribute 28, 1
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 2
.eabi_attribute 34, 1
.eabi_attribute 18, 4
.file   "neonattr.c"
.text
.align  2
.global foo
.syntax unified
.arm
.fpu neon
.type   foo, %function
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
movwr1, #:lower16:a
movwr2, #:lower16:b
movtr1, #:upper16:a
movtr2, #:upper16:b
movwr3, #:lower16:e
vldrd16, [r1]
movtr3, #:upper16:e
vldrd17, [r2]
vaddl.s8q8, d16, d17
vst1.64 {d16-d17}, [r3:64]
bx  lr
.size   foo, .-foo
.comm   e,16,8
.comm   b,8,8
.comm   a,8,8
.ident  "GCC: (unknown) 6.0.0 20151207 (experimental)"

[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES

[alalaw01 at gcc dot gnu.org]

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

--- Comment #6 from alalaw01 at gcc dot gnu.org ---
Well, I can confirm that the patch generates load-lanes/store-lanes instead of
SLP, all over the (vect) testsuite. All execution tests are passing :) so it
*may* just be a case of updating a lot of scan-tree-dump tests but we'll need
to do at least some performance evaluation, watch this space.

[Bug libstdc++/58938] std::exception_ptr is missing on architectures with incomplete atomic int support

[philip.deegan at gmail dot com]

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

Philip Deegan  changed:

   What|Removed |Added

 CC||philip.deegan at gmail dot com

--- Comment #13 from Philip Deegan  ---
How would one fix this on ARMv7-A for instance? 

Compiling with "-march=armv7-a" on arm-linux-gnueabihf results in a link error
for exception_ptr/current_exception/rethrow_exception etc.

gcc_5.3_ARM32HF/bin/gcc  -dM - -E -march=armv7-a < /dev/null | grep 
ATOMIC_INT_LOCK_FREE
#define __GCC_ATOMIC_INT_LOCK_FREE 2

[Bug c/48088] -Werror=frame-larger-than=100 does not work as expected

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
.

[Bug c/48088] -Werror=frame-larger-than=100 does not work as expected

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Should be fixed now for GCC 6+.

[Bug target/68793] Bad optimization by split-wide-type on NEON

[linux at carewolf dot com]

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

--- Comment #3 from Allan Jensen  ---
Created attachment 36959
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36959=edit
neon-test-no-split-wide-types.s

[Bug rtl-optimization/68721] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Created attachment 36960
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36960=edit
untested fix

[Bug target/68793] Bad optimization by split-wide-type on NEON

[linux at carewolf dot com]

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

--- Comment #6 from Allan Jensen  ---
I mean the neon64 case, not 32-bit.

[Bug target/68793] Bad optimization by split-wide-type on NEON

[ktkachov at gcc dot gnu.org]

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
(In reply to Allan Jensen from comment #6)
> I mean the neon64 case, not 32-bit.

Seems so. I get:
_Z16RGBA2BGRA_neon64PKjPjj:
.LFB3215:
.cfi_startproc
subsw7, w2, #7
mov w5, 0
beq .L4
.p2align 2
.L8:
ubfiz   x3, x5, 2, 32
add w5, w5, 8
add x4, x0, x3
add x3, x1, x3
cmp w5, w7
ld4 {v4.8b - v7.8b}, [x4]
mov v0.8b, v6.8b
mov v1.8b, v5.8b
mov v2.8b, v4.8b
mov v3.8b, v7.8b
st4 {v0.8b - v3.8b}, [x3]
bcc .L8
.L4:
cmp w5, w2
bcs .L10
uxtwx3, w5
sub w2, w2, #1
sub w2, w2, w5
add x5, x3, 1
add x5, x2, x5
lsl x2, x3, 2
lsl x5, x5, 2
.p2align 2
.L7:
ldr w3, [x0, x2]
and w4, w3, 16711935
str w4, [x1, x2]
ldr w3, [x0, x2]
and w3, w3, -16711936
orr w3, w4, w3, ror (32 - 16)
str w3, [x1, x2]
add x2, x2, 4
cmp x2, x5
bne .L7
ret
.L10:
ret

[Bug fortran/68768] [fortran] propagate foo restrict to foo._omp_fn.0

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
PR68640 has been fixed by committing the simple fix, so the status of this PR
has changed from hypothetical to actual.

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Tue Dec  8 14:43:32 2015
New Revision: 231412

URL: https://gcc.gnu.org/viewcvs?rev=231412=gcc=rev
Log:
PR c++/68116
* g++.dg/cpp0x/pr68116.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr68116.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug driver/68794] New: an option for -fsanitize= is accepted even if the corresponding library is not available

[doko at gcc dot gnu.org]

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

Bug ID: 68794
   Summary: an option for -fsanitize= is accepted even if the
corresponding library is not available
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

[forwarded from https://bugs.debian.org/805422]

an option for -fsanitize= is accepted even if the corresponding library is
not available, e.g. undefined/ubsan on aarch64-linux-gnu.  The compiler should
warn when building, not only failing when linking.

...
g++ -DDEBUG -g2 -O1 -std=c++03  -pipe -fsanitize=undefined -c fipsalgt.cpp
g++ -DDEBUG -g2 -O1 -std=c++03  -pipe -fsanitize=undefined -c dlltest.cpp
g++ -o cryptest.exe -DDEBUG -g2 -O1 -std=c++03  -pipe
-fsanitize=undefined bench.o bench2.o test.o validat1.o validat2.o
validat3.o adhoc.o datatest.o regtest.o fipsalgt.o dlltest.o
./libcryptopp.a -pthread
/usr/bin/ld: cannot find -lubsan
collect2: error: ld returned 1 exit status

[Bug tree-optimization/68333] [6 Regression] FAIL: gcc.dg/vect/slp-multitypes-4.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1

[mwahab at gcc dot gnu.org]

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

--- Comment #5 from mwahab at gcc dot gnu.org ---
(In reply to mwahab from comment #4)
> (In reply to Richard Biener from comment #3)
> > Should be fixed now.
> 
> It's still failing for aarch64_be-none-elf.
> 
> The test has a dg-skip-if directive for aarch64-*-*, should that be
> aarch64*-*-*?

Sorry, I was looking at the wrong test, slp-multitype-4 is passing for
aarch64_be.

[Bug target/68793] Bad optimization by split-wide-type on NEON

[linux at carewolf dot com]

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

--- Comment #1 from Allan Jensen  ---
Created attachment 36957
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36957=edit
neon-test.cpp

[Bug target/68793] Bad optimization by split-wide-type on NEON

[linux at carewolf dot com]

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

--- Comment #2 from Allan Jensen  ---
Created attachment 36958
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36958=edit
neon-test-split-wide-types.s

[Bug target/68793] New: Bad optimization by split-wide-type on NEON

[linux at carewolf dot com]

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

Bug ID: 68793
   Summary: Bad optimization by split-wide-type on NEON
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linux at carewolf dot com
  Target Milestone: ---

Enabling the optimization 'split-wide-types' causes worse code for NEON
intrinsics than disabling it, and it is enabled by default by -O1.

It is triggered by multi-register intrinsics such as vst4 and vld4, and using a
NEON-width wider than the native registers (128bit on aarch64 for instance).

uint8x16x4_t tmp = vld4q_u8((const uint8_t*)(src + i));
vst4q_u8((uint8_t*)(dst + i), {tmp.val[2], tmp.val[1], tmp.val[0],
tmp.val[3]});

with -fno-split-wide-types generates
ld4 {v4.16b - v7.16b}, [x5]
orr v0.16b, v6.16b, v6.16b
orr v1.16b, v5.16b, v5.16b
orr v2.16b, v4.16b, v4.16b
orr v3.16b, v7.16b, v7.16b
st4 {v0.16b - v3.16b}, [x4]

But by default -O1 (with split-wide-types):
ld4 {v0.16b - v3.16b}, [x5]
umovx14, v2.d[0]
umovx15, v2.d[1]
umovx12, v1.d[0]
umovx13, v1.d[1]
umovx10, v0.d[0]
umovx11, v0.d[1]
stp x14, x15, [sp]
str q3, [sp, 48]
str x12, [sp, 16]
stp x13, x10, [sp, 24]
str x11, [sp, 40]
ld1 {v0.16b - v3.16b}, [sp]
st4 {v0.16b - v3.16b}, [x8]

[Bug tree-optimization/68640] foo restrict propagated to foo._omp_fn.0

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org ---
Author: vries
Date: Tue Dec  8 14:17:42 2015
New Revision: 231411

URL: https://gcc.gnu.org/viewcvs?rev=231411=gcc=rev
Log:
Clear restrict in install_var_field

2015-12-08  Tom de Vries  

PR tree-optimization/68640
* omp-low.c (install_var_field): Clear the restrict qualifier on the
var
type.

Added:
trunk/gcc/testsuite/gcc.dg/gomp/pr68640.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c

[Bug c/68657] [6 Regression] "gcc -Werror=sign-conversion test.i" shows invalid: -Wsign-conversion is not an option that controls warnings

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Should be fixed now.

[Bug c++/68049] [5/6 Regression] template instantiation involving may_alias defines symbol twice

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-08
Summary|template instantiation  |[5/6 Regression] template
   |involving may_alias defines |instantiation involving
   |symbol twice|may_alias defines symbol
   ||twice
 Ever confirmed|0   |1