[Bug rtl-optimization/68330] [6 Regression]: FAIL: gcc.target/alpha/pr42269-1.c scan-assembler-not addl on alpha-linux-gnu

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

[Bug fortran/47266] Optimization: Declare PRIVATE module procedures as "TREE_PUBLIC = 0" ("static function")

[dominiq at gcc dot gnu.org]

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

--- Comment #6 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Fri Nov 13 10:58:53 2015
New Revision: 230298

URL: https://gcc.gnu.org/viewcvs?rev=230298=gcc=rev
Log:
2015-11-13  Dominique d'Humieres 

PR fortran/47266
* gfortran.dg/warn_unused_function_2.f90: New test.


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

[Bug ipa/68331] New: [meta-bug] fipa-pta issues

[vries at gcc dot gnu.org]

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

Bug ID: 68331
   Summary: [meta-bug] fipa-pta issues
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

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

1)
we lack good testing coverage for IPA PTA so wrong-code bugs might still exist

2)
IPA PTA can use a _lot_ of memory and compile-time

3)
for existing wrong-code issues I have merely dumbed down the use of the
analysis result resulting in weaker alias analysis compared to the local PTA
(for some cases)

Because of 2 and no good way to avoid this I decided to not make
fixing 3 a priority (and 1 still holds).

[Bug c++/68295] internal compiler error / segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-cygwin
   Host||cygwin

--- Comment #3 from Richard Biener  ---
Works for me on x86_64-linux.

