[Bug target/68172] [6 Regression] LTO/PGO bootstrapped compiler is miscompiled (looping in sched_rgn_init)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from Markus Trippelsdorf  ---
Cannot reproduce anymore. Closing.

[Bug middle-end/68251] New: [6 Regression] sorry, unimplemented: reverse storage order for BLKmode

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 68251
   Summary: [6 Regression] sorry, unimplemented: reverse storage
order for BLKmode
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

Nightly build of CP2K failed with: sorry, unimplemented: reverse storage order
for BLKmode , between good r229944 and bad r229981

I'm reducing the testcase, but a single couple takes several minutes before the
error triggers, so it will take a while.

[Bug debug/66728] [5 Regression] CONST_WIDE_INT causes corrupted DWARF debug info

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---
Summary|[5/6 Regression]|[5 Regression]
   |CONST_WIDE_INT causes   |CONST_WIDE_INT causes
   |corrupted DWARF debug info  |corrupted DWARF debug info
  Known to fail||5.2.0

--- Comment #10 from Richard Biener  ---
Still not fixed on the branch.

[Bug c++/68252] New: regiression left operand of shift expression, while we shift > 0 integer

[dushistov at mail dot ru]

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

Bug ID: 68252
   Summary: regiression left operand of shift expression, while we
shift > 0 integer
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dushistov at mail dot ru
  Target Milestone: ---

struct Test {   
  static const int foo = (1 << sizeof(int))*(-3);   
};

$ g++ -c -Wall -Wextra -pedantic -std=c++11 test_bug.cpp test_bug.cpp:2:44:
error: left operand of shift expression '(-3 << 4ul)' is negative
   static const int foo = (1 << sizeof(int))*(-3);  
^


while clang not give any errors, plus gcc 4.9.3 also not produce any errors.

[Bug middle-end/68251] [6 Regression] sorry, unimplemented: reverse storage order for BLKmode

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Botcazou  ---
Ouch.  Could you post the configure line of the compiler?

[Bug regression/68253] New: Valgrind: Conditional jump or move depends on uninitialised value in fold-const.c:5587

[marxin at gcc dot gnu.org]

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

Bug ID: 68253
   Summary: Valgrind: Conditional jump or move depends on
uninitialised value in fold-const.c:5587
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Hi.

Starting from r229965 (Merge of the scalar-storage-order branch.) there are
some new valgrind errors in:

==4887== Conditional jump or move depends on uninitialised value(s)
==4887==at 0x5C7706: fold_truth_andor_1(unsigned int, tree_code,
tree_node*, tree_node*, tree_node*) (fold-const.c:5587)
==4887==by 0x5C8828: fold_truth_andor(unsigned int, tree_code, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node*) (fold-const.c:8020)
==4887==by 0x8A1A79: fold_binary_loc(unsigned int, tree_code, tree_node*,
tree_node*, tree_node*) (fold-const.c:10444)
==4887==by 0x8B380C: fold(tree_node*) (fold-const.c:11994)
==4887==by 0x6A4664: cp_build_binary_op(unsigned int, tree_code,
tree_node*, tree_node*, int) (typeck.c:5123)
==4887==by 0x5EF98F: build_new_op_1(unsigned int, tree_code, int,
tree_node*, tree_node*, tree_node*, tree_node**, int) (call.c:5758)
==4887==by 0x5F036E: build_new_op(unsigned int, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int) (call.c:5803)
==4887==by 0x69B42E: build_x_binary_op(unsigned int, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int) (typeck.c:3835)
==4887==by 0x67D45D: cp_parser_binary_expression(cp_parser*, bool, bool,
bool, cp_parser_prec, cp_id_kind*) (parser.c:8605)
==4887==by 0x67D94D: cp_parser_assignment_expression(cp_parser*,
cp_id_kind*, bool, bool) (parser.c:8726)
==4887==by 0x67FC11: cp_parser_expression(cp_parser*, cp_id_kind*, bool,
bool) (parser.c:8885)
==4887==by 0x6716B6: cp_parser_jump_statement (parser.c:11422)
==4887==by 0x6716B6: cp_parser_statement(cp_parser*, tree_node*, bool,
bool*, vec*) (parser.c:10049)

My test case is tramp3d ([1]) with following options:

valgrind --leak-check=yes --trace-children=yes ./gcc/xg++ -Bgcc
~/Programming/tramp3d/tramp3d-v4.ii -fpermissive -O2

Note: The error is exposed right at the beginning of compiler's run.

[1] http://users.suse.com/~rguenther/tramp3d/

Thanks,
Martin

[Bug middle-end/68253] [6 Regression] Valgrind: Conditional jump or move depends on uninitialised value in fold-const.c:5587

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|regression  |middle-end
   Target Milestone|--- |6.0
Summary|Valgrind: Conditional jump  |[6 Regression] Valgrind:
   |or move depends on  |Conditional jump or move
   |uninitialised value in  |depends on uninitialised
   |fold-const.c:5587   |value in fold-const.c:5587

[Bug middle-end/68251] [6 Regression] sorry, unimplemented: reverse storage order for BLKmode

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

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

--- Comment #2 from Joost VandeVondele  
---
very standard, I assume:

Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/data/vjoost/gnu/gcc_trunk/install
--enable-languages=c,c++,fortran --disable-multilib --enable-plugins
--enable-lto --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20151109 (experimental) [trunk revision 229981] (GCC)

