Confirmed: https://gcc.gnu.org/ml/gcc-testresults/2016-04/msg00602.html :
...
FAIL: gcc.dg/tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch "Issued prefetch" 2
FAIL: gcc.dg/tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch "Not prefetching" 1
...

https://gcc.gnu.org/ml/gcc-regression/2016-03/msg00336.html :

Regressions on trunk at revision 234600 vs revision 234546

Offending commit: https://gcc.gnu.org/ml/gcc-cvs/2016-03/msg00744.html :
...
Author: hubicka
Date: Wed Mar 30 14:30:57 2016
New Revision: 234572

URL: https://gcc.gnu.org/viewcvs?rev=234572&root=gcc&view=rev
Log:
	* tree-ssa-loop-niter.c (idx_infer_loop_bounds): We can't get realistic
	estimates here.
	* tree-ssa-loop-unswitch.c (tree_unswitch_single_loop): Use also
	max_loop_iterations_int.
	(tree_unswitch_outer_loop): Likewise.
	* tree-ssa-loop-ivopts.c (avg_loop_niter): Likewise.
	* tree-vect-loop.c (vect_analyze_loop_2): Likewise.
...

This is a regression from the gcc-5 branch.

Hi.

It shows that after Honza's change, 'estimated_stmt_executions_int' return -1 for all 3 situations.
Thus 'Issued prefetch' is not printed to the dump file.

However, before Honza's patch was applied, estimated_stmt_executions_int returns strange results for following 2 loops:

struct tail0
{
  int xxx;
  int yyy[2];
};

int loop0 (int n, struct tail0 *x)
{
  int i, s = 0;

  for (i = 0; i < n; i++)
    s += x->yyy[i];

  return s;
}

returns 3, however:

struct tail1
{
  int xxx;
  int yyy[1];
};

int loop1 (int n, struct tail1 *x)
{
  int i, s = 0;

  for (i = 0; i < n; i++)
    s += x->yyy[i];

  return s;
}

returns -1. Well, I would expect here to we given value 2. According to tree dump file, both loops have exactly the same CFG.

Martin

I think -1 is the right answer, these are flexible array-like arrays, 
where one could e.g.
struct tail0 *p = malloc (sizeof (struct tail0) + 131072 * sizeof (int));
initialize (p);
loop0 (131072, p);
and similarly for tail1/loop1.

(In reply to Jakub Jelinek from comment #6)
> I think -1 is the right answer, these are flexible array-like arrays, 
> where one could e.g.
> struct tail0 *p = malloc (sizeof (struct tail0) + 131072 * sizeof (int));
> initialize (p);
> loop0 (131072, p);
> and similarly for tail1/loop1.

Ah, you are right, thanks for explanation.

This commit caused miscompare of spec2000/178.galgel on -march=skylake-avx512 (-Ofast -flto -funroll-loops):
                   Newton iteration #  0    Maximal derivative = 0.1526E-07
                   Newton iteration #  0    Maximal derivative = 0.3901E-07

(In reply to Kirill Yukhin from comment #8)
> This commit caused miscompare of spec2000/178.galgel on
> -march=skylake-avx512 (-Ofast -flto -funroll-loops):
>                    Newton iteration #  0    Maximal derivative = 0.1526E-07
>                    Newton iteration #  0    Maximal derivative = 0.3901E-07

Please file a separate bugreport for this.

Thus a matter of adjusting the testcase.  Basically the comments in it are all
"wrong", in all cases the array is a trailing one.

Author: marxin
Date: Tue Apr 12 13:38:46 2016
New Revision: 234902

URL: https://gcc.gnu.org/viewcvs?rev=234902&root=gcc&view=rev
Log:
Revert r234572 (aka PR testsuite/70577)

	Revert
	2016-03-30  Jan Hubicka  <hubicka@ucw.cz>

	* tree-ssa-loop-niter.c (idx_infer_loop_bounds): We can't get realistic
	estimates here.
	* tree-ssa-loop-unswitch.c (tree_unswitch_single_loop): Use also
	max_loop_iterations_int.
	(tree_unswitch_outer_loop): Likewise.
	* tree-ssa-loop-ivopts.c (avg_loop_niter): Likewise.
	* tree-vect-loop.c (vect_analyze_loop_2): Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-loop-ivopts.c
    trunk/gcc/tree-ssa-loop-niter.c
    trunk/gcc/tree-ssa-loop-unswitch.c
    trunk/gcc/tree-vect-loop.c

Fixed.