[Bug rtl-optimization/68328] [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=68328

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.8.5
   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

[Bug fortran/47266] Optimization: Declare PRIVATE module procedures as "TREE_PUBLIC = 0" ("static function")

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #8 from Dominique d'Humieres  ---
In comment 6

* gfortran.dg/warn_unused_function_2.f90: New test.

should be

* gfortran.dg/module_private_2.f90: New test.

The typo has been fixed in the ChangeLog.

Closing as FIXED. Please file new PR(s) for remaining issue(s).

[Bug fortran/36854] [meta-bug] fortran front-end optimization

[dominiq at lps dot ens.fr]

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

Bug 47266 Summary: Optimization: Declare PRIVATE module procedures as 
"TREE_PUBLIC = 0" ("static function")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47266

   What|Removed |Added

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

[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Can you attach preprocessed source for x32?

[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to Richard Biener from comment #11)
> Can you attach preprocessed source for x32?

Ah, it's in the tar file.

[Bug c++/68295] internal compiler error / segmentation fault

[tho...@maier-komor.de]

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

--- Comment #4 from Thomas Maier-Komor  ---
(In reply to Richard Biener from comment #3)
> Works for me on x86_64-linux.

Yes - it seems to be cygwin specific...

[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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/68332] [6 Regression] ICE: in rs6000_is_valid_mask, at config/rs6000/rs6000.c:17052 with __sync_and_and_fetch() @ powerpc

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  ---
Statistics for other variants:
  4  internal compiler error: RTL check: expected code 'const_int', have
'mem' in rs6000_is_valid_mask, at config/rs6000/rs6000.c:17052
  4  internal compiler error: RTL check: expected code 'const_int', have
'subreg' in rs6000_is_valid_mask, at config/rs6000/rs6000.c:17052
 16  internal compiler error: RTL check: expected code 'const_int', have
'reg' in rs6000_is_valid_mask, at config/rs6000/rs6000.c:17052

[Bug driver/67613] spell suggestions for misspelled command line options

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
This is awesome! Great job. Do not forget to mention all your awesome work in
https://gcc.gnu.org/gcc-6/changes.html Some people think GCC is dead, and it is
far from it. Let them know!

[Bug middle-end/67790] [6 Regression] verify_ssa failed: definition in block 20 follows the use

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
The issue here is that

  /* If we detected "res -= x[i]" earlier, rewrite it into
 "res += -x[i]" now.  If this turns out to be useless reassoc
 will clean it up again.  */
  if (orig_code == MINUS_EXPR)
{
  tree rhs = gimple_assign_rhs2 (def_stmt);
  tree negrhs = make_ssa_name (TREE_TYPE (rhs));
  gimple *negate_stmt = gimple_build_assign (negrhs, NEGATE_EXPR, rhs);
  gimple_stmt_iterator gsi = gsi_for_stmt (def_stmt);
  set_vinfo_for_stmt (negate_stmt, new_stmt_vec_info (negate_stmt,
  loop_info));
  gsi_insert_before (, negate_stmt, GSI_NEW_STMT);
  gimple_assign_set_rhs2 (def_stmt, negrhs);
  gimple_assign_set_rhs_code (def_stmt, PLUS_EXPR);
  update_stmt (def_stmt);
}

actually inserts stmts into the IL which assigns UIDs to them (via
set_vinfo_for_stmt) which later confuses get_later/earlier_stmt.

The "proper" way of doing the above is by using a pattern which avoids
this issue.

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

[jgreenhalgh at gcc dot gnu.org]

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

Bug ID: 68333
   Summary: [6 Regression] FAIL: gcc.dg/vect/slp-multitypes-4.c
-flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorized 1 loops" 1
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jgreenhalgh at gcc dot gnu.org
CC: dje at gcc dot gnu.org, michael.collison at linaro dot org,
rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64-unknown-linux-gnu

This failure, along with:

FAIL: gcc.dg/vect/slp-multitypes-4.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-multitypes-4.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-multitypes-4.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-multitypes-5.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-multitypes-5.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-multitypes-5.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-multitypes-5.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-perm-8.c -flto -ffat-lto-objects  scan-tree-dump-times
vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-perm-8.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/vect-125.c -flto -ffat-lto-objects  scan-tree-dump vect
"vectorized 1 loops"
FAIL: gcc.dg/vect/vect-125.c scan-tree-dump vect "vectorized 1 loops"

Seems to have started some time in May, near vectorization patches added on
2015-05-22. On IRC:

 Rhy0lite: but yes, widen-sum pattern might be detected but not
supported afterwards as well
 richi: On AArch64 it was slp-multitypes-4.c:16:3: note: not
vectorized: relevant stmt not supported: patt_127 = _7 w+ 1;
 ah, caused by 2015-05-22, (vect_recog_widen_sum_pattern): Likewise.
 formerly only detected for reductions now also in other places
 there is a PR for the dot_prod case (and the sad case as well)
 richi: same note in PPC dump as jgreenhalgh showed
 hum, vect_recog_widen_sum_pattern misses an optab check.
 note: not vectorized: relevant stmt not supported: patt_127 = _7 w+
1;
 ok, can you open a new PR please?  looks like a different issue than
the dot_prod/sad issue

The failure currently shows up for the rs6000 and ia64 backends, but Michael
Collison's proposed patch adding support for vector widening add patterns would
introduce it to the aarch64 port (
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00898.html ).

With Michael's patch applied, I see the following in the dumps for vect-125.c
on AArch64:

vect-125.c:10:3: note: vect_recog_widen_sum_pattern: detected: patt_58
= _13 w+ _24;
vect-125.c:10:3: note: pattern recognized: patt_58 = _13 w+ _24;
[...snip...]
vect-125.c:10:3: note: ==> examining pattern statement: patt_58 = _13
w+ _24;
vect-125.c:10:3: note: vect_is_simple_use: operand _13
vect-125.c:10:3: note: def_stmt: _13 = *_12;
vect-125.c:10:3: note: type of def: internal
vect-125.c:10:3: note: not vectorized: relevant stmt not supported:
patt_58 = _13 w+ _24;

[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
(In reply to H.J. Lu from comment #4)
> +   /* If that didn't simplify to a constant see if we have recorded
> +  temporary expressions from taken edges.  */
> +   if (!val || TREE_CODE (val) != INTEGER_CST)
> + {
> +   tree ops[2];
> +   ops[0] = gimple_cond_lhs (stmt);
> +   ops[1] = gimple_cond_rhs (stmt);
> +   val = vn_nary_op_lookup_pieces (2, gimple_cond_code (stmt),
> +   boolean_type_node, ops, NULL);
> + }
> 
> turns
> 
>  type  used unsigned type_6 SI
> size 
> unit size 
> align 32 symtab 1390664112 alias set -1 canonical type
> 0x7f205894a888 precision 32 min  max
> >
> visited var def_stmt GIMPLE_NOP
> 
> version 5>
>  
> constant 536870911>
> 
> if (__n_5(D) > 536870911)
> 
> into
> 
>  
> constant 0>
> 
> This can't be right.

If that's the transform done to
_ZN9__gnu_cxx20throw_allocator_baseINSt8__detail10_Hash_nodeIiLb0EEENS_15limit_conditionEE8allocateEjPKv
then that looks perfectly valid.  We have


  :
  if (__n_5(D) > 536870911)
goto ;
  else
goto ;

  :
  std::__throw_bad_alloc ();

  :
  _18 = _S_count;
  _19 = _S_limit;
  if (_18 == _19)
goto ;
  else
goto ;

  :
  __gnu_cxx::__throw_forced_error ();

  :
  _20 = _18 + 1;
  _S_count = _20;
  _8 = _2(D)->_M_allocator;
  if (__n_5(D) > 536870911)
goto ;
  else
goto ;

and we optimize the compare in bb 6 which is redundant as the one in BB2
dominates it.

Can you check whether disabling PRE fixes the runtime failure?

Maybe it is also just inlining of the above function that is enabled by
the patch and causes followup errors.

[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 13 12:14:57 2015
New Revision: 230310

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

PR tree-optimization/68306
* tree-vect-data-refs.c (verify_data_ref_alignment): Move
loop related checks ...
(vect_verify_datarefs_alignment): ... here.
(vect_slp_analyze_and_verify_node_alignment): Compute and
verify alignment of the single DR that it matters.
* tree-vect-stmts.c (vectorizable_store): Add an assert.
(vectorizable_load): Add a comment.
* tree-vect-slp.c (vect_analyze_slp_cost_1): Fix DR used
for determining load cost.

* gcc.dg/pr68306.c: Adjust.
* gcc.dg/pr68306-2.c: New testcase.
* gcc.dg/pr68306-3.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/pr68306-2.c
trunk/gcc/testsuite/gcc.dg/pr68306-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr68306.c
trunk/gcc/tree-vect-data-refs.c
trunk/gcc/tree-vect-slp.c
trunk/gcc/tree-vect-stmts.c

[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #21 from Joost VandeVondele  
---
(In reply to Markus Trippelsdorf from comment #20)
> I haven't seen this issue since Jason's GC related C++ patches went in:
> r230201 and r230202.
> 
> But of course this may well be another statistical fluke.

likely so, since my testcase is Fortran based. For me the nightly build of CP2K
now fails with 

/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/pw_spline_utils.F:2303:0:

   SUBROUTINE add_fine2coarse(fine_values_pw,coarse_coeffs_pw,&


internal compiler error: Segmentation fault
0xb525df crash_signal
../../gcc/gcc/toplev.c:336
0x1322c4c dr_misalignment
../../gcc/gcc/tree-vectorizer.h:889
0x1322c4c aligned_access_p
../../gcc/gcc/tree-vectorizer.h:902
0x1322c4c vect_supportable_dr_alignment(data_reference*, bool)
../../gcc/gcc/tree-vect-data-refs.c:5863
0xd96d9f vectorizable_load
../../gcc/gcc/tree-vect-stmts.c:6706
0xda061d vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
../../gcc/gcc/tree-vect-stmts.c:7998
0xdc0a31 vect_schedule_slp_instance
../../gcc/gcc/tree-vect-slp.c:3468

not sure if it is related.

[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>

[trippels at gcc dot gnu.org]

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

--- Comment #22 from Markus Trippelsdorf  ---
(In reply to Joost VandeVondele from comment #21)
> likely so, since my testcase is Fortran based. For me the nightly build of
> CP2K now fails with 
> 
> /data/vjoost/gnu/cp2k/cp2k/makefiles/../src/pw_spline_utils.F:2303:0:
> 
>SUBROUTINE add_fine2coarse(fine_values_pw,coarse_coeffs_pw,&
> 
> 
> internal compiler error: Segmentation fault
> 0xb525df crash_signal
> ../../gcc/gcc/toplev.c:336
> 0x1322c4c dr_misalignment
> ../../gcc/gcc/tree-vectorizer.h:889
> 0x1322c4c aligned_access_p
> ../../gcc/gcc/tree-vectorizer.h:902
> 0x1322c4c vect_supportable_dr_alignment(data_reference*, bool)
> ../../gcc/gcc/tree-vect-data-refs.c:5863
> 0xd96d9f vectorizable_load
> ../../gcc/gcc/tree-vect-stmts.c:6706
> 0xda061d vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*,
> _slp_tree*, _slp_instance*)
> ../../gcc/gcc/tree-vect-stmts.c:7998
> 0xdc0a31 vect_schedule_slp_instance
> ../../gcc/gcc/tree-vect-slp.c:3468
> 
> not sure if it is related.

No, that is PR68324 caused by Richi's recent vectorizer changes.

[Bug c++/68071] Generic lambda variadic argument pack cannot be empty

[ralph.tandetzky at gmail dot com]

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

Ralph Tandetzky  changed:

   What|Removed |Added

 CC||ralph.tandetzky at gmail dot 
com

--- Comment #2 from Ralph Tandetzky  ---
I can confirm that error. The code 

int main(){
[](auto...){}();
}

leads to the following compile-time error:

main.cpp: In function 'int main()':
main.cpp:2:23: error: no match for call to '(main()::)
()'
 [](auto...){}();
   ^
main.cpp:2:19: note: candidate: template
main()::
 [](auto...){}();
   ^
main.cpp:2:19: note:   template argument deduction/substitution failed:
main.cpp:2:23: note:   candidate expects 1 argument, 0 provided
 [](auto...){}();
   ^

This is the case for gcc 4.9 and gcc 5.2 with C++14 enabled. Clang 3.6 compiles
it.

[Bug rtl-optimization/68328] New: wrong code at -O2 and -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 68328
   Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

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

It also affects 4.9.x and later releases, making it a regression from 4.8.x. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151112 (experimental) [trunk revision 230270] (GCC) 
$ 
$ gcc-trunk -Os small.c; ./a.out
$ gcc-4.8 -O2 small.c; ./a.out
$ 
$ gcc-trunk -O2 small.c
$ ./a.out
0
$ 


-


int printf (const char *, ...); 

int a, b, c = 1, d = 1, e;

int
fn1 (int p1)
{
  char g, h;
  int i, j;

  for (;;)
{
  if (c)
h = d;
  g = h < p1 ? h : 0; 
  i = (char) ((g - 120) ^ 1);
  j = i > 97;
  if (a - j)
printf ("%d\n", 0);
  if (!b)
return e;
}
}

int
main ()
{
  fn1 (2);
  return 0;
}

[Bug c++/68295] internal compiler error / segmentation fault

[tho...@maier-komor.de]

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

--- Comment #2 from Thomas Maier-Komor  ---
Created attachment 36701
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36701=edit
Another preprocessed testcase

This testcase has no missing symbols and should compile cleanly.

[Bug c/68329] [4.8 4.9]gcc using array index to accelerate loop running , why turn off at gcc 5.X

[zuogang at huawei dot com]

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

zuogang  changed:

   What|Removed |Added

 Target||amd64 ppwerpc32 (tested)
   ||and others(no testing)
  Known to work||4.4.1, 5.2.0
   Host||amd64
  Known to fail||4.8.5, 4.9.4
  Build||amd64

--- Comment #1 from zuogang  ---
the src code file is:
/*
 * compiling options:
 * -g -w -c -Wall -fno-common -fno-omit-frame-pointer -Wextra
-Wformat-nonliteral -Wformat-security -Wswitch-default -O2 -fstrength-reduce
-fno-strict-aliasing
 *
 *  */
#define NULL 0
typedef unsigned int uint4;
typedef unsigned short ushort;
typedef unsigned long ulong;

typedef struct team {
ulong size;
ulong count;
ulong flag;
ulong peer;
 ulong event;
 ulong index[1];
 ulong addr;
}Team;

typedef struct entry {
uint4 *p1;
 uint4 *p2;
 char simple[64];
 char full[64];
 uint4 index;
}Entry;

extern uint4 get1(uint4 p1, uint4 *p2);
extern uint4 get2(uint4 p1, uint4 p2, Entry **p3);
extern void hand(uint4 p1, uint4 p2, Entry *p3);

void recvt(ushort id, Team *pTeam)
{
uint4 num = 0;
uint4 index   = 0;
Entry *pEntry   = NULL;
uint4 count = 0;
uint4 i   = 0;

if (0x01 & pTeam->flag)
{
count = pTeam->count;

for (i = 0; i < count; i++)
{
index = *(pTeam->index + i);
   if(0 != get1(index, ))
{
continue;
}
if (0 == index)
{
continue;
}

if ( 0 != get2(num ,index, ))
{
continue;
}

hand(num, pTeam->event, pEntry);
}
}

return;
}

compile this file using :
gcc -g -w -c -Wall -fno-common -fno-omit-frame-pointer -Wextra
-Wformat-nonliteral -Wformat-security -Wswitch-default -O2 -fstrength-reduce
-fno-strict-aliasing test-loop.c -o testloop

see the disassemble file , wile find that the loop "for (i = 0; i < count;
i++)" run only once.

I think this "bug" is because gcc find the loop index "i", is a array's index,
and the array 's len is 1, so gcc tell the loop can only run once, so gcc don't
generate loop-specific asm codes.

my question is why this op are not support in gcc version 5. any option to
control this "bug"?

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

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Thu, 12 Nov 2015, jsm28 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162
> 
> --- Comment #10 from Joseph S. Myers  ---
> I have verified that the patch in comment#7, (a) on its own and (b) together
> with my patch, does not cause any regressions on x86_64-pc-linux-gnu.  My
> inclination would be that this patch should go in, with a separate issue being
> filed in Bugzilla for the extra qualifiers, and then I can put my patch in.

Fine with me.

[Bug middle-end/68134] [6 Regression] float64x1_t comparison ICE on aarch64-none-elf

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #4 from Ilya Enkovich  ---
Seems the problem is that we have V1DF mode but don't have V1DI mode.  It
causes mode_for_vector to return DI instead of V1DI which makes vector lowering
pass think it is a scalar statements which doesn't need lowering.  This patch
should help:

diff --git a/gcc/targhooks.c b/gcc/targhooks.c
index c34b4e9..66d983b 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
@@ -1093,8 +1093,8 @@ default_get_mask_mode (unsigned nunits, unsigned
vector_size)
   gcc_assert (elem_size * nunits == vector_size);

   vector_mode = mode_for_vector (elem_mode, nunits);
-  if (VECTOR_MODE_P (vector_mode)
-  && !targetm.vector_mode_supported_p (vector_mode))
+  if (!VECTOR_MODE_P (vector_mode)
+  || !targetm.vector_mode_supported_p (vector_mode))
 vector_mode = BLKmode;

   return vector_mode;

[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
I'm testing another followup...

[Bug tree-optimization/68324] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-13
 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch
Summary|ICE on valid code at -O3 on |[6 Regression] ICE on valid
   |x86_64-linux-gnu|code at -O3 on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

[Bug c/68311] gcc/ipa-icf.c:3041: possible sequence point error ?

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 36700
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36700=edit
Suggested patch

[Bug c/68329] New: [4.8 4.9]gcc using array index to accelerate loop running , why turn off at gcc 5.X

[zuogang at huawei dot com]

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

Bug ID: 68329
   Summary: [4.8 4.9]gcc using array index to accelerate loop
running , why turn off at gcc 5.X
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zuogang at huawei dot com
  Target Milestone: ---

[Bug libstdc++/68197] negative index to ios_base::iword lead to unpredictable result

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
No, it seems underspecified. I have raised it with the C++ committee.

[Bug c++/68295] internal compiler error / segmentation fault

[tho...@maier-komor.de]

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

--- Comment #1 from Thomas Maier-Komor  ---
The bug is reproduceable with gcc 5.2.0 on cygwin.

[Bug c++/63517] bogus Wreturn-type warning after error

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Gcc 5.1 and current trunk (6.0) print just the first error message and not the
-Wreturn-type warning.  Resolving as fixed.

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

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk.

[Bug fortran/68319] ICE on using interface with included entry

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> In fact, gfortran is not issues an error for data-stmt, format-stmt,
> or stmt-function-stmt.

Confirmed: the following test compiles

module m
   interface
  subroutine s
  entry e
integer :: x
data x /1/
f(x) = x*x
10  format (a)
  end
   end interface
contains
   subroutine g
   end
end

[Bug middle-end/68336] False positive Wreturn-type warning

[yyc1992 at gmail dot com]

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

--- Comment #1 from Yichao Yu  ---
Ref clang bug report https://llvm.org/bugs/show_bug.cgi?id=25521

[Bug tree-optimization/68317] [6 regression] ice in set_value_range, at tree-vrp.c:380

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

 CC||jiwang at gcc dot gnu.org

--- Comment #5 from Jiong Wang  ---
(In reply to Marek Polacek from comment #4)
> FWIW, started with r230150.

Sorry for the breakage, let me have a further check

[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #23 from Markus Trippelsdorf  ---
Unfortunately it is a ggc_collect and not a ggc_free:

Hardware watchpoint 1: *(const_tree*)0x3fff9d65aa30

Old value = (const_tree) 0x0
New value = (const_tree) 0xa5a5a5a5a5a5a5a5
0x3fffb793bfa8 in __memset_power7 () from /lib64/libc.so.6
(gdb) bt
#0  0x3fffb793bfa8 in __memset_power7 () from /lib64/libc.so.6
#1  0x102a4bf4 in poison_pages () at ../../gcc/gcc/ggc-page.c:2085
#2  0x102a6ca4 in ggc_collect () at ../../gcc/gcc/ggc-page.c:2180
#3  0x10717b50 in execute_one_pass (pass=0x116e2de0) at
../../gcc/gcc/passes.c:2383
#4  0x10718038 in execute_pass_list_1 (pass=0x116e2de0) at
../../gcc/gcc/passes.c:2398
#5  0x10718050 in execute_pass_list_1 (pass=0x116e1d60) at
../../gcc/gcc/passes.c:2399
#6  0x107180fc in execute_pass_list (fn=0x3fff9f468298, pass=) at ../../gcc/gcc/passes.c:2409
#7  0x10351514 in cgraph_node::expand (this=0x3fff9d2d2f70) at
../../gcc/gcc/cgraphunit.c:1965
#8  0x10353588 in expand_all_functions () at
../../gcc/gcc/cgraphunit.c:2101
#9  symbol_table::compile (this=0x3fffaf39) at
../../gcc/gcc/cgraphunit.c:2450
#10 0x10355c5c in symbol_table::finalize_compilation_unit
(this=0x3fffaf39) at ../../gcc/gcc/cgraphunit.c:2540
#11 0x10812f30 in compile_file () at ../../gcc/gcc/toplev.c:491
#12 0x10153288 in do_compile () at ../../gcc/gcc/toplev.c:1954
#13 toplev::main (this=, argc=107, argv=0x3fffe188) at
../../gcc/gcc/toplev.c:2061
#14 0x101551e8 in main (argc=, argv=0x3fffe188) at
../../gcc/gcc/main.c:39

[Bug sanitizer/68338] New: tsan report error about c++11 static local initialize

[dushistov at mail dot ru]

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

Bug ID: 68338
   Summary: tsan report error about c++11 static local initialize
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dushistov at mail 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: ---

With code like this:

#include 
#include 
#include 

std::string message()
{
static std::string msg("hi");
return msg;
}

int main()
{
std::thread t1([]() { std::cout << message() << "\n"; });
std::thread t2([]() { std::cout << message() << "\n"; });

t1.join();
t2.join();
}

compile like this:
g++ -O3 -g3 -fsanitize=thread -Wall -std=c++11 -pthread -Wextra test.cpp

according to c++11 statnadard such code should be thread safe,

at the same time if replate g++(gcc 5.2) by clang++(clang 3.7)
it does run without any reported failures.

[Bug sanitizer/68338] tsan report error about c++11 static local initialize

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Version|unknown |5.2.0

--- Comment #1 from Jonathan Wakely  ---
I can reproduce this with 5.2 but not trunk.

I suspect it's a false positive and libtsan on trunk has been taught to ignore
it.

[Bug middle-end/68336] False positive Wreturn-type warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Confirmed.  An even simpler test case is below.  See also bug 67629.

$ cat z.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S -Wall
-o/dev/null z.c
int f (void)
{
for (int i = 1; i; )
return 1;
}
z.c: In function ‘f’:
z.c:5:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

G++ also warns on the trivial:

int f (void)
{
if (bool b = true)
return 1;
}

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[chrbr at gcc dot gnu.org]

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

--- Comment #30 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Fri Nov 13 15:19:19 2015
New Revision: 230327

URL: https://gcc.gnu.org/viewcvs?rev=230327=gcc=rev
Log:
2015-11-13  Christian Bruel  

PR target/65837
* config/arm/arm.c (arm_option_override): Move NEON check...
(arm_option_check_internal): here
(arm_file_start): Move .fpu print...
(arm_declare_function_name): here
(arm_option_print): Dump current fpu name.
* config/arm/arm.opt (arm_fpu_index): Mark Save.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.opt

[Bug rtl-optimization/68330] [6 Regression]: FAIL: gcc.target/alpha/pr42269-1.c scan-assembler-not addl on alpha-linux-gnu

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org

--- Comment #2 from Segher Boessenkool  ---
Hrm, I don't think your analysis is entirely correct yet -- you say
with the old compiler insn 19 is removed, but that sets reg 73 which
is still used in insn 20.

Anyway, mine, I'll figure it out.

[Bug sanitizer/68338] tsan report error about c++11 static local initialize

[dushistov at mail dot ru]

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

--- Comment #2 from Evgeniy Dushistov  ---
The problem as I understand assembler in check
that find out is static variable initialized,

clang emit this:

callq  45bdb0 <__tsan_atomic8_load>

while gcc emit 

callq  401260 <__tsan_read1@plt>

[Bug tree-optimization/68198] [6 Regression]Excessive code size, compile time and memory usage bloat due to FSM threading in 453.povray

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law  ---
Creating a forwarder outside the path doesn't help since you still have to have
an edge to the forwarder from each copy of the block with the SWITCH_EXPR. 

The solution is to realize that a path containing a SWITCH_EXPR that does not
have a compile-time determinable destination probably isn't worth optimizing to
start with!  Essentially we're duplicating a block with 1k outgoing edges to
eliminate a single conditional later in the path.  From a cost/benefit analysis
that's just silly.

As I mentioned, this kind of situation was possible with the old threader too,
it was just too dumb to discover the path.

[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
See also bug 68336, which may be a possible duplicate of this one.

[Bug fortran/68319] ICE on using interface with included entry

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Fri, Nov 13, 2015 at 12:42:16AM +, kargl at gcc dot gnu.org wrote:
> --- Comment #2 from kargl at gcc dot gnu.org ---
> It seems that gfortran is missing a check for ENTRY.  F2008 has
> 
> C1206 (R1205) An interface-body shall not contain a data-stmt, format-stmt,
> entry-stmt, or stmt-function-stmt.
> 

In fact, gfortran is not issues an error for data-stmt, format-stmt,
or stmt-function-stmt.

[Bug tree-optimization/68327] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vect_is_simple_use, at tree-vect-stmts.c:8562

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

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

[Bug tree-optimization/68060] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1413

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Started with r228811.

[Bug c/68337] New: [MPX] memcpy() for arrays with function pointers results in huge resource usage and binaries

[jussi.judin at ericsson dot com]

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

Bug ID: 68337
   Summary: [MPX] memcpy() for arrays with function pointers
results in huge resource usage and binaries
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jussi.judin at ericsson dot com
  Target Milestone: ---

Created attachment 36703
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36703=edit
Preprocessed source file including string.h

If I compile following program with GCC 5.2.0 with following options, it takes
around 7.6 seconds to compile and uses over 500 megabytes of memory (Maximum
resident set size):

$ gcc -save-temps -fcheck-pointer-bounds -mmpx -o mpx-funcptr-explosion -c
mpx-funcptr-explosion.c

#include 

#define ARRAY_SIZE 8192

typedef int (* funcptr_t) (void);

typedef struct {
int data;
funcptr_t callback1;
funcptr_t callback2;
funcptr_t callback3;
funcptr_t callback4;
} funcptr_struct_t;

funcptr_struct_t source[ARRAY_SIZE];

void memcpy_user(void) {
funcptr_struct_t target[ARRAY_SIZE];
memcpy(target, source, sizeof(source));
}

The resulting binary takes 4197096 bytes and assembly file 8117029 bytes. Every
funcptr_t instance I add to the structure adds around 2.6 seconds to execution
time of the compilation. This basically makes it impossible to use static
memory with callback functions with MPX support, as it explodes the compilation
resources and the resulting binary.

GCC has following specifications:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/local/ejusjud/intel-mpx/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.2.0/configure --enable-libmpx
--with-as=/home/ejusjud/local/intel-mpx/bin/as
--with-ld=/home/ejusjud/local/intel-mpx/bin/ld
--prefix=/home/ejusjud/local/intel-mpx
Thread model: posix
gcc version 5.2.0 (GCC)

[Bug libstdc++/68323] chrono reference to ‘literals’ namespace is ambiguous when using gnu-versioned-namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Daniel Morilha from comment #0)
> /home/y/lib/gcc/x86_64-redhat-linux/5.2.0/include/c++/chrono:873:19: error:
> reference to ‘literals’ is ambiguous
>using namespace literals::chrono_literals;
>^
> /home/y/lib/gcc/x86_64-redhat-linux/5.2.0/include/c++/chrono:788:3: note:
> candidates are: namespace std::literals { }

Ah, I think we should have a __7 in there.

> /home/y/lib/gcc/x86_64-redhat-linux/5.2.0/include/c++/bits/basic_string.h:
> 5547:3: note: namespace std::__7::literals { }

And the __7 there might be in the wrong place.

[Bug fortran/68319] ICE on using interface with included entry

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Fri, Nov 13, 2015 at 04:08:05PM +, sgk at troutmask dot
apl.washington.edu wrote:
> --- Comment #6 from Steve Kargl  ---
> On Fri, Nov 13, 2015 at 12:42:16AM +, kargl at gcc dot gnu.org wrote:
> >
> > It seems that gfortran is missing a check for ENTRY.  F2008 has
> > 
> > C1206 (R1205) An interface-body shall not contain a data-stmt, format-stmt,
> > entry-stmt, or stmt-function-stmt.
> > 
> 
> I have a patch for stmt-function-stmt and entry.
> data-stmt and format-stmt will follow shortly.
> 

I now have data-stmt and format-stmt covered.  Patch to be submitted
later today.

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

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
In the end, I think the "ree" pass is at fault here.
I'm testing a patch.

[Bug tree-optimization/68317] [6 regression] ice in set_value_range, at tree-vrp.c:380

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
FWIW, started with r230150.

[Bug middle-end/68336] New: False positive Wreturn-type warning

[yyc1992 at gmail dot com]

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

Bug ID: 68336
   Summary: False positive Wreturn-type warning
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yyc1992 at gmail dot com
  Target Milestone: ---

The following code gives a warning about control flow reaching the end of
function without returning a value even though the function will always reach
the `return 1;` statement and won't reach the end of the function.

```
int f()
{
for (int i = 1;--i >= 0;) {
return 1;
}
}
```

Given no warning about this is given if the loop condition is replaced with `1`
I hope it is also possible for gcc to figure out that the loop is executed as
least once and silence the warning.

This (admittedly stupid) code pattern arise from macro expansion to setup a
single time local context.

[Bug fortran/68319] ICE on using interface with included entry

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
Working on this.

[Bug fortran/68319] ICE on using interface with included entry

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Fri, Nov 13, 2015 at 12:42:16AM +, kargl at gcc dot gnu.org wrote:
>
> It seems that gfortran is missing a check for ENTRY.  F2008 has
> 
> C1206 (R1205) An interface-body shall not contain a data-stmt, format-stmt,
> entry-stmt, or stmt-function-stmt.
> 

I have a patch for stmt-function-stmt and entry.
data-stmt and format-stmt will follow shortly.

[Bug rtl-optimization/68330] [6 Regression]: FAIL: gcc.target/alpha/pr42269-1.c scan-assembler-not addl on alpha-linux-gnu

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #0)
> Revision r230164 [1] regressed:
> 
> FAIL: gcc.target/alpha/pr42269-1.c scan-assembler-not addl
> 
> on alpha-linux-gnu.
> 
> The difference starts in combine, where before the patch, we were able
> to combine insns:

Please scrap this, the correct analysis is below.

We start with following sequence:

(insn 19 18 20 2 (set (reg/v:DI 73 [ x ])
(sign_extend:DI (subreg:SI (reg:DI 90) 0))) pr42269.c:9 2
{*extendsidi2_1}
 (expr_list:REG_DEAD (reg:DI 90)
(nil)))
(insn 20 19 21 2 (set (reg:DI 91 [ x ])
(zero_extend:DI (subreg/s/u:SI (reg/v:DI 73 [ x ]) 0))) pr42269.c:10 48
{zero_extendsidi2}
 (nil))

where before the referred patch, combine pass removes (insn 19), leaving only:

(insn 20 19 21 2 (set (reg:DI 91 [ x ])
(zero_extend:DI (subreg/s/u:SI (reg/v:DI 73 [ x ]) 0))) pr42269.c:10 48
{zero_extendsidi2}
 (nil))
(note 21 20 22 2 NOTE_INSN_DELETED)

With the patched gcc, we still have:

(insn 19 18 20 2 (set (reg/v:DI 73 [ x ])
(sign_extend:DI (subreg:SI (reg:DI 90) 0))) pr42269-fail.c:9 2
{*extendsidi2_1}
 (expr_list:REG_DEAD (reg:DI 90)
(nil)))
(insn 20 19 21 2 (set (reg:DI 91 [ x ])
(zero_extend:DI (subreg/s/u:SI (reg/v:DI 73 [ x ]) 0)))
pr42269-fail.c:10 48 {zero_extendsidi2}
 (nil))

Please note that (insn 19) above is redundant.

BTW: I wonder if combine pass is the correct place to perform this optimization
(please see PR 42269), we have ree pass that should remove redundant
extensions.

[Bug rtl-optimization/68330] [6 Regression]: FAIL: gcc.target/alpha/pr42269-1.c scan-assembler-not addl on alpha-linux-gnu

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Segher Boessenkool from comment #2)
> Hrm, I don't think your analysis is entirely correct yet -- you say
> with the old compiler insn 19 is removed, but that sets reg 73 which
> is still used in insn 20.

For some reason, the transformation slightly mixes insn numbers:

(note 18 15 19 2 NOTE_INSN_DELETED)
(insn 19 18 20 2 (set (reg/v:DI 73 [ x ])
(xor:DI (reg/v:DI 71 [ x ])
(reg:DI 72 [ _4 ]))) pr42269.c:9 58 {xordi3}
 (expr_list:REG_DEAD (reg/v:DI 71 [ x ])
(expr_list:REG_DEAD (reg:DI 72 [ _4 ])
(nil
(insn 20 19 21 2 (set (reg:DI 91 [ x ])
(zero_extend:DI (subreg/s/u:SI (reg/v:DI 73 [ x ]) 0))) pr42269.c:10 48
{zero_extendsidi2}
 (nil))

[Bug libstdc++/58393] Please relax feature check for std::to_string and std::sto* for uClibc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #6 from Jonathan Wakely  ---
Should be fixed on trunk now.

[Bug libstdc++/61580] stoi function unknown on W7/Cygwin/x86_64

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Should be fixed on trunk now.

[Bug sanitizer/68338] tsan report error about c++11 static local initialize

[dvyukov at google dot com]

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

Dmitry Vyukov  changed:

   What|Removed |Added

 CC||dvyukov at google dot com

--- Comment #3 from Dmitry Vyukov  ---
As far as I remember there was a real bug in gcc that it emitted non-atomic
load for static var initialization fast-path (think broken double-checked
locking). This bug should be fixed by now. So if it works with tip gcc, I
propose to close this.

[Bug tree-optimization/68341] New: FAIL: gcc.dg/graphite/interchange-{1,11,13}.c (internal compiler error)

[vries at gcc dot gnu.org]

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

Bug ID: 68341
   Summary: FAIL: gcc.dg/graphite/interchange-{1,11,13}.c
(internal compiler error)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Fails with revision r230329 (testing x86_64 non-bootstrap build):
...
FAIL: gcc.dg/graphite/interchange-1.c (internal compiler error)
FAIL: gcc.dg/graphite/interchange-1.c (test for excess errors)
FAIL: gcc.dg/graphite/interchange-11.c (internal compiler error)
FAIL: gcc.dg/graphite/interchange-11.c (test for excess errors)
FAIL: gcc.dg/graphite/interchange-13.c (internal compiler error)
FAIL: gcc.dg/graphite/interchange-13.c (test for excess errors)
...

ICE in more detail:
...
src/gcc/testsuite/gcc.dg/graphite/interchange-1.c:13:1: internal compiler
error: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:701
0x10949ce check_loop_closed_ssa_use
src/gcc/tree-ssa-loop-manip.c:701
0x1094b3c verify_loop_closed_ssa(bool)
src/gcc/tree-ssa-loop-manip.c:745
0x1ced442 checking_verify_loop_closed_ssa
src/gcc/tree-ssa-loop-manip.h:35
0x1ced4f4 graphite_verify
src/gcc/graphite-isl-ast-to-gimple.c:107
0x1cef88d graphite_regenerate_ast_isl(scop*)
src/gcc/graphite-isl-ast-to-gimple.c:1216
0x1cecc3f graphite_transform_loops()
src/gcc/graphite.c:343
0x1ceccce graphite_transforms
src/gcc/graphite.c:371
0x1cecdf5 execute
src/gcc/graphite.c:448
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
...

[Bug rtl-optimization/68340] New: Inner-nested constant-bounded loop not recognized as constant-bounded during loop unrolling

[kelvin at gcc dot gnu.org]

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

Bug ID: 68340
   Summary: Inner-nested constant-bounded loop not recognized as
constant-bounded during loop unrolling
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kelvin at gcc dot gnu.org
  Target Milestone: ---

As currently implemented, only inner-most loops are unrolled by the loop
unrolling code found in loop-unroll.c.

If a constant-bounded loop is nested within another loop, processing of the
outer loop results in induction variable optimization of the inner loop before
the inner loop is seen by the loop unroller.  After the original code is
replaced with induction variables, the inner loop is no longer recognized by
the loop unrolling code as constant bounded.

Consider, for example, this simple program:

void foo(double *d, unsigned long int n) {
  unsigned long int i, j;

  for (i = 0; i < n; i++) {
for (j = 0; j < 1002; j++) {
  d[j * 2] = 0.0;
}
  }
}

Compile this code with:
  gcc -S -O3 -fno-tree-vectorize -funroll-loops --param max-unroll-times=4
-fdump-rtl-loop2_unroll file.c

Following induction-variable replacements, the transformed inner loop is
restructured to resemble the following:

void *array_end = (void *) [1002 * 2];
double *ivtmp_9 = d;
while (ivtmp_9 < (double *) array_end) {
  *ivtmp_9 = 0.0;
  ivtmp_9 += 2;
}

This can be seen in the trace output reported by the loop2_unroll file. 
Following the first heading "starting region dump", the rtl instructions
associated with "bb 4" (basic block 4) holds the contents of the loop body,
which matches the C pseudo-code shown immediately above.  Subsequent messages
within this same file report:

;; Considering unrolling loop with constant number of iterations
;; Unable to prove that the loop iterates constant times

If the same inner loop is compiled in an outer-most context, you will not see
the error message about "unable to prove that the loop iterates constant times"
and consequently, the result of loop unrolling will be very different.

[Bug middle-end/68339] New: g++.dg/vect/simd-clone-2.cc ICEs with aggressive GC settings and OpenMP

[jason at gcc dot gnu.org]

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

Bug ID: 68339
   Summary: g++.dg/vect/simd-clone-2.cc ICEs with aggressive GC
settings and OpenMP
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Compiling g++.dg/vect/simd-clone-2.cc with

  --param ggc-min-heapsize=0 --param ggc-min-expand=0 -fopenmp-simd

results in a memory corruption ICE.  This seems to be because
expand_simd_clones calls simd_clone_mangle, which generates an identifier, and
then calls simd_clone_create, which eventually calls ggc_collect from
execute_one_ipa_transform_pass.

Since nothing refers to the identifier yet, it gets collected as garbage, so
when expand_simd_clones tries to use it the compiler blows up.

[Bug fortran/68237] ICE on invalid with submodules

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #7)
> > This slightly changed test case should demonstrate the problem:
> 
> Confirmed, the backtrace is
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0001000288c7 in gfc_match_submod_proc () at
> ../../work/gcc/fortran/decl.c:7649
> 7649if (sym->ts.interface->attr.function)
> (gdb) bt
> #0  0x0001000288c7 in gfc_match_submod_proc () at
> ../../work/gcc/fortran/decl.c:7649
> #1  0x000100082e8d in decode_statement () at
> ../../work/gcc/fortran/parse.c:384
> #2  0x000100084bc5 in next_statement () at
> ../../work/gcc/fortran/parse.c:1075
> #3  0x00010008b0f4 in parse_contained (module=) at
> ../../work/gcc/fortran/parse.c:4990
> #4  0x00010008c1df in parse_module () at
> ../../work/gcc/fortran/parse.c:5390
> #5  0x00010008cc43 in gfc_parse_file () at
> ../../work/gcc/fortran/parse.c:5696
> #6  0x0001000d39db in gfc_be_parse_file () at
> ../../work/gcc/fortran/f95-lang.c:205
> #7  0x000100aec62a in compile_file () at ../../work/gcc/toplev.c:466
> #8  0x000100fc173c in ?? ()
> #9  0x000100fc30f9 in main (argc=2, argv=0x7fff5fbff308) at
> ../../work/gcc/main.c:39

This patch

Index: decl.c
===
--- decl.c  (revision 230336)
+++ decl.c  (working copy)
@@ -7650,7 +7666,7 @@ gfc_match_submod_proc (void)

   /* Make sure that the result field is appropriately filled, even though
  the result symbol will be replaced later on.  */
-  if (sym->ts.interface->attr.function)
+  if (sym->ts.interface && sym->ts.interface->attr.function)
 {
   if (sym->ts.interface->result
  && sym->ts.interface->result != sym->ts.interface)

yields

troutmask:sgk[215] gfc6 -c k1.f90
k1.f90:14:19:

module procedure foo
   1

Error: MODULE PROCEDURE at (1) must be in a generic module interface
k1.f90:15:6:

end procedure
  1

Error: Expecting END SUBMODULE statement at (1)

Have no idea if it is correct.  pault?

[Bug fortran/68319] ICE on using interface with included entry

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Nov 13 21:28:10 2015
New Revision: 230352

URL: https://gcc.gnu.org/viewcvs?rev=230352=gcc=rev
Log:
2015-11-13  Steven G. Kargl  

PR fortran/68319
* decl.c (gfc_match_data, gfc_match_entry): Enforce F2008:C1206.
* io.c (gfc_match_format): Ditto.
* match.c (gfc_match_st_function): Ditto.

2015-11-13  Steven G. Kargl  

PR fortran/68319
* gfortran.dg/pr68319.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr68319.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/decl.c
branches/gcc-5-branch/gcc/fortran/io.c
branches/gcc-5-branch/gcc/fortran/match.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/68319] ICE on using interface with included entry

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.3

--- Comment #10 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch.  Thanks for the bug report.

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

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
This failure is introduced here:
https://gcc.gnu.org/ml/gcc-regression/2015-11/msg00186.html :
...
FAIL: gcc.dg/graphite/fuse-1.c scan-tree-dump-times forwprop4
"gimple_simplified to[^\\n]*\\^ 12" 1
...

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

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
Hmm, before r230190 (add testsuite automatic dg-options and dg-do action for
isl-ast-gen-* and fuse-* files) I have one FAIL, but two UNRESOLVED:
...
PASS: gcc.dg/graphite/fuse-1.c (test for excess errors)
PASS: gcc.dg/graphite/fuse-1.c execution test
FAIL: gcc.dg/graphite/fuse-1.c scan-tree-dump-times forwprop4
"gimple_simplified to[^\\n]*\\^ 12" 1
UNRESOLVED: gcc.dg/graphite/fuse-1.c scan-tree-dump-times graphite "ISL AST
generated by ISL:.*for (int c0 = 0; c0 <= 99; c0 += 1)
{.*S_.*(c0);.*S_.*(c0);.*S_.*(c0);.*}" 1
PASS: gcc.dg/graphite/fuse-2.c (test for excess errors)
PASS: gcc.dg/graphite/fuse-2.c execution test
UNRESOLVED: gcc.dg/graphite/fuse-2.c scan-tree-dump-times graphite "ISL AST
generated by ISL:.*for (int c0 = 0; c0 <= 99; c0 += 1)
{.*S_.*(c0);.*S_.*(c0);.*S_.*(c0);.*}" 1
...

[Bug target/63304] Aarch64 pc-relative load offset out of range

[e.menezes at samsung dot com]

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

--- Comment #37 from Evandro  ---
Here's what I had in mind:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01787.html

Feedback is welcome.

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

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

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

[Bug c++/68342] New: Unexpected expansion pattern contains no argument packs error

[pkeir at outlook dot com]

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

Bug ID: 68342
   Summary: Unexpected expansion pattern contains no argument
packs error
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pkeir at outlook dot com
  Target Milestone: ---

Created attachment 36704
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36704=edit
The code which produces the unexpected error

The C++11 code below unexpectedly fails to compile on 64-bit Ubuntu 15.04 using
g++ (GCC) 6.0.0 20151110 (experimental) with the following message:

nullary.cpp:12:27: error: expansion pattern ‘g(xs#0)’ contains no argument
packs
   using r_t  = decltype(mt(g(x),g(xs)...))

It compiles with Clang 3.8.0.

struct vec { int x; };

template 
int g(T y) { return y.x; }

template 
int mt(Ts ...xs){ return 0; }

template 
void quack(T x, Ts ...xs)
{
  using r_t  = decltype(mt(g(x),g(xs)...));
  auto f = []() { return r_t{}; };
}

int main(int argc, char *argv[])
{
  quack(vec{0},vec{0},vec{0});
  return 0;
}

[Bug fortran/67803] ICE on concatenating wrong character array constructor

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
I have an ugly patch for this one.

[Bug tree-optimization/68341] FAIL: gcc.dg/graphite/interchange-{1,11,13}.c (internal compiler error)

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from vries at gcc dot gnu.org ---
At https://gcc.gnu.org/ml/gcc-regression/2015-11/msg00399.html, we find
confirmation.

Caused by:
...
commit 30162daabfa9ba2702a361c7837be3773e353fe4
Author: spop 
Date:   Thu Nov 12 00:37:47 2015 +

Preserve the original program while using graphite.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@230200
138bc75d-0d04-0410-961f-82ee72b054a4
...

[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[hjl.tools at gmail dot com]

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

--- Comment #14 from H.J. Lu  ---
(In reply to Richard Biener from comment #13)
> 
> Can you check whether disabling PRE fixes the runtime failure?
> 

-O1: OK.
-O1 -finline-small-functions: Bad.
-O1 -fno-tree-fre -finline-small-functions: Bad.

[Bug c/68344] New: No warning for old-style function declarations.

[i.hamsa at gmail dot com]

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

Bug ID: 68344
   Summary: No warning for old-style function declarations.
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i.hamsa at gmail dot com
  Target Milestone: ---

The following minimal test case

int a();

generates no warning when -Wold-style-declaration -std=c11 is specified.

It is expected that a warning should be produced.

The manual at https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html says:

-Wold-style-declaration
Warn for obsolescent usages, according to the C Standard, in a declaration

The C11 draft standard says:
6.11.6 Function declarators
The use of function declarators with empty parentheses (not prototype-
format parameter type declarators) is an obsolescent feature.

===
Information about the compiler:

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

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

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #4 from vries at gcc dot gnu.org ---
(In reply to vries from comment #2)
> Hmm, before r230190 (add testsuite automatic dg-options and dg-do action for
> isl-ast-gen-* and fuse-* files) I have one FAIL, but two UNRESOLVED:
> ...
> UNRESOLVED: gcc.dg/graphite/fuse-1.c scan-tree-dump-times graphite "ISL AST
> generated by ISL:.*for (int c0 = 0; c0 <= 99; c0 += 1)
> {.*S_.*(c0);.*S_.*(c0);.*S_.*(c0);.*}" 1
> UNRESOLVED: gcc.dg/graphite/fuse-2.c scan-tree-dump-times graphite "ISL AST
> generated by ISL:.*for (int c0 = 0; c0 <= 99; c0 += 1)
> {.*S_.*(c0);.*S_.*(c0);.*S_.*(c0);.*}" 1
> ...

And these UNRESOLVEDs seems to have been present since the tests were added.

[Bug fortran/68319] ICE on using interface with included entry

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Nov 13 21:11:42 2015
New Revision: 230351

URL: https://gcc.gnu.org/viewcvs?rev=230351=gcc=rev
Log:
2015-11-13  Steven G. Kargl  

PR fortran/68319
* decl.c (gfc_match_data, gfc_match_entry): Enforce F2008:C1206.
* io.c (gfc_match_format): Ditto.
* match.c (gfc_match_st_function): Ditto.

2015-11-13  Steven G. Kargl  

PR fortran/68319
* gfortran.dg/pr68319.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr68319.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/io.c
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog

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

[vries at gcc dot gnu.org]

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

Bug ID: 68343
   Summary: FAIL: gcc.dg/graphite/fuse-{1,2}.c scan
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Fails with revision r230329 (on x86_64):
...
FAIL: gcc.dg/graphite/fuse-2.c scan-tree-dump-times graphite "ISL AST generated
by ISL:.*for \\(int c0 = 0; c0 <= 99; c0 \\+= 1\\)
{.*S_.*\\(c0\\);.*S_.*\\(c0\\);.*S_.*\\(c0\\);.*}" 1
FAIL: gcc.dg/graphite/fuse-1.c scan-tree-dump-times graphite "ISL AST generated
by ISL:.*for \\(int c0 = 0; c0 <= 99; c0 \\+= 1\\)
{.*S_.*\\(c0\\);.*S_.*\\(c0\\);.*S_.*\\(c0\\);.*}" 1
FAIL: gcc.dg/graphite/fuse-1.c scan-tree-dump-times forwprop4
"gimple_simplified to[^\\n]*\\^ 12" 1
...

[Bug target/66785] internal compiler error in record_operand_use

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #2 from Jim Wilson  ---
The operand_rr_info struct has arrays sized by MAX_REGS_PER_ADDRESS.

regrename is calling record_operand_use for a write to an operand.  It is also
calling record_operand_use when a use (read or write) overlaps an earlier
write.  Hence a mem operand using an address with N regs can overlap N previous
writes explaining the use of MAX_REGS_PER_ADDRESS. 

However, we can also have an operand that is N-regs wide that can overlap N
previous 1-reg wide writes.  Thus, we need to be able to handle the number of
regs in the widest possible mode also.  If we can have multiword regs used
inside an address, things get even more complicated, but that isn't an issue at
the moment.

So instead of using just MAX_REGS_PER_ADDRESS, we need here something like
#define OPERAND_RR_INFO_ARRAY_SIZE\
  MAX (MAX_REGS_PER_ADDRESS,  \
   (MAX_BITSIZE_MODE_ANY_MODE / BITS_PER_UNIT) / MIN_UNITS_PER_WORD)

Unfortunately, this increases the array size from 2 to 16 for aarch64, as the
widest mode is CXImode which takes 16 registers.  This change may be wasting
too much memory to be useful.  This only affects the ports that have their own
target dependent regrename pass though, which is only c6x and aarch64 at the
moment.

I suspect that we only need an array size of 4 for arm, as the widest
instructions operate on 4 registers at a time, but I don't see an obvious way
to get that info without adding another macro.

I don't see any obvious uses of the chains member in operand_rr_info.  The c6x
and aarch64 ports are only using the heads member.  So we could partially
offset the memory size increase by dropping the chains member.

Or maybe we can modify mode creation to avoid getting the CXI mode, as we don't
need it.  It is created automatically because we define XI as an 8-wide integer
mode.  Without CXImode the widest modes are only 8 registers wide.  Combined
with the removal of the chains member we are only doubling the size of this
structure.

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

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |spop at gcc dot gnu.org

--- Comment #5 from Sebastian Pop  ---
You need ISL 0.15 to have these tests pass.
Could you please report which ISL version you configured gcc with?
I will try to get a check in the graphite.exp to only select fuse-* files when
configured with ISL 0.15 or later.

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

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to Sebastian Pop from comment #5)
> You need ISL 0.15 to have these tests pass.
> Could you please report which ISL version you configured gcc with?

isl-0.14

[Bug target/66785] internal compiler error in record_operand_use

[wilson at gcc dot gnu.org]

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

--- Comment #3 from Jim Wilson  ---
Created attachment 36705
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36705=edit
untested patch that may be wasting memory

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

[thopre01 at gcc dot gnu.org]

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

--- Comment #3 from Thomas Preud'homme  ---
Things start to go awry in the get_defs called at the end of
make_defs_and_copies_lists for conditional move in ree.c. ree correctly detect
that insn 308 is a conditional move and do the transitive closure on it in
search for its definition. It finds insn 304 as the definition for register di
but then screw up by finding insn 308 itself as the definition for bp in insn
308.

This all happens in get_defs that uses df information. For insn 308, there is
only one link in the use-def chain for the dp use and the ref for that link
points to insn 308.

I'm not sure if it's a failure of df to link the use to the def being done in
the same instruction or if it's ree failing to detect this. If the latter, I
guess the fix would be to ignore a def to the same instruction and return an
error if there is only that def (so add a counter in the last loop).

[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de  ---
On November 14, 2015 12:09:28 AM GMT+01:00, "hjl.tools at gmail dot com"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239
>
>--- Comment #14 from H.J. Lu  ---
>(In reply to Richard Biener from comment #13)
>> 
>> Can you check whether disabling PRE fixes the runtime failure?
>> 
>
>-O1: OK.
>-O1 -finline-small-functions: Bad.
>-O1 -fno-tree-fre -finline-small-functions: Bad.

So maybe bisect with the no-fre case then.

[Bug rtl-optimization/68330] New: [6 Regression]: FAIL: gcc.target/alpha/pr42269-1.c scan-assembler-not addl on alpha-linux-gnu

[ubizjak at gmail dot com]

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

Bug ID: 68330
   Summary: [6 Regression]: FAIL: gcc.target/alpha/pr42269-1.c
scan-assembler-not addl on alpha-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---
Target: alpha-linux-gnu

Revision r230164 [1] regressed:

FAIL: gcc.target/alpha/pr42269-1.c scan-assembler-not addl

on alpha-linux-gnu.

The difference starts in combine, where before the patch, we were able
to combine insns:

(insn 7 6 8 2 (set (reg:DI 82)
(lshiftrt:DI (reg:DI 81 [ x ])
(const_int 16 [0x10]))) pr42269-1.c:8 66 {lshrdi3}
 (expr_list:REG_DEAD (reg:DI 81 [ x ])
(nil)))
(insn 8 7 11 2 (set (reg:DI 70 [ _2 ])
(sign_extend:DI (subreg:SI (reg:DI 82) 0))) pr42269-1.c:8 2
{*extendsidi2_1}
 (expr_list:REG_DEAD (reg:DI 82)
(nil)))

to:

Trying 7 -> 8:
Successfully matched this instruction:
(set (reg:DI 70 [ _2 ])
(zero_extract:DI (reg/v:DI 80 [ x ])
(const_int 16 [0x10])
(const_int 16 [0x10])))
allowing combination of insns 7 and 8
original costs 4 + 4 = 8
replacement cost 4
deferring deletion of insn with uid = 7.
modifying insn i3 8: r70:DI=zero_extract(r80:DI,0x10,0x10)
deferring rescan insn with uid = 8.

After the patch, the combination fails:

Trying 7 -> 8:
Failed to match this instruction:
(set (reg:DI 70 [ _2 ])
(sign_extend:DI (lshiftrt:SI (subreg:SI (reg/v:DI 80 [ x ]) 0)
(const_int 16 [0x10]

[1] https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00900.html

[Bug c/65083] Can not indirectly call some C11 atomic library functions

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Confirmed; Joseph has posted a patch.

[Bug target/68332] New: [6 Regression] ICE: in rs6000_is_valid_mask, at config/rs6000/rs6000.c:17052 with __sync_and_and_fetch() @ powerpc

[zsojka at seznam dot cz]

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

Bug ID: 68332
   Summary: [6 Regression] ICE: in rs6000_is_valid_mask, at
config/rs6000/rs6000.c:17052 with
__sync_and_and_fetch() @ powerpc
   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 36702
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36702=edit
reduced testcase

Running the testsuite with RTL checking enabled shows several times the
following assertion failure:

$ powerpc-unknown-linux-gnu-gcc testcase.c 
testcase.c: In function 'foo':
testcase.c:6:3: internal compiler error: RTL check: expected code 'const_int',
have 'reg' in rs6000_is_valid_mask, at config/rs6000/rs6000.c:17052
   __sync_and_and_fetch (, b);
   ^

0xaa4747 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/repo/gcc-trunk/gcc/rtl.c:811   
0xe59608 rs6000_is_valid_mask(rtx_def*, int*, int*, machine_mode)
/repo/gcc-trunk/gcc/config/rs6000/rs6000.c:17052
0xe59627 rs6000_is_valid_and_mask(rtx_def*, machine_mode)
/repo/gcc-trunk/gcc/config/rs6000/rs6000.c:17109
0x1045eff and_operand(rtx_def*, machine_mode)
/repo/gcc-trunk/gcc/config/rs6000/predicates.md:867
0x9f9ee6 insn_operand_matches
/repo/gcc-trunk/gcc/optabs.c:6691
0x9f9ee6 maybe_legitimize_operand_same_code
/repo/gcc-trunk/gcc/optabs.c:6719
0x9fdc61 maybe_legitimize_operand
/repo/gcc-trunk/gcc/optabs.c:6789
0x9fdc61 maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
/repo/gcc-trunk/gcc/optabs.c:6854
0x9fe349 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.c:6872
0x9fea58 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.c:6915
0xa003d1 maybe_emit_op
/repo/gcc-trunk/gcc/optabs.c:6457
0xa06640 expand_atomic_fetch_op_no_fallback
/repo/gcc-trunk/gcc/optabs.c:6497
0xa0685f expand_atomic_fetch_op(rtx_def*, rtx_def*, rtx_def*, rtx_code,
memmodel, bool)
/repo/gcc-trunk/gcc/optabs.c:6575
0x690301 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/repo/gcc-trunk/gcc/builtins.c:6538
0x7d1fbf expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.c:10578
0x6b6f8e expand_expr
/repo/gcc-trunk/gcc/expr.h:256
0x6b6f8e expand_call_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:2622
0x6b6f8e expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.c:3510
0x6b6f8e expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:3673
0x6b8702 expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.c:5679
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ powerpc-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc/bin/powerpc-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-230115-checking-yes-rtl-df-nographite-powerpc/bin/../libexec/gcc/powerpc-unknown-linux-gnu/6.0.0/lto-wrapper
Target: powerpc-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=powerpc-unknown-linux-gnu
--with-ld=/usr/bin/powerpc-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc-unknown-linux-gnu-as --with-sysroot=/chroot/powerpc
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-230115-checking-yes-rtl-df-nographite-powerpc
Thread model: posix
gcc version 6.0.0 20151110 (experimental) (GCC) 

RTL checking must be enabled.

Tested revisions:
r230264 - ICE
r230115 - ICE
5-branch r230247 - OK
4_9-branch r230249 - OK
4_8-branch r224828 - OK

[Bug tree-optimization/68327] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vect_is_simple_use, at tree-vect-stmts.c:8562

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-13
   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
   |vect_is_simple_use, at  |x86_64-linux-gnu in
   |tree-vect-stmts.c:8562  |vect_is_simple_use, at
   ||tree-vect-stmts.c:8562
 Ever confirmed|0   |1

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

[Bug tree-optimization/68324] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/68317] [6 regression] ice in set_value_range, at tree-vrp.c:380

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #3 from Richard Biener  ---
(gdb) p debug_generic_expr (max)
4294443008(OVF)

We have OVF in the IL before VRP:

fn1 ()
{
  unsigned int ivtmp.8;
  int i;
  int _5;

  :

  :
  # ivtmp.8_8 = PHI <4294443008(OVF)(2), ivtmp.8_11(3)>
  _5 = (int) ivtmp.8_8;
  fn2 (_5);
  ivtmp.8_11 = ivtmp.8_8 - 524288;
  goto ;

introduced by IVOPTs which does

 fn1 ()
 {
+  unsigned int ivtmp.8;
   int i;
-  int _4;
   int _5;

   :

   :
-  # i_1 = PHI <7(2), i_7(4)>
-  _4 = i_1 + 8184;
-  _5 = _4 * 524288;
+  # ivtmp.8_8 = PHI <4294443008(OVF)(2), ivtmp.8_11(4)>
+  _5 = (int) ivtmp.8_8;
   fn2 (_5);
-  i_7 = i_1 + -1;

   :
+  ivtmp.8_11 = ivtmp.8_8 - 524288;
   goto ;

 }

note that the infinite loop contains undefined overflow.

IVOPTs should simply strip the overflow flag (using drop_tree_overflow).

[Bug rtl-optimization/68321] [5/6 Regression] wrong code at -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=68321

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-13
   Target Milestone|--- |5.3
Summary|wrong code at -O3 on|[5/6 Regression] wrong code
   |x86_64-linux-gnu (in 64-bit |at -O3 on x86_64-linux-gnu
   |mode)   |(in 64-bit mode)
 Ever confirmed|0   |1

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

[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

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

[Bug tree-optimization/68315] ivdep has no effect in parloops

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Yes.  The easiest way would be to make tree-data-ref.c use it I suppose.

[Bug tree-optimization/68324] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Target||aarch64-none-linux-gnu,
   ||x86_64-none-linux-gnu
 CC||jgreenhalgh at gcc dot gnu.org

--- Comment #1 from James Greenhalgh  ---
I can reproduce this on aarch64-none-linux-gnu.

I also see a similar backtrace in the testsuite for AArch64 on
gcc.target/aarch64/vect-vaddv.c:

FAIL: gcc.target/aarch64/vect-vaddv.c (test for excess errors)
Excess errors:
.../gcc/testsuite/gcc.target/aarch64/vect-vaddv.c:87:5: internal compiler
error: Segmentation fault
0xad6cd7 crash_signal
.../gcc/toplev.c:336
0x10a09b8 dr_misalignment(data_reference*)
.../gcc/tree-vectorizer.h:889
0x10a09b8 aligned_access_p
.../gcc/tree-vectorizer.h:902
0x10a09b8 vect_supportable_dr_alignment(data_reference*, bool)
.../gcc/tree-vect-data-refs.c:5863
0xd13ce3 vectorizable_load
.../gcc/tree-vect-stmts.c:6706
0xd1c1d7 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
.../gcc/tree-vect-stmts.c:7997
0xd33703 vect_schedule_slp_instance
.../gcc/tree-vect-slp.c:3468
0xd3359b vect_schedule_slp_instance
.../gcc/tree-vect-slp.c:3349
0xd3359b vect_schedule_slp_instance
.../gcc/tree-vect-slp.c:3349
0xd3359b vect_schedule_slp_instance
.../gcc/tree-vect-slp.c:3349
0xd3359b vect_schedule_slp_instance
.../gcc/tree-vect-slp.c:3349
0xd35193 vect_schedule_slp(vec_info*)
.../gcc/tree-vect-slp.c:3533
0xd3851f vect_slp_bb(basic_block_def*)
.../gcc/tree-vect-slp.c:2525
0xd3a4db execute
.../gcc/tree-vectorizer.c:738

[Bug tree-optimization/68324] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
Also seen on x86_64-apple-darwin14. Revision r230007 is OK, r230269 gives the
ICE.

[Bug tree-optimization/66558] Missed vectorization of loop with control flow

[alahay01 at gcc dot gnu.org]

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

--- Comment #3 from alahay01 at gcc dot gnu.org ---
Author: alahay01
Date: Fri Nov 13 10:51:34 2015
New Revision: 230297

URL: https://gcc.gnu.org/viewcvs?rev=230297=gcc=rev
Log:
Optimize condition reductions where the result is an integer induction variable

2015-11-13  Alan Hayward 

gcc/
PR tree-optimization/66558
* tree-vect-loop.c (is_integer_induction):Add.
(vectorizable_reduction): Add integer induction checks.

gcc/testsuite/
PR tree-optimization/66558
* gcc.dg/vect/pr65947-1.c: Add checks.
* gcc.dg/vect/pr65947-2.c: Add checks.
* gcc.dg/vect/pr65947-3.c: Add checks.
* gcc.dg/vect/pr65947-4.c: Add checks.
* gcc.dg/vect/pr65947-5.c: Add checks.
* gcc.dg/vect/pr65947-6.c: Add checks.
* gcc.dg/vect/pr65947-10.c: Add checks.
* gcc.dg/vect/pr65947-12.c: New test.
* gcc.dg/vect/pr65947-13.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr65947-12.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-13.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr65947-1.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-10.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-2.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-3.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-4.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-5.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-6.c
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vectorizer.h

[Bug fortran/47266] Optimization: Declare PRIVATE module procedures as "TREE_PUBLIC = 0" ("static function")

[dominiq at gcc dot gnu.org]

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

--- Comment #7 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Fri Nov 13 11:03:40 2015
New Revision: 230299

URL: https://gcc.gnu.org/viewcvs?rev=230299=gcc=rev
Log:
2015-11-13  Dominique d'Humieres 

PR fortran/47266
* gfortran.dg/module_private_2.f90: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/module_private_2.f90
Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/68198] [6 Regression]Excessive code size, compile time and memory usage bloat due to FSM threading in 453.povray

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Jeffrey A. Law from comment #6)
> Fixing ought to be fairly easy...

Create a forwarder block outside of the path?

[Bug target/68332] [6 Regression] ICE: in rs6000_is_valid_mask, at config/rs6000/rs6000.c:17052 with __sync_and_and_fetch() @ powerpc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0