[Bug c++/68252] regiression left operand of shift expression, while we shift > 0 integer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-09
Version|unknown |5.2.1
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Looks like a bogus folding to me (CST << B * CST -> CST' << B).

 return -3 << a;

from .original and

int foo (int a)
{
  return (1 << a) * -3;
}

On trunk:

/* Fold (a * (1 << b)) into (a << b)  */
(simplify
 (mult:c @0 (convert? (lshift integer_onep@1 @2)))
  (if (! FLOAT_TYPE_P (type)
   && tree_nop_conversion_p (type, TREE_TYPE (@1)))
   (lshift @0 @2)))

on the branch this is still in fold-const.c.

Note that I think this undefinedness doesn't buy us anything and that we should
just make sure to not emit bogus ubsan errors or warnings.

[Bug fortran/44856] Usage of array PARAMETERs: Literal copy vs. global variable

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-09
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
Concerning the test in comment 3, is "REAL_KINDS(i)" a constant if "i" is not?
IMO it is not and it is why I have used the convoluted code

do i=1,size(real_kinds)
  if (i == 1) then
write(s, '(2F4.1,2F4.0)') real(-9.4905,kind=j(1)), &
  real(9.4905,kind=j(1)),  &
  real(9.5,kind=j(1)), real(8.5,kind=j(1))
write(s1, '(3PE10.3,2PE10.3)') real(987350.,kind=j(1)), &
   real(98765.0,kind=j(1))
  else if (i == 2) then
...
  end if

in gfortran.dg/fmt_en.f90.

[Bug middle-end/68251] [6 Regression] sorry, unimplemented: reverse storage order for BLKmode

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P1
   Target Milestone|--- |6.0

[Bug tree-optimization/66768] address space gets lost on literal pointer

[rth at gcc dot gnu.org]

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

--- Comment #11 from Richard Henderson  ---
Author: rth
Date: Mon Nov  9 09:18:16 2015
New Revision: 229997

URL: https://gcc.gnu.org/viewcvs?rev=229997&root=gcc&view=rev
Log:
PR tree-opt/66768

* tree-ssa-address.c (create_mem_ref_raw): Use a pointer of
the correct type for the base.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-address.c

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-09
   Target Milestone|--- |6.0
Summary|wrong code at -O2 and -O3   |[6 Regression] wrong code
   |on x86_64-linux-gnu (in |at -O2 and -O3 on
   |64-bit mode)|x86_64-linux-gnu (in 64-bit
   ||mode)
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Disabling VRP helps.  Confirmed.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-09
   Target Milestone|--- |4.9.4
Summary|wrong code at -O2 and -O3   |[4.9/5/6 Regression] wrong
   |on x86_64-linux-gnu |code at -O2 and -O3 on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

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

[Bug tree-optimization/68248] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in uniform_vector_p, at tree.c:10807

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-09
   Target Milestone|--- |6.0
Summary|ICE on valid code at -O3 on |[6 Regression] ICE on valid
   |x86_64-linux-gnu in |code at -O3 on
   |uniform_vector_p, at|x86_64-linux-gnu in
   |tree.c:10807|uniform_vector_p, at
   ||tree.c:10807
 Ever confirmed|0   |1

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

[Bug rtl-optimization/68189] [4.9/5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu by RTL if-conversion

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
(In reply to Mikael Pettersson from comment #6)
> Started with r208165 (on x86_64-linux with -O3).

This also only exposed the bug I believe.

[Bug c++/68252] regiression left operand of shift expression, while we shift > 0 integer

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(with { tree utype = unsigned_type_for (TREE_TYPE (@0)); }
 (convert (lshift (convert:utype @0) @2
maybe?

[Bug tree-optimization/68240] [6 Regression] compilation hangs on valid code at -O1 and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-09
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0
Summary|compilation hangs on valid  |[6 Regression] compilation
   |code at -O1 and above on|hangs on valid code at -O1
   |x86_64-linux-gnu|and above on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

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

[Bug tree-optimization/68240] [6 Regression] compilation hangs on valid code at -O1 and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Starting iteration 95064
Value numbering iftmp.1_2 stmt = iftmp.1_2 = PHI <1(3), 0(4)>
Setting value number of iftmp.1_2 to iftmp.0_1 (changed)
Starting iteration 95065
Value numbering iftmp.1_2 stmt = iftmp.1_2 = PHI <1(3), 0(4)>
Setting value number of iftmp.1_2 to 1 (changed)
Starting iteration 95066
Value numbering iftmp.1_2 stmt = iftmp.1_2 = PHI <1(3), 0(4)>
Setting value number of iftmp.1_2 to iftmp.0_1 (changed)
Starting iteration 95067
Value numbering iftmp.1_2 stmt = iftmp.1_2 = PHI <1(3), 0(4)>
Setting value number of iftmp.1_2 to 1 (changed)
...

(oops)

[Bug middle-end/68251] [6 Regression] sorry, unimplemented: reverse storage order for BLKmode

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #3 from Joost VandeVondele  
---
Created attachment 36667
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36667&action=edit
partially reduced testcase

I attach a partially reduced testcase, reduction will continue for a while.

gfortran -c -O3 -D__LIBINT -cpp 493.f90

[Bug tree-optimization/68234] tree-vrp pass need to be improved when handling ASSERT_EXPR

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

Summary|tree-vrp pass need to be|tree-vrp pass need to be
   |improved when handling  |improved when handling
   |ASSERT/PLUS/MINUS/_EXPR and |ASSERT_EXPR
   |Phi node|

--- Comment #2 from Jiong Wang  ---
(In reply to Richard Biener from comment #1)

> I think the issue is that we insert the assert in the first place or
> that we intersect to a symbolic range this causes us to not use SCEV / loop
> analysis to get at the range for c_1.  That is, in vrp_visit_phi_node
> the early outs to varying: shouldn't skip
> 
>   /* If we dropped either bound to +-INF then if this is a loop
>  PHI node SCEV may known more about its value-range.  */
>   if ((cmp_min > 0 || cmp_min < 0
>|| cmp_max < 0 || cmp_max > 0)
>   && (l = loop_containing_stmt (phi))
>   && l->header == gimple_bb (phi))
> adjust_range_with_scev (&vr_result, l, phi, lhs);
> 
> sth like
> 
> Index: gcc/tree-vrp.c
> ===
> --- gcc/tree-vrp.c  (revision 229804)
> +++ gcc/tree-vrp.c  (working copy)
> @@ -8827,6 +8805,24 @@ update_range:
>  
>/* No match found.  Set the LHS to VARYING.  */
>  varying:
> +
> +  /* If we dropped either bound to +-INF then if this is a loop
> + PHI node SCEV may known more about its value-range.  */
> +  if ((l = loop_containing_stmt (phi))
> +  && l->header == gimple_bb (phi))
> +{
> +  adjust_range_with_scev (&vr_result, l, phi, lhs);
> +
> +  /* If we will end up with a (-INF, +INF) range, set it to
> +VARYING.  Same if the previous max value was invalid for
> +the type and we end up with vr_result.min > vr_result.max.  */
> +  if (!((vrp_val_is_max (vr_result.max)
> +&& vrp_val_is_min (vr_result.min))
> +   || compare_values (vr_result.min,
> +  vr_result.max) > 0))
> +   goto update_range;
> +}
> +
>set_value_range_to_varying (lhs_vr);
>return SSA_PROP_VARYING;
>  }
> 
> which ends up with
> 
> Value ranges after VRP:
> 
> c_1: [0, +INF]
> 
> as desired.  Maybe you can take the above and put it to testing.

Thanks for the explanation on those issues.

The "if" check needs to be guarded by vr_result.type == VR_RANGE, otherwise
above draft patch passed my testing. bootstrapping on x86-64 and AArch64 OK. no
regresson on both.

[Bug middle-end/68253] [6 Regression] Valgrind: Conditional jump or move depends on uninitialised value in fold-const.c:5587

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Botcazou  ---
Indeed, will fix momentarily.

[Bug tree-optimization/68238] Vector cost model overestimates prologue cost for SLPed code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Interesting.  The trunk patch wasn't supposed to change behavior ;)

Btw, confirmed on x86_64 for the 5 branch:

slp-costs.c:7:3: note: Cost model analysis:
  Vector inside of loop cost: 32
  Vector prologue cost: 1033
  Vector epilogue cost: 0
  Scalar iteration cost: 64
  Scalar outside cost: 1
  Vector outside cost: 1033
  prologue iterations: 0
  epilogue iterations: 0
  Calculated minimum iters for profitability: 33


Ah, the fix that sneaked in and to be backported is

* tree-vect-loop.c (new_loop_vec_info):
...
(vect_estimate_min_profitable_iters): Use LOOP_VINFO_COMP_ALIAS_DDRS
to estimate alias versioning cost.

which is very simple.

Breakpoint 5, vect_estimate_min_profitable_iters (loop_vinfo=0x22847b0, 
ret_min_profitable_niters=0x7fffd7f0, 
ret_min_profitable_estimate=0x7fffd7ec)
at /space/rguenther/src/svn/gcc-5-branch/gcc/tree-vect-loop.c:2828
2828  unsigned len = LOOP_VINFO_MAY_ALIAS_DDRS (loop_vinfo).length ();
(gdb) n
2830vect_prologue);
(gdb) p len
$1 = 1024
(gdb) p loop_vinfo->comp_alias_ddrs.m_vec->m_vecpfx
$3 = {m_alloc = 1024, m_using_auto_storage = 0, m_num = 1}

so only one check is actually added but we account for 1024...

Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 229701)
+++ gcc/tree-vect-loop.c(working copy)
@@ -2825,7 +2825,7 @@ vect_estimate_min_profitable_iters (loop
   if (LOOP_REQUIRES_VERSIONING_FOR_ALIAS (loop_vinfo))
 {
   /*  FIXME: Make cost depend on complexity of individual check.  */
-  unsigned len = LOOP_VINFO_MAY_ALIAS_DDRS (loop_vinfo).length ();
+  unsigned len = LOOP_VINFO_COMP_ALIAS_DDRS (loop_vinfo).length ();
   (void) add_stmt_cost (target_cost_data, len, vector_stmt, NULL, 0,
vect_prologue);
   dump_printf (MSG_NOTE,

backport pre-approved.  With the above patch:

slp-costs.c:7:3: note: Cost model analysis:
  Vector inside of loop cost: 32
  Vector prologue cost: 10
  Vector epilogue cost: 0
  Scalar iteration cost: 64
  Scalar outside cost: 1
  Vector outside cost: 10
  prologue iterations: 0
  epilogue iterations: 0
  Calculated minimum iters for profitability: 1

[Bug middle-end/68251] [6 Regression] sorry, unimplemented: reverse storage order for BLKmode

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #4 from Eric Botcazou  ---
Thanks, I can reproduce.

[Bug tree-optimization/68234] tree-vrp pass need to be improved when handling ASSERT_EXPR

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Mon, 9 Nov 2015, jiwang at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68234
> 
> Jiong Wang  changed:
> 
>What|Removed |Added
> 
> Summary|tree-vrp pass need to be|tree-vrp pass need to be
>|improved when handling  |improved when handling
>|ASSERT/PLUS/MINUS/_EXPR and |ASSERT_EXPR
>|Phi node|
> 
> --- Comment #2 from Jiong Wang  ---
> (In reply to Richard Biener from comment #1)
> 
> > I think the issue is that we insert the assert in the first place or
> > that we intersect to a symbolic range this causes us to not use SCEV / loop
> > analysis to get at the range for c_1.  That is, in vrp_visit_phi_node
> > the early outs to varying: shouldn't skip
> > 
> >   /* If we dropped either bound to +-INF then if this is a loop
> >  PHI node SCEV may known more about its value-range.  */
> >   if ((cmp_min > 0 || cmp_min < 0
> >|| cmp_max < 0 || cmp_max > 0)
> >   && (l = loop_containing_stmt (phi))
> >   && l->header == gimple_bb (phi))
> > adjust_range_with_scev (&vr_result, l, phi, lhs);
> > 
> > sth like
> > 
> > Index: gcc/tree-vrp.c
> > ===
> > --- gcc/tree-vrp.c  (revision 229804)
> > +++ gcc/tree-vrp.c  (working copy)
> > @@ -8827,6 +8805,24 @@ update_range:
> >  
> >/* No match found.  Set the LHS to VARYING.  */
> >  varying:
> > +
> > +  /* If we dropped either bound to +-INF then if this is a loop
> > + PHI node SCEV may known more about its value-range.  */
> > +  if ((l = loop_containing_stmt (phi))
> > +  && l->header == gimple_bb (phi))
> > +{
> > +  adjust_range_with_scev (&vr_result, l, phi, lhs);
> > +
> > +  /* If we will end up with a (-INF, +INF) range, set it to
> > +VARYING.  Same if the previous max value was invalid for
> > +the type and we end up with vr_result.min > vr_result.max.  */
> > +  if (!((vrp_val_is_max (vr_result.max)
> > +&& vrp_val_is_min (vr_result.min))
> > +   || compare_values (vr_result.min,
> > +  vr_result.max) > 0))
> > +   goto update_range;
> > +}
> > +
> >set_value_range_to_varying (lhs_vr);
> >return SSA_PROP_VARYING;
> >  }
> > 
> > which ends up with
> > 
> > Value ranges after VRP:
> > 
> > c_1: [0, +INF]
> > 
> > as desired.  Maybe you can take the above and put it to testing.
> 
> Thanks for the explanation on those issues.
> 
> The "if" check needs to be guarded by vr_result.type == VR_RANGE, otherwise
> above draft patch passed my testing. bootstrapping on x86-64 and AArch64 OK. 
> no
> regresson on both.

Great.  Can you add a testcase and post the patch?

[Bug target/66326] Floating point exception with -mfpmath=387 and -fcilkplus.

[ienkovich at gcc dot gnu.org]

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

--- Comment #5 from Ilya Enkovich  ---
Author: ienkovich
Date: Mon Nov  9 10:12:34 2015
New Revision: 230008

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

2015-11-09  Igor Zamyatin  

PR target/66326
* runtime/config/x86/os-unix-sysdep.c (sysdep_save_fp_ctrl_state):
Use fnstcw instead fnstsw.


gcc/testsuite

2015-11-09  Igor Zamyatin  

PR target/66326
* g++.dg/cilk-plus/CK/pr66326.cc: New test.

Added:
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/pr66326.cc
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcilkrts/ChangeLog
trunk/libcilkrts/runtime/config/x86/os-unix-sysdep.c

[Bug tree-optimization/65447] AArch64: iv-opt causes bad addressing

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from amker at gcc dot gnu.org ---
fixed.

[Bug middle-end/68253] [6 Regression] conditional jump or move depends on uninitialized value in fold-const.c:5587

[ebotcazou at gcc dot gnu.org]

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

--- Comment #2 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Nov  9 10:45:00 2015
New Revision: 230011

URL: https://gcc.gnu.org/viewcvs?rev=230011&root=gcc&view=rev
Log:
PR middle-end/68253
* fold-const.c (fold_truth_andor_1): Initialize new variables to 0.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c

[Bug middle-end/68253] [6 Regression] conditional jump or move depends on uninitialized value in fold-const.c:5587

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
Thanks for the heads up.

[Bug libgomp/67141] wrong libgomp mutex initialisation order

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #10 from Thomas Schwinge  ---
Fixed on trunk and gcc-5-branch; confirmed fixed for the latter.

[Bug target/49526] extra move instruction for smmul

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #3 from ktkachov at gcc dot gnu.org ---
A patch for the smmul, smmla and smmls instructions is proposed at:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00686.html

Adding patterns for the rounding variants seems to expose some LRA ICE that
I'll analyse and report separate

[Bug target/68254] New: [4.9/5/6 Regression] ICE: in lra_set_insn_recog_data, at lra.c:954 with -O -fPIC and "X" asm input @ aarch64

[zsojka at seznam dot cz]

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

Bug ID: 68254
   Summary: [4.9/5/6 Regression] ICE: in lra_set_insn_recog_data,
at lra.c:954 with -O -fPIC and "X" asm input @ aarch64
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

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

Compiler output:
$ aarch64-unknown-linux-gnu-gcc testcase.c -O -fPIC 
testcase.c: In function 'foo':
testcase.c:7:1: internal compiler error: in lra_set_insn_recog_data, at
lra.c:954
 }
 ^
0x967431 lra_set_insn_recog_data(rtx_insn*)
/repo/gcc-trunk/gcc/lra.c:952
0x967507 lra_get_insn_recog_data
/repo/gcc-trunk/gcc/lra-int.h:486
0x967507 lra_update_insn_regno_info
/repo/gcc-trunk/gcc/lra.c:1574
0x967c07 lra_update_insn_regno_info
/repo/gcc-trunk/gcc/vec.h:1410
0x967c07 lra_push_insn_1
/repo/gcc-trunk/gcc/lra.c:1639
0x967c07 lra_push_insn
/repo/gcc-trunk/gcc/lra.c:1647
0x967c07 push_insns
/repo/gcc-trunk/gcc/lra.c:1690
0x969759 lra_process_new_insns(rtx_insn*, rtx_insn*, rtx_insn*, char const*)
/repo/gcc-trunk/gcc/lra.c:1736
0x97caf5 curr_insn_transform
/repo/gcc-trunk/gcc/lra-constraints.c:3919
0x97e5e6 lra_constraints(bool)
/repo/gcc-trunk/gcc/lra-constraints.c:4406
0x96a6dc lra(_IO_FILE*)
/repo/gcc-trunk/gcc/lra.c:2267
0x912bb9 do_reload
/repo/gcc-trunk/gcc/ira.c:5380
0x912bb9 execute
/repo/gcc-trunk/gcc/ira.c:5551
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ aarch64-unknown-linux-gnu-gcc -v 
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-229845-checking-yes-rtl-df-nographite-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --with-sysroot=/chroot/aarch64
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-229845-checking-yes-rtl-df-nographite-aarch64
Thread model: posix
gcc version 6.0.0 20151106 (experimental) (GCC) 


The failing assert is:
  /* It is a special insn like USE or CLOBBER.  We should
 recognize any regular insn otherwise LRA can do nothing
 with this insn.  */
  gcc_assert (GET_CODE (PATTERN (insn)) == USE
  || GET_CODE (PATTERN (insn)) == CLOBBER
  || GET_CODE (PATTERN (insn)) == ASM_INPUT);


Tested revisions:
trunk r229845 - ICE
5-branch r229829 - ICE
4_9-branch r229828 - ICE
4_8-branch r224828 - OK

[Bug rtl-optimization/67749] FAIL: gcc.dg/ifcvt-2.c scan-rtl-dump ce1 "3 true changes made"

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Mon Nov  9 11:40:17 2015
New Revision: 230014

URL: https://gcc.gnu.org/viewcvs?rev=230014&root=gcc&view=rev
Log:
[RTL-ifcvt] PR rtl-optimization/67749: Do not emit separate SET insn in IF-ELSE
case

PR rtl-optimization/67749
* ifcvt.c (noce_try_cmove_arith): Do not emit move in IF-ELSE
case before emitting the two blocks.  Instead modify the register
in the corresponding final insn of the basic block.

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

[Bug debug/66716] gomp4: libgomp.oacc-c/../libgomp.oacc-c-c++-common/kernels-loop.c -g ICE

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #5 from Thomas Schwinge  ---
Fixed in trunk in r229847,
.

[Bug target/68254] [4.9/5/6 Regression] ICE: in lra_set_insn_recog_data, at lra.c:954 with -O -fPIC and "X" asm input @ aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on all branches

[Bug rtl-optimization/67749] FAIL: gcc.dg/ifcvt-2.c scan-rtl-dump ce1 "3 true changes made"

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
This should be fixed on trunk now.

[Bug target/68254] [4.9/5/6 Regression] ICE: in lra_set_insn_recog_data, at lra.c:954 with -O -fPIC and "X" asm input @ aarch64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 63669.

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

[Bug middle-end/63669] [AArch64] gcc.dg/torture/asm-subreg-1.c ICEs with -fPIC or -mno-lra

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

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

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r225722.  There's another PR caused by this revision.

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
And that's PR66949, but that's an ICE, not wrong-code.

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

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

[Bug middle-end/68251] [6 Regression] sorry, unimplemented: reverse storage order for BLKmode

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

   Keywords|wrong-code  |rejects-valid
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2015-11/msg00930.ht
   ||ml
   Severity|normal  |critical

[Bug middle-end/68251] [6 Regression] sorry, unimplemented: reverse storage order for BLKmode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Nov  9 12:14:07 2015
New Revision: 230015

URL: https://gcc.gnu.org/viewcvs?rev=230015&root=gcc&view=rev
Log:
PR middle-end/68251
* tree-core.h (REF_REVERSE_STORAGE_ORDER): Move around.
* tree.h (REF_REVERSE_STORAGE_ORDER): Change to default_def_flag.
* tree-streamer-in.c (unpack_ts_base_value_fields): Adjust.
* tree-streamer-out.c (pack_ts_base_value_fields): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-core.h
trunk/gcc/tree-streamer-in.c
trunk/gcc/tree-streamer-out.c
trunk/gcc/tree.h

[Bug middle-end/68251] [6 Regression] sorry, unimplemented: reverse storage order for BLKmode

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Botcazou  ---
This should work again.  And I suspect that you won't be able to reduce the
testcase much further, as there is a size factor involved in the bug.

[Bug middle-end/68253] [6 Regression] conditional jump or move depends on uninitialized value in fold-const.c:5587

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Nov  9 12:31:50 2015
New Revision: 230017

URL: https://gcc.gnu.org/viewcvs?rev=230017&root=gcc&view=rev
Log:
PR middle-end/68253
* fold-const.c (fold_truth_andor_1): Initialize new variables to 0.

Modified:
branches/scalar-storage-order/gcc/fold-const.c

[Bug middle-end/68251] [6 Regression] sorry, unimplemented: reverse storage order for BLKmode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Nov  9 12:32:28 2015
New Revision: 230018

URL: https://gcc.gnu.org/viewcvs?rev=230018&root=gcc&view=rev
Log:
PR middle-end/68251
* tree-core.h (REF_REVERSE_STORAGE_ORDER): Move around.
* tree.h (REF_REVERSE_STORAGE_ORDER): Change to default_def_flag.
* tree-streamer-in.c (unpack_ts_base_value_fields): Adjust.
* tree-streamer-out.c (pack_ts_base_value_fields): Likewise.

Modified:
branches/scalar-storage-order/gcc/tree-core.h
branches/scalar-storage-order/gcc/tree-streamer-in.c
branches/scalar-storage-order/gcc/tree-streamer-out.c
branches/scalar-storage-order/gcc/tree.h

[Bug middle-end/68253] [6 Regression] conditional jump or move depends on uninitialized value in fold-const.c:5587

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
The leak has gone, thanks.

[Bug tree-optimization/56118] Piecewise vector / complex initialization from constants not combined

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Mon Nov  9 12:59:17 2015
New Revision: 230020

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

PR tree-optimization/56118
* tree-vectorizer.h (vect_find_last_scalar_stmt_in_slp): Declare.
* tree-vect-slp.c (vect_find_last_scalar_stmt_in_slp): Export.
* tree-vect-data-refs.c (vect_slp_analyze_node_dependences): New
function.
(vect_slp_analyze_data_ref_dependences): Instead of computing
all dependences of the region DRs just analyze the code motions
SLP vectorization will perform.  Remove SLP instances that
cannot have their store/load motions applied.
(vect_analyze_data_refs): Allow DRs without a vectype
in BB vectorization.

* gcc.dg/vect/no-tree-sra-bb-slp-pr50730.c: Adjust.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/no-tree-sra-bb-slp-pr50730.c
trunk/gcc/tree-vect-data-refs.c
trunk/gcc/tree-vect-slp.c
trunk/gcc/tree-vectorizer.h

[Bug tree-optimization/68234] tree-vrp pass need to be improved when handling ASSERT_EXPR

[jiwang at gcc dot gnu.org]

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

--- Comment #4 from Jiong Wang  ---
(In reply to rguent...@suse.de from comment #3)
> On Mon, 9 Nov 2015, jiwang at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68234
> > 
> > Jiong Wang  changed:
> > 
> >What|Removed |Added
> > 
> > Summary|tree-vrp pass need to be|tree-vrp pass need to be
> >|improved when handling  |improved when handling
> >|ASSERT/PLUS/MINUS/_EXPR and |ASSERT_EXPR
> >|Phi node|
> > 
> > --- Comment #2 from Jiong Wang  ---
> > (In reply to Richard Biener from comment #1)
> > 
> > > I think the issue is that we insert the assert in the first place or
> > > that we intersect to a symbolic range this causes us to not use SCEV / 
> > > loop
> > > analysis to get at the range for c_1.  That is, in vrp_visit_phi_node
> > > the early outs to varying: shouldn't skip
> > > 
> > >   /* If we dropped either bound to +-INF then if this is a loop
> > >  PHI node SCEV may known more about its value-range.  */
> > >   if ((cmp_min > 0 || cmp_min < 0
> > >|| cmp_max < 0 || cmp_max > 0)
> > >   && (l = loop_containing_stmt (phi))
> > >   && l->header == gimple_bb (phi))
> > > adjust_range_with_scev (&vr_result, l, phi, lhs);
> > > 
> > > sth like
> > > 
> > > Index: gcc/tree-vrp.c
> > > ===
> > > --- gcc/tree-vrp.c  (revision 229804)
> > > +++ gcc/tree-vrp.c  (working copy)
> > > @@ -8827,6 +8805,24 @@ update_range:
> > >  
> > >/* No match found.  Set the LHS to VARYING.  */
> > >  varying:
> > > +
> > > +  /* If we dropped either bound to +-INF then if this is a loop
> > > + PHI node SCEV may known more about its value-range.  */
> > > +  if ((l = loop_containing_stmt (phi))
> > > +  && l->header == gimple_bb (phi))
> > > +{
> > > +  adjust_range_with_scev (&vr_result, l, phi, lhs);
> > > +
> > > +  /* If we will end up with a (-INF, +INF) range, set it to
> > > +VARYING.  Same if the previous max value was invalid for
> > > +the type and we end up with vr_result.min > vr_result.max.  */
> > > +  if (!((vrp_val_is_max (vr_result.max)
> > > +&& vrp_val_is_min (vr_result.min))
> > > +   || compare_values (vr_result.min,
> > > +  vr_result.max) > 0))
> > > +   goto update_range;
> > > +}
> > > +
> > >set_value_range_to_varying (lhs_vr);
> > >return SSA_PROP_VARYING;
> > >  }
> > > 
> > > which ends up with
> > > 
> > > Value ranges after VRP:
> > > 
> > > c_1: [0, +INF]
> > > 
> > > as desired.  Maybe you can take the above and put it to testing.
> > 
> > Thanks for the explanation on those issues.
> > 
> > The "if" check needs to be guarded by vr_result.type == VR_RANGE, otherwise
> > above draft patch passed my testing. bootstrapping on x86-64 and AArch64 
> > OK. no
> > regresson on both.
> 
> Great.  Can you add a testcase and post the patch?

OK.

now I understand this patch actually done the range correction not in vrp1 but
in vrp2, as after vrp1 those trouble maker ASSERT_EXPR are removed, then in
vrp2, the tree is quite simplified that we invoke the scalar evolution to do a
final calculation to make sure we find as accurate information as possible. I
feel this is what we should have done originally, it is a general improvement
to range info calcuation.

Will combine this block of code with above similar code then send out the patch
with testcase.

[Bug go/68255] New: cgo-generated constructor not being called

[vogt at linux dot vnet.ibm.com]

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

Bug ID: 68255
   Summary: cgo-generated constructor not being called
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com
  Target Milestone: ---
  Host: s390x
Target: s390x

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

With the latest code from the Gcc-6 development branch, constructor functions
in packages may not be called.  (Test code attached, run with

 $ tar xf cgo-ling.tar
 $ cd cgo-link
 $ GOPATH=$(pwd)
 $ cd src/main
 $ go build
 $ ./cgo-link"
==> NULL pointer acces, crash
.)




-- src/main/main.go --
package main 
import "pack" 
func main () { 
pack.Foo() 
} 
-- END --

-- src/pack/pack.go --
package pack 

/* 
#include "c/c_code.c" 
*/ 
import "C" 

func Foo () { 
println(C.p_cfunc) 
} 
-- END --

-- src/pack/c/c_code.c --
#include  

typedef void (*cfunc_t)(void); 

static void cfunc(void) 
{ 
printf("hallo\n"); 
} 

const cfunc_t p_cfunc = cfunc; 
-- END --

The init function generated by cgo to initialize p_cfunc is not placed into the
executable:

 $ go build -x

-- snip --
...

ar cru $WORK/libpack.a $WORK/pack/_obj/_go_.o $WORK/pack/_obj/_cgo_defun.o
$WOR\
K/pack/_obj/_cgo_export.o $WORK/pack/_obj/pack.cgo2.o

...

.../bin/gccgo -I $WORK -I .../cgo-link/pkg/gccgo_linux_s390x -c -g
-fgo-relativ\
e-import-path=_.../cgo-link/src/main -o $WORK/main/_obj/_go_.o ./main.go 
ar cru $WORK/libmain.a $WORK/main/_obj/_go_.o 

.../bin/gccgo -o $WORK/main/_obj/exe/a.out $WORK/main/_obj/_go_.o -Wl,-(
$WORK/\
libpack.a -Wl,-) -Wl,-E 
cp $WORK/main/_obj/exe/a.out main 
-- snip --

The linker invocation triggered with the final gccgo command disposes of the
init() function generated by cgo, so p_cfund ends up unitinialised.  The
problem goes away if I put _go_.o into the link group with libpack.a.

While it's possible to do the same in C, the specific problem with the go tool
and cgo is that you have no direct control over the linker invocation.  I'm not
sure whether this is a bad invocation of the linker or a bug in the linker, but
it should be possible to fic that in the sources of the go tool in build.go.

--

This is probably the same problem as here:
/show_bug.cgi?id=65134

But the workaround mentioned there won't work because the init function is
generated by cgo.

[Bug tree-optimization/56118] Piecewise vector / complex initialization from constants not combined

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Cost model still rejects the original testcase.

[Bug target/68256] New: [6 regression] switching constant pools to rodata sections causes go bootstrap failure.

[ramana at gcc dot gnu.org]

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

Bug ID: 68256
   Summary: [6 regression] switching constant pools to rodata
sections causes go bootstrap failure.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ramana at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00839.html

[Bug target/68256] [6 regression] switching constant pools to rodata sections causes go bootstrap failure.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #1 from Ramana Radhakrishnan  ---
confirmed.

[Bug ipa/67811] [TM] ICE with try-block in transaction

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Henderson  ---
There's no change from .tmipa til .inline, so it's simply a
matter of not having diagnosed the problem earlier.

That said, the output looks right at a glance, so I'm not
sure what verify_flow_info is complaining about...

[Bug middle-end/68068] [6 Regression] ICE: in get_untransformed_body, at cgraph.c:3268

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #3 from Markus Trippelsdorf  ---
Seems to be fixed. Closing.

[Bug middle-end/67295] [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Sorry for getting back late on this. I'll try to give more detailed steps to
reproduce this.

I take my clean checkout of trunk from svn and do:

1) $ svn up -r226900
This is the revision before the copyrename patch.

2) I build a simple cc1 by doing:
$ cd 
$ $/configure --prefix=`pwd` --enable-languages=c,c++
--target=arm-none-eabi
$ make -j

Wait till it builds cc1.
The testcase is:
$ cat rev.c
extern short foos16 (short);

/* revshne */
short swaps16_cond (short x, int y)
{
  short z = x;
  if (y)
z = __builtin_bswap16 (x);
  return foos16 (z);
}

3) I compile the testcase:
$ /gcc/cc1  -march=armv7-a -O2 -marm rev.c

The output rev.s contains:
swaps16_cond:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
cmp r1, #0
revshne r0, r0
.L2:
b   foos16


4) Now I go back to the gcc svn checkout and do:
$ svn up -r226901
This is the revision with the copyrename patch.

5) Rebuild cc1 as in step 2.

6) Compile the testcase again:
$ /gcc/cc1  -march=armv7-a -O2 -marm rev.c

rev.s now contains:
swaps16_cond:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
cmp r1, #0
rev16ne r0, r0
uxthne  r0, r0
.L2:
sxthr0, r0
b   foos16


Hope this helps,
Kyrill

[Bug target/68256] [6 regression] switching constant pools to rodata sections causes go bootstrap failure.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug tree-optimization/68248] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in uniform_vector_p, at tree.c:10807

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Mon Nov  9 14:47:09 2015
New Revision: 230021

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

PR tree-optimization/68248
* tree-vect-generic.c (expand_vector_operations_1): Handle
scalar rhs2.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr68248.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-generic.c

[Bug ipa/67811] [TM] ICE with try-block in transaction

[rth at gcc dot gnu.org]

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

--- Comment #2 from Richard Henderson  ---
copy_bbs fails to duplicate the eh regions included within
the requested region.  This no doubt causes all sorts of 
bad follow-on effects, heretofore unobserved.

[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number

[krebbel at gcc dot gnu.org]

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

--- Comment #23 from Andreas Krebbel  ---
Author: krebbel
Date: Mon Nov  9 15:31:32 2015
New Revision: 230023

URL: https://gcc.gnu.org/viewcvs?rev=230023&root=gcc&view=rev
Log:
[PR debug/67192] Fix C loops' back-jump location

gcc/c/ChangeLog:

PR debug/67192
* c-parser.c (c_parser_while_statement): Finish the loop before
parsing ahead for misleading indentation.
(c_parser_for_statement): Likewise.

gcc/testsuite/ChangeLog:

PR debug/67192
* gcc.dg/guality/pr67192.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/guality/pr67192.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number

[krebbel at gcc dot gnu.org]

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

--- Comment #24 from Andreas Krebbel  ---
Author: krebbel
Date: Mon Nov  9 15:35:10 2015
New Revision: 230024

URL: https://gcc.gnu.org/viewcvs?rev=230024&root=gcc&view=rev
Log:
[PR debug/67192] Further fix C loops' back-jump location

gcc/c/ChangeLog:

PR debug/67192
* c-typeck.c (c_finish_loop): For unconditional loops, set the
location of the backward-goto to the start of the loop body.

gcc/testsuite/ChangeLog:

PR debug/67192
* gcc.dg/guality/pr67192.c (f3, f4): New functions.
(main): Invoke them.


Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/guality/pr67192.c

[Bug target/68129] [5/6 Regression] ICE: in simplify_const_binary_operation, at simplify-rtx.c:3961 (TARGET_SUPPORTS_WIDE_INT == 0) with -fno-split-wide-types @ aarch64

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Mon Nov  9 15:53:26 2015
New Revision: 230029

URL: https://gcc.gnu.org/viewcvs?rev=230029&root=gcc&view=rev
Log:
[AArch64] PR target/68129: Define TARGET_SUPPORTS_WIDE_INT

PR target/68129
* config/aarch64/aarch64.h (TARGET_SUPPORTS_WIDE_INT): Define to 1.
* config/aarch64/aarch64.c (aarch64_print_operand, CONST_DOUBLE):
Delete VOIDmode case.  Assert that mode is not VOIDmode.
* config/aarch64/predicates.md (const0_operand): Remove const_double
match.

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


Added:
trunk/gcc/testsuite/gcc.dg/pr68129_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.h
trunk/gcc/config/aarch64/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug c/68107] Non-VLA type whose size is half or more of the address space constructed via a pointer

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c/68107] Non-VLA type whose size is half or more of the address space constructed via a pointer

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
The same seems to apply for the C++ FE as well.

[Bug c++/68257] New: Reject empty abi_tag attribute on inline namespace

[sbergman at redhat dot com]

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

Bug ID: 68257
   Summary: Reject empty abi_tag attribute on inline namespace
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

Quoting  "Re: abi_tag
questions" by Jonathan Wakely:

> On 4 November 2015 at 14:37, Stephan Bergmann  wrote:
>> I have two questions regarding the abi_tag attribute (as documented at
>> ):
[...]
>> 2  "The argument can be a list of strings of arbitrary length."
>>
>> Does that mean the list can be empty?
>>
>>> void f() __attribute__((__abi_tag__()));
>>
>> fails with "error: wrong number of arguments specified for ‘__abi_tag__’
>> attribute" while
>>
>>> inline namespace n __attribute__((__abi_tag__())) {}
>>
>> is accepted by recent trunk GCC (as well as older versions).
>
> That seems like a bug.

That would apparently have flagged the code fixed with
 "Fix abi_tag in
special modes."

[Bug c++/68258] New: core 879 Missing built-in comparison operators for pointer types not supported

[derrick at ca dot ibm.com]

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

Bug ID: 68258
   Summary: core 879  Missing built-in comparison operators for
pointer types not supported
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: derrick at ca dot ibm.com
  Target Milestone: ---

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#879
not implemented, while clang3.6 works.
Code:

#include 
struct X_
{
operator std::nullptr_t() { return nullptr; }
};
struct Y_
{
operator std::nullptr_t() { return nullptr; }
};
int main()
{
X_ x;
Y_ y;
bool z = x != y;

return 0;
}

Compile error:
main.cpp: In function 'int main()':

main.cpp:15:28: error: no match for 'operator!=' (operand types are 'X_' and
'Y_')

 bool z = x != y;

^

[Bug sanitizer/68259] New: [6 Regression][UBSAN] ICE tree check: expected record_type or union_type or qual_union_type or array_type, have reference_type in reverse_storage_order_for_component_p, at t

[burnus at gcc dot gnu.org]

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

Bug ID: 68259
   Summary: [6 Regression][UBSAN] ICE tree check: expected
record_type or union_type or qual_union_type or
array_type, have reference_type in
reverse_storage_order_for_component_p, at tree.h:4392
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

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

Compiling attached test case with today's GCC trunk using
  g++ -S -O0 -fsanitize=undefined
fails as follows:

test.ii:77:1: internal compiler error: tree check: expected record_type or
union_type or qual_union_type or array_type, have reference_type in
reverse_storage_order_for_component_p, at tree.h:4392
 }
 ^

0xf7589c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9587
0xa10907 tree_check4(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code, tree_code)
../../gcc/tree.h:3002
0xa10907 reverse_storage_order_for_component_p
../../gcc/tree.h:4392
0xa10907 get_inner_reference(tree_node*, long*, long*, tree_node**,
machine_mode*, int*, int*, int*, bool)
../../gcc/expr.c:6901
0x8e6182 get_object_alignment_2
../../gcc/builtins.c:261
0x8e5f63 get_pointer_alignment_1(tree_node*, unsigned int*, unsigned long*)
../../gcc/builtins.c:429
0x8e687b get_pointer_alignment(tree_node*)
../../gcc/builtins.c:498
0x8c80e1 ubsan_maybe_instrument_reference_or_call
../../gcc/c-family/c-ubsan.c:414
0x8c9c02 ubsan_maybe_instrument_reference(tree_node*)
../../gcc/c-family/c-ubsan.c:441
0x81d6ca cp_genericize_r
../../gcc/cp/cp-gimplify.c:1319

[Bug debug/66728] [5 Regression] CONST_WIDE_INT causes corrupted DWARF debug info

[mrs at gcc dot gnu.org]

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

--- Comment #11 from mrs at gcc dot gnu.org  ---
Author: mrs
Date: Mon Nov  9 18:27:43 2015
New Revision: 230039

URL: https://gcc.gnu.org/viewcvs?rev=230039&root=gcc&view=rev
Log:
PR debug/66728
* dwarf2out.c (get_full_len): Return a value based upon the actual
precision needed for the value.
(add_const_value_attribute): Use a maximal wide-int for
CONST_WIDE_INTs, not VOIDmode.
(output_die): Don't ever output NULL with printf.

* rtl.h (get_precision of rtx_mode_t): Ensure we never process
BLKmode nor VOIDmode values.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/dwarf2out.c
branches/gcc-5-branch/gcc/rtl.h

[Bug debug/66728] [5 Regression] CONST_WIDE_INT causes corrupted DWARF debug info

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
  Known to work||5.2.1
 Resolution|--- |FIXED

--- Comment #12 from mrs at gcc dot gnu.org  ---
Fixed.

[Bug c++/57854] Would like to have a warning for virtual overrides without C++11 "override" keyword

[nachms+gcc at gmail dot com]

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

Nach  changed:

   What|Removed |Added

 CC||nachms+gcc at gmail dot com

--- Comment #6 from Nach  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Thiago Macieira from comment #0)
> > 
> > It should be in -Weffc++.
> 
> Not unless a new C++11 edition of Effective C++ recommends using override on
> all overriding functions, and not unless we update -Weffc++ to correspond to
> something other than the first edition.
> 

Modern Effective C++ Item 12 is that every virtual derived function should make
use of the override keyword.

Therefore, -Weffc++ should now include this new warning.

[Bug fortran/68225] ICE with -Wrealloc-lhs-all on structure constructor with allocatable components

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #4 from Gerhard Steinmetz  
---
>
> Am I correct to understand that this error is bogus for Fortran 2008 (at 
> least)? 

That feature is new in F2008 :
A structure constructor can omit the value for an allocatable component.


Further investigations show, that analogous examples with allocatable
arrays are correct (see examples below). Therefore, basically it's an
issue with allocatable scalars (of any type).

[Bug fortran/68225] ICE with -Wrealloc-lhs-all on structure constructor with allocatable scalar component(s)

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #5 from Gerhard Steinmetz  
---
$ cat yy0.f90
program p
   type t
  integer, allocatable :: a(:)
   end type
   type(t) :: x
   x = t()
   print *, allocated(x%a), x%a
end

$ gfortran -g -O0 -Wall -fcheck=all  yy0.f90
$ a.out
 F

---

$ cat yy1.f90
program p
   type t
  integer, allocatable :: a(:)
   end type
   type(t) :: x
   x = t([1, 2])
   print *, allocated(x%a), x%a
end

$ gfortran -g -O0 -Wall -fcheck=all  yy1.f90
$ a.out
 T   1   2

---

$ cat zz0.f90
program p
   type t
  integer, allocatable :: a(:)
   end type
   type, extends(t) :: t2
  integer, allocatable :: b(:)
   end type
   type(t2) :: x
   x = t2()
   print *, allocated(x%a), x%a
   print *, allocated(x%b), x%b
end

$ gfortran -g -O0 -Wall -fcheck=all  zz0.f90
$ a.out
 F
 F

---

$ cat zz1.f90
program p
   type t
  integer, allocatable :: a(:)
   end type
   type, extends(t) :: t2
  integer, allocatable :: b(:)
   end type
   type(t2) :: x
   x = t2([1])
   print *, allocated(x%a), x%a
   print *, allocated(x%b), x%b
end

$ gfortran -g -O0 -Wall -fcheck=all  zz1.f90
$ a.out
 T   1
 F

---

$ cat zz2.f90
program p
   type t
  integer, allocatable :: a(:)
   end type
   type, extends(t) :: t2
  integer, allocatable :: b(:)
   end type
   type(t2) :: x
   x = t2(null(), [1, 2])
   print *, allocated(x%a), x%a
   print *, allocated(x%b), x%b
end

$ gfortran -g -O0 -Wall -fcheck=all  zz2.f90
$ a.out
 F
 T   1   2

[Bug fortran/66494] [4.9/5/6 Regression] ICE on using same name for embedded subroutine

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #4 from Gerhard Steinmetz  
---
Indeed it is. 

And prefix specs recursive and non_recursive are not relevant here.

[Bug sanitizer/68260] New: false positive with tsan

[claprix at yandex dot ru]

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

Bug ID: 68260
   Summary: false positive with tsan
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: claprix at yandex dot ru
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Hello.

gcc --version
gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010

https://gist.github.com/kevgs/31a528aa442fd39f639a

[Bug sanitizer/68260] false positive with tsan

[dvyukov at google dot com]

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

Dmitry Vyukov  changed:

   What|Removed |Added

 CC||dvyukov at google dot com

--- Comment #1 from Dmitry Vyukov  ---
gcc does not instrument atomic operations:

004a73d0 <_ZN4spin6unlockEv>:

void unlock() { flag.clear(std::memory_order_release); }
  4a73d0:   55  push   %rbp
  4a73d1:   48 89 e5mov%rsp,%rbp
  4a73d4:   48 83 ec 10 sub$0x10,%rsp
  4a73d8:   48 8b 45 08 mov0x8(%rbp),%rax
  4a73dc:   48 89 7d f0 mov%rdi,-0x10(%rbp)
  4a73e0:   48 89 c7mov%rax,%rdi
  4a73e3:   e8 68 4f fd ff  callq  47c350 <__tsan_func_entry>
  4a73e8:   be 03 00 00 00  mov$0x3,%esi
  4a73ed:   48 8b 45 f0 mov-0x10(%rbp),%rax
  4a73f1:   48 89 45 f8 mov%rax,-0x8(%rbp)
  4a73f5:   48 8b 7d f8 mov-0x8(%rbp),%rdi
  4a73f9:   e8 62 02 00 00  callq  4a7660
<_ZNSt11atomic_flag5clearESt12memory_order>
  4a73fe:   e8 fd 4f fd ff  callq  47c400 <__tsan_func_exit>
  4a7403:   48 83 c4 10 add$0x10,%rsp
  4a7407:   5d  pop%rbp
  4a7408:   c3  retq   



FWIW this programs works fine with clang.

[Bug sanitizer/68259] [6 Regression][UBSAN] ICE tree check: expected record_type or union_type or qual_union_type or array_type, have reference_type in reverse_storage_order_for_component_p, at tree.h

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-09
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

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

[Bug fortran/44348] ICE in build_function_decl

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #11 from Gerhard Steinmetz  
---
As a side note, with a slightly modified example b from comment 3 and

$ gfortran --version
GNU Fortran (SUSE Linux) 5.2.1 20151008 [gcc-5-branch revision 228597]


$ cat pr44348_c3b_modified.f90
FUNCTION f2() RESULT(g)
  real :: g
contains
  real FUNCTION g()
  END FUNCTION
END FUNCTION


$ gfortran -g -O0 -Wall -fcheck=all pr44348_c3b_modified.f90
pr44348_c3b_modified.f90:4.17:

  real FUNCTION g()
 1
pr44348_c3b_modified.f90:1.23:

FUNCTION f2() RESULT(g)
   2
Error: Procedure 'g' at (1) has an explicit interface and must not have
attributes declared at (2)

f951: internal compiler error: Segmentation fault


---

With gfortran 4.9.0 :

$ gfortran-4.9 -g -O0 -Wall -fcheck=all pr44348_c3b_modified.f90
pr44348_c3b_modified.f90:4.17:

  real FUNCTION g()
 1
pr44348_c3b_modified.f90:1.23:

FUNCTION f2() RESULT(g)
   2
Error: Procedure 'g' at (1) has an explicit interface and must not have
attributes declared at (2)
pr44348_c3b_modified.f90:4.19:

  real FUNCTION g()
   1
Error: Symbol 'g' at (1) already has basic type of REAL
pr44348_c3b_modified.f90:6.3:

END FUNCTION
   1
Error: Expecting END PROGRAM statement at (1)

[Bug sanitizer/68259] [6 Regression][UBSAN] ICE tree check: expected record_type or union_type or qual_union_type or array_type, have reference_type in reverse_storage_order_for_component_p, at tree.h

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started with r229965 aka Merge of the scalar-storage-order branch.

[Bug sanitizer/68259] [6 Regression][sso] tree checking failure in reverse_storage_order_for_component_p, at tree.h:4392

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
Summary|[6 Regression][sso][UBSAN]  |[6 Regression][sso] tree
   |ICE tree check: expected|checking failure in
   |record_type or union_type   |reverse_storage_order_for_c
   |or qual_union_type or   |omponent_p, at tree.h:4392
   |array_type, have|
   |reference_type in   |
   |reverse_storage_order_for_c |
   |omponent_p, at tree.h:4392  |

--- Comment #3 from Eric Botcazou  ---
I can reproduce, but the ASAN tree doesn't look valid to me, it's a
COMPONENT_REF of a REFERENCE_TYPE.  I guess I can kludge around it though
(there is already such a kludge for invalid Fortran trees).

[Bug middle-end/68259] [6 Regression][sso] tree checking failure in reverse_storage_order_for_component_p, at tree.h:4392

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|sanitizer   |middle-end

--- Comment #4 from Eric Botcazou  ---
Recategorizing.

[Bug target/68261] New: GCC needs to use optimized version of memcpy

[geir at cray dot com]

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

Bug ID: 68261
   Summary: GCC needs to use optimized version of memcpy
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geir at cray dot com
  Target Milestone: ---

The memcpy routine for GCC needs to be faster.  The following test case shows
that the Intel compiler implementation of memcpy is over twice as fast as GCC. 
I realize that memcpy is a part of GLIBC, but the GCC compiler should take
advantage of the targetting information being provided and the context of the
memcpy in order to provide more optimal code:

$ cat test_memcpy.cpp 
#include   
#include  
#include 
#include

extern "C" void memcpy_custom(double* out, double* in, int length);

int main(int argn, char** argv)
{  
int repeat = 200;  
int N = (1 << 20); 
std::vector inp(N, 1);
std::vector out(N, 2);

double t = -omp_get_wtime();
if (argn == 1)  
{   
for (int i = 0; i < repeat; i++)
{   
memcpy(&out[0], &inp[0], N * sizeof(double));
}
}
else 
{
for (int i = 0; i < repeat; i++) 
{
memcpy_custom(&out[0], &inp[0], N);  
}
}
t += omp_get_wtime();

printf("performance: %.4f MB/sec.\n", repeat * N * sizeof(double) / t / (1
<< 20)); 
}   
$ cat memcpy_custom.cpp
extern "C" void memcpy_custom(double* out, double* in, int length)  
{   
for (int i = 0; i < length; i++) out[i] = in[i];
} 
$

  GCC g++ performance:

$ g++ --version
g++ (GCC) 5.1.0 20150422 (Cray Inc.)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++ -march=corei7-avx -o gcc.out -O3 -fopenmp memcpy_custom.cpp
test_memcpy.cpp
$  ./gcc.out
performance: 6977.5857 MB/sec.
$


 Intel icpc performance:

$ icpc --version
icpc (ICC) 15.0.3 20150407
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

$ icpc -mavx -o intel.out -O3 -qopenmp memcpy_custom.cpp test_memcpy.cpp
$ ./intel.out   
performance: 13055.0563 MB/sec.
$


Performance of GCC can be improved by implementing a simple "custom"
version of memcpy:

$ ./gcc.out 1   
performance: 11619.4630 MB/sec. 
$ ./intel.out 1 
performance: 13068.3777 MB/sec. 
$

[Bug c++/68262] New: Ill-formed function pointer declaration acts as multi-line comment until ;

[yaghmour.shafik at gmail dot com]

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

Bug ID: 68262
   Summary: Ill-formed function pointer declaration acts as
multi-line comment until ;
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yaghmour.shafik at gmail dot com
  Target Milestone: ---

Given the following code:

#include 

int main()
{
   void (*) {}
We could go on and on
line after line
and no errors?  
;
std::cout << "hello\n" ;
}

live example here http://melpon.org/wandbox/permlink/iWzF2dKUBxZ3NOMn

What looks like an ill-formed function pointer declaration does not generate a
diagnostic and allows complete none sense until a ; is reached. 

After that the compiler seems to go on as if nothing odd has happened. 

This seems to go back as far as 4.4.7 and version 4.3.6 does not seem to have
this bug.

[Bug target/68263] New: Vector "*mov_internal" fails to handle misaligned load/store from reload

[hjl.tools at gmail dot com]

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

Bug ID: 68263
   Summary: Vector "*mov_internal" fails to handle
misaligned load/store from reload
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: julia.koval at intel dot com, ubizjak at gmail dot com
  Target Milestone: ---
Target: x86

On Linux/ia32 with SSE2 enabled, r230050 gave:

FAIL: gcc.target/i386/iamcu/test_passing_floats.c execution,  -O3 -g 

Reload generates

(insn 153 7 9 2 (set (mem/c:V4SF (plus:SI (reg/f:SI 7 sp)
(const_int 16 [0x10])) [7 %sfp+-16 S16 A32])
(reg:V4SF 22 xmm1 [88])) gcc.target/i386/iamcu/test_passing_floats.c:49
1210 {*movv4sf_internal}
 (nil))

in test_floats_on_stack.  But sse.md has

(define_insn "*mov_internal"
  [(set (match_operand:VMOVE 0 "nonimmediate_operand"   "=v,v ,m")
(match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand"  "C
,vm,v"))]
  "TARGET_SSE
   && (register_operand (operands[0], mode)
   || register_operand (operands[1], mode))"
{
...
   {
case MODE_V16SF:
case MODE_V8SF:
case MODE_V4SF:
  if (TARGET_AVX
  && (misaligned_operand (operands[0], mode)
  || misaligned_operand (operands[1], mode)))
return "vmovups\t{%1, %0|%0, %1}";
  else
return "%vmovaps\t{%1, %0|%0, %1}";

case MODE_V8DF:
case MODE_V4DF:
case MODE_V2DF:
  if (TARGET_AVX
  && (misaligned_operand (operands[0], mode)
  || misaligned_operand (operands[1], mode)))
return "vmovupd\t{%1, %0|%0, %1}";
  else
return "%vmovapd\t{%1, %0|%0, %1}";

case MODE_OI:
case MODE_TI:
  if (TARGET_AVX
  && (misaligned_operand (operands[0], mode)
  || misaligned_operand (operands[1], mode)))
return TARGET_AVX512VL ? "vmovdqu64\t{%1, %0|%0, %1}"
   : "vmovdqu\t{%1, %0|%0, %1}";
  else
return TARGET_AVX512VL ? "vmovdqa64\t{%1, %0|%0, %1}"
   : "%vmovdqa\t{%1, %0|%0, %1}";

Misaligned load/store are only handled for AVX, not SSE.

[Bug middle-end/68259] [6 Regression][sso] tree checking failure in reverse_storage_order_for_component_p, at tree.h:4392

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Nov  9 22:40:44 2015
New Revision: 230056

URL: https://gcc.gnu.org/viewcvs?rev=230056&root=gcc&view=rev
Log:
PR middle-end/68259
* tree.h (reverse_storage_order_for_component_p) :
Check that the type of the first operand is an aggregate type.

Added:
trunk/gcc/testsuite/g++.dg/ubsan/pr68259.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.h

[Bug middle-end/68259] [6 Regression][sso] tree checking failure in reverse_storage_order_for_component_p, at tree.h:4392

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Nov  9 22:42:14 2015
New Revision: 230057

URL: https://gcc.gnu.org/viewcvs?rev=230057&root=gcc&view=rev
Log:
PR middle-end/68259
* tree.h (reverse_storage_order_for_component_p) :
Check that the type of the first operand is an aggregate type.

Modified:
branches/scalar-storage-order/gcc/tree.h

[Bug middle-end/68259] [6 Regression][sso] tree checking failure in reverse_storage_order_for_component_p, at tree.h:4392

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #7 from Eric Botcazou  ---
This should work again.

[Bug tree-optimization/68264] New: tree-call-cdce wrongly uses ordered comparisons

[jsm28 at gcc dot gnu.org]

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

Bug ID: 68264
   Summary: tree-call-cdce wrongly uses ordered comparisons
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

When tree-call-cdce.c:gen_conditions_for_domain generates comparisons to test
if a function argument is within a range for which errno cannot be set, it uses
ordered comparisons LT_EXPR LE_EXPR GT_EXPR GE_EXPR.  But these will raise
"invalid" for quiet NaNs, when the functions should generally return a quiet
NaN with no exceptions raised.  Unordered comparisons should be used instead.

[Bug target/57845] ICE with -freg-struct-return on SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Nov 10 00:45:03 2015
New Revision: 230074

URL: https://gcc.gnu.org/viewcvs?rev=230074&root=gcc&view=rev
Log:
PR target/57845
* config/sparc/sparc.c (sparc_function_value_1): In 32-bit mode, do
not promote the mode for aggregate types.

Added:
trunk/gcc/testsuite/gcc.target/sparc/sparc-ret-1.c
  - copied unchanged from r230016,
trunk/gcc/testsuite/gcc.target/sparc/sparc-ret.c
trunk/gcc/testsuite/gcc.target/sparc/sparc-ret-2.c
Removed:
trunk/gcc/testsuite/gcc.target/sparc/sparc-ret.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.c
trunk/gcc/testsuite/ChangeLog

[Bug target/57845] ICE with -freg-struct-return on SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Nov 10 00:47:28 2015
New Revision: 230076

URL: https://gcc.gnu.org/viewcvs?rev=230076&root=gcc&view=rev
Log:
PR target/57845
* config/sparc/sparc.c (sparc_function_value_1): In 32-bit mode, do
not promote the mode for aggregate types.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/sparc/sparc-ret-1.c
  - copied unchanged from r228932,
branches/gcc-5-branch/gcc/testsuite/gcc.target/sparc/sparc-ret.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/sparc/sparc-ret-2.c
  - copied unchanged from r230074,
trunk/gcc/testsuite/gcc.target/sparc/sparc-ret-2.c
Removed:
branches/gcc-5-branch/gcc/testsuite/gcc.target/sparc/sparc-ret.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/sparc/sparc.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/57845] ICE with -freg-struct-return on SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Nov 10 00:49:05 2015
New Revision: 230077

URL: https://gcc.gnu.org/viewcvs?rev=230077&root=gcc&view=rev
Log:
PR target/57845
* config/sparc/sparc.c (sparc_function_value_1): In 32-bit mode, do
not promote the mode for aggregate types.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/sparc/sparc-ret-1.c
  - copied unchanged from r228932,
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/sparc/sparc-ret.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/sparc/sparc-ret-2.c
  - copied unchanged from r230076,
trunk/gcc/testsuite/gcc.target/sparc/sparc-ret-2.c
Removed:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/sparc/sparc-ret.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/sparc/sparc.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/57845] ICE with -freg-struct-return on SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Version|4.9.0   |4.9.4
 Resolution|--- |FIXED

--- Comment #14 from Eric Botcazou  ---
Fixed on all active branches but -freg-struct-return comes with no warranty.

[Bug target/68261] GCC needs to use optimized version of memcpy

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Note glibc does provide a memcpy which is optimized for each target via ifuncs.
What version of glibc are you running.

[Bug c++/68265] New: Arbitrary syntactic nonsense silently accepted after 'int (*){}' until the next close brace

[zackw at panix dot com]

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

Bug ID: 68265
   Summary: Arbitrary syntactic nonsense silently accepted after
'int (*){}' until the next close brace
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zackw at panix dot com
  Target Milestone: ---

(From https://stackoverflow.com/questions/33614455/ :)

The C++ compiler fails to diagnose ill-formed constructs such as

  int main()
  {
  int (*) {}
 any amount of syntactic nonsense
 on multiple lines, with *punctuation* and ++operators++ even...
 will be silently discarded
 until the next close brace
  }

With -pedantic -std=c++98 you do get "warning: extended initializer lists only
available with -std=c++11 or -std=gnu++11", but with -std=c++11, not a peep.

If any one (or more) of the tokens 'int ( * ) { }' are removed, you do get an
error.  Also, the C compiler does not have the same bug.

[Bug c++/67927] array new expression with excessive number of elements not diagnosed

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Tue Nov 10 02:23:34 2015
New Revision: 230081

URL: https://gcc.gnu.org/viewcvs?rev=230081&root=gcc&view=rev
Log:
PR c++/67913 - new expression with negative size not diagnosed
PR c++/67927 - array new expression with excessive number of elements
   not diagnosed 

gcc/cp/
* call.c (build_operator_new_call): Do not assume size_check
is non-null, analogously to the top half of the function.
* init.c (build_new_1): Detect and diagnose array sizes in
excess of the maximum of roughly SIZE_MAX / 2.
Insert a runtime check only for arrays with a non-constant size.
(build_new): Detect and diagnose negative array sizes.

gcc/testsuite/
* init/new45.C: New test to verify that operator new is invoked
with or without overhead for a cookie.
* init/new44.C: New test for placement new expressions for arrays
with excessive number of elements.
* init/new43.C: New test for placement new expressions for arrays
with negative number of elements.
* other/new-size-type.C: Expect array new expression with
an excessive number of elements to be rejected.

Added:
trunk/gcc/testsuite/g++.dg/init/new43.C
trunk/gcc/testsuite/g++.dg/init/new44.C
trunk/gcc/testsuite/g++.dg/init/new45.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/other/new-size-type.C

[Bug c++/67913] new expression with negative size not diagnosed

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Tue Nov 10 02:23:34 2015
New Revision: 230081

URL: https://gcc.gnu.org/viewcvs?rev=230081&root=gcc&view=rev
Log:
PR c++/67913 - new expression with negative size not diagnosed
PR c++/67927 - array new expression with excessive number of elements
   not diagnosed 

gcc/cp/
* call.c (build_operator_new_call): Do not assume size_check
is non-null, analogously to the top half of the function.
* init.c (build_new_1): Detect and diagnose array sizes in
excess of the maximum of roughly SIZE_MAX / 2.
Insert a runtime check only for arrays with a non-constant size.
(build_new): Detect and diagnose negative array sizes.

gcc/testsuite/
* init/new45.C: New test to verify that operator new is invoked
with or without overhead for a cookie.
* init/new44.C: New test for placement new expressions for arrays
with excessive number of elements.
* init/new43.C: New test for placement new expressions for arrays
with negative number of elements.
* other/new-size-type.C: Expect array new expression with
an excessive number of elements to be rejected.

Added:
trunk/gcc/testsuite/g++.dg/init/new43.C
trunk/gcc/testsuite/g++.dg/init/new44.C
trunk/gcc/testsuite/g++.dg/init/new45.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/other/new-size-type.C

[Bug c++/67913] new expression with negative size not diagnosed

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fix committed in r230081.

[Bug c++/67927] array new expression with excessive number of elements not diagnosed

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fix committed in r230081.

[Bug bootstrap/68231] [6 Regression] bootstrap failure after placement new

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Sebor  ---
Today's powerpc-ibm-aix7.1.0.0 test results
(http://gcc.gnu.org/ml/gcc-testresults/2015-11/msg00887.html) look free of the
test failures mentioned in comment #6.  Resolving as fixed.

[Bug c++/68266] New: pointers to arrays of excessive size not diagnosed

[msebor at gcc dot gnu.org]

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

Bug ID: 68266
   Summary: pointers to arrays of excessive size not diagnosed
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In C mode, GCC issues an error for pointers to arrays of excessive size such as
the one in the program below.  However, in C++ mode, it fails to diagnose the
same invalid constructs.

$ cat u.cpp && /build/gcc-trunk-svn/gcc/xg++ -B /build/gcc-trunk-svn/gcc -S
-Wall -Wextra -Wpedantic -o /dev/tty u.cpp
typedef __typeof__ (sizeof 0) size_t;

typedef int (*A)[__SIZE_MAX__];
.file   "u.cpp"
.ident  "GCC: (GNU) 6.0.0 20151108 (experimental)"
.section.note.GNU-stack,"",@progbits
$

[Bug middle-end/68251] [6 Regression] sorry, unimplemented: reverse storage order for BLKmode

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #8 from Joost VandeVondele  
---
Created attachment 36671
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36671&action=edit
reduced testcase

thanks, the issue is fixed indeed. Attached is the reduced testcase, about 1000
lines remain, but at least it can be compiled in ~2s.