Started with r230297.
Note, in C
  const int N = 8;
  int v[N];
is a variable length array, so unnecessarily pessimizing, you need to use
#define N 8
or
  enum { N = 8 };
or something similar instead for it to be a non-VLA.  In C++ it is not a VLA.
But fixing that doesn't help here.

GCC 6.4 is being released, adjusting target milestone.

More complete testcase:

int v[8] = { 77, 1, 79, 3, 4, 5, 6, 7 };

__attribute__((noipa)) void
foo ()
{
  int k, r = -1;
  for (k = 0; k < 8; k++)
    if (v[k] == 77)
      r = k;
  if (r != 0)
    __builtin_abort ();
}

__attribute__((noipa)) void
bar ()
{
  int k, r = 4;
  for (k = 0; k < 8; k++)
    if (v[k] == 79)
      r = k;
  if (r != 2)
    __builtin_abort ();
}

int
main ()
{
  foo ();
  bar ();
  return 0;
}

The conditional reduction handling is buggy.
In foo we emit:
  vect_cst__21 = { 8, 8, 8, 8, 8, 8, 8, 8 };
  vect_cst__28 = { 77, 77, 77, 77, 77, 77, 77, 77 };
  vect_cst__30 = { -1, -1, -1, -1, -1, -1, -1, -1 };

  <bb 3> [local count: 119292720]:
...
  # vect_vec_iv_.0_22 = PHI <vect_vec_iv_.0_23(9), { 0, 1, 2, 3, 4, 5, 6, 7 }(2)>
  # vect_r_3.1_24 = PHI <vect_r_3.6_29(9), { 0, 0, 0, 0, 0, 0, 0, 0 }(2)>
  # vectp_v.2_25 = PHI <vectp_v.2_26(9), &v(2)>
...
  vect_vec_iv_.0_23 = vect_vec_iv_.0_22 + vect_cst__21;
  vect__1.4_27 = MEM[(int *)vectp_v.2_25];
  vect_r_3.6_29 = VEC_COND_EXPR <vect__1.4_27 == vect_cst__28, vect_vec_iv_.0_22, vect_r_3.1_24>;
...
  <bb 18> [local count: 119292720]:
  # vect_r_3.6_31 = PHI <vect_r_3.6_29(3)>
  stmp_r_3.7_32 = REDUC_MAX (vect_r_3.6_31);
  stmp_r_3.7_33 = stmp_r_3.7_32 == 0 ? -1 : stmp_r_3.7_32;

vect_cst__30 which seems to be the initial value of the reduction var r as a vector is unused.
The problem is that by starting with zero vector for vect_r_3.1_24 there is no difference between a condition match on the first iteration and
no match at all, both result in REDUC_MAX of 0 and the emitted code assumes REDUC_MAX of 0 means no match.

In this case (if the first iteration iterator is constant and bigger than the minimum value of the type), just initializing by a vector containing any value smaller than the first iteration IV and adjusting that:
  stmp_r_3.7_33 = stmp_r_3.7_32 == 0 ? -1 : stmp_r_3.7_32;
to
  stmp_r_3.7_33 = stmp_r_3.7_32 == the_chosen_value ? -1 : stmp_r_3.7_32;
or specially in case when the reduction var is previously initialized to a value smaller than the minimum, we could build a vector of those values and avoid the COND_EXPR on the REDUC_MAX value.

Now, in case the first iteration iterator is constant, but is the minimum value, we can't use this trick.  Perhaps we could in that case just
bias it by one, say if the reduction is with unsigned type emit e.g.:
  # vect_vec_iv_.0_22 = PHI <vect_vec_iv_.0_23(9), { 1, 2, 3, 4, 5, 6, 7, 8 }(2)>
  # vect_r_3.1_24 = PHI <vect_r_3.6_29(9), { 0, 0, 0, 0, 0, 0, 0, 0 }(2)>
  # vectp_v.2_25 = PHI <vectp_v.2_26(9), &v(2)>
...
  vect_vec_iv_.0_23 = vect_vec_iv_.0_22 + vect_cst__21;
  vect__1.4_27 = MEM[(int *)vectp_v.2_25];
  vect_r_3.6_29 = VEC_COND_EXPR <vect__1.4_27 == vect_cst__28, vect_vec_iv_.0_22, vect_r_3.1_24>;
...
  <bb 18> [local count: 119292720]:
  # vect_r_3.6_31 = PHI <vect_r_3.6_29(3)>
  stmp_r_3.7_32 = REDUC_MAX (vect_r_3.6_31);
  stmt_r_3.7_34 = stmp_r_3.7_32 - 1;
  stmp_r_3.7_33 = stmp_r_3.7_32 == 0 ? <original_r_value> : stmt_r_3.7_34;

For the non-constant IV first value we actually emit really weird code:
int v[8] = { 77, 1, 79, 3, 4, 5, 6, 7 };

__attribute__((noipa)) void
foo (int *v, int f)
{
  int k, r = -1;
  for (k = f; k < f + 8; k++)
    if (v[k] == 77)
      r = k;
  if (r != 0)
    __builtin_abort ();
}

__attribute__((noipa)) void
bar (int *v, int f)
{
  int k, r = 4;
  for (k = f; k < f + 8; k++)
    if (v[k] == 79)
      r = k;
  if (r != 2)
    __builtin_abort ();
}

int
main ()
{
  foo (v, 0);
  bar (v, 0);
  return 0;
}

where we emit 2 VEC_COND_EXPRs and 2 REDUC_MAX.  While that testcases passes, not really sure if it is correct generally, and furthermore,
it seems unnecessarily complicated to me.  Can't we just emit what we'd emit for unsigned conditional reduction with first iteration 1, and only after the vectorized loop adjust it.
So, say for the foo in the second case, emit:

  vect_cst__21 = { 8, 8, 8, 8, 8, 8, 8, 8 };
  vect_cst__28 = { 77, 77, 77, 77, 77, 77, 77, 77 };

  <bb 3> [local count: 119292720]:
...
  # vect_vec_iv_.0_22 = PHI <vect_vec_iv_.0_23(9), { 1, 2, 3, 4, 5, 6, 7, 8 }(2)>
  # vect_r_3.1_24 = PHI <vect_r_3.6_29(9), { 0, 0, 0, 0, 0, 0, 0, 0 }(2)>
  # vectp_v.2_25 = PHI <vectp_v.2_26(9), &v(2)>
...
  vect_vec_iv_.0_23 = vect_vec_iv_.0_22 + vect_cst__21;
  vect__1.4_27 = MEM[(int *)vectp_v.2_25];
  vect_r_3.6_29 = VEC_COND_EXPR <vect__1.4_27 == vect_cst__28, vect_vec_iv_.0_22, vect_r_3.1_24>;
...
  <bb 18> [local count: 119292720]:
  # vect_r_3.6_31 = PHI <vect_r_3.6_29(3)>
  stmp_r_3.7_32 = REDUC_MAX (vect_r_3.6_31);
  stmt_r_3.7_34 = f_9(D) + (stmp_r_3.7_32 - 1) * step;
  stmp_r_3.7_33 = stmp_r_3.7_32 == 0 ? <r_value_before_loop> : stmp_r_3.7_34;
where _22, _24, _29 would be all in vectors of unsigned_type_for (r)?
Or for signed start with { min, min, ... } as condition never seen value, and { min+1, min+2, min+3, ... } vector as the initial _22 value?

On December 8, 2017 4:56:12 PM GMT+01:00, "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80631
>
>Jakub Jelinek <jakub at gcc dot gnu.org> changed:
>
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>             CC|                            |rguenth at gcc dot gnu.org
>
>--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
>More complete testcase:
>
>int v[8] = { 77, 1, 79, 3, 4, 5, 6, 7 };
>
>__attribute__((noipa)) void
>foo ()
>{
>  int k, r = -1;
>  for (k = 0; k < 8; k++)
>    if (v[k] == 77)
>      r = k;
>  if (r != 0)
>    __builtin_abort ();
>}
>
>__attribute__((noipa)) void
>bar ()
>{
>  int k, r = 4;
>  for (k = 0; k < 8; k++)
>    if (v[k] == 79)
>      r = k;
>  if (r != 2)
>    __builtin_abort ();
>}
>
>int
>main ()
>{
>  foo ();
>  bar ();
>  return 0;
>}
>
>The conditional reduction handling is buggy.
>In foo we emit:
>  vect_cst__21 = { 8, 8, 8, 8, 8, 8, 8, 8 };
>  vect_cst__28 = { 77, 77, 77, 77, 77, 77, 77, 77 };
>  vect_cst__30 = { -1, -1, -1, -1, -1, -1, -1, -1 };
>
>  <bb 3> [local count: 119292720]:
>...
># vect_vec_iv_.0_22 = PHI <vect_vec_iv_.0_23(9), { 0, 1, 2, 3, 4, 5, 6,
>7
>}(2)>
># vect_r_3.1_24 = PHI <vect_r_3.6_29(9), { 0, 0, 0, 0, 0, 0, 0, 0 }(2)>
>  # vectp_v.2_25 = PHI <vectp_v.2_26(9), &v(2)>
>...
>  vect_vec_iv_.0_23 = vect_vec_iv_.0_22 + vect_cst__21;
>  vect__1.4_27 = MEM[(int *)vectp_v.2_25];
>  vect_r_3.6_29 = VEC_COND_EXPR <vect__1.4_27 == vect_cst__28,
>vect_vec_iv_.0_22, vect_r_3.1_24>;
>...
>  <bb 18> [local count: 119292720]:
>  # vect_r_3.6_31 = PHI <vect_r_3.6_29(3)>
>  stmp_r_3.7_32 = REDUC_MAX (vect_r_3.6_31);
>  stmp_r_3.7_33 = stmp_r_3.7_32 == 0 ? -1 : stmp_r_3.7_32;
>
>vect_cst__30 which seems to be the initial value of the reduction var r
>as a
>vector is unused.
>The problem is that by starting with zero vector for vect_r_3.1_24
>there is no
>difference between a condition match on the first iteration and
>no match at all, both result in REDUC_MAX of 0 and the emitted code
>assumes
>REDUC_MAX of 0 means no match.
>
>In this case (if the first iteration iterator is constant and bigger
>than the
>minimum value of the type), just initializing by a vector containing
>any value
>smaller than the first iteration IV and adjusting that:
>  stmp_r_3.7_33 = stmp_r_3.7_32 == 0 ? -1 : stmp_r_3.7_32;
>to
>stmp_r_3.7_33 = stmp_r_3.7_32 == the_chosen_value ? -1 : stmp_r_3.7_32;
>or specially in case when the reduction var is previously initialized
>to a
>value smaller than the minimum, we could build a vector of those values
>and
>avoid the COND_EXPR on the REDUC_MAX value.
>
>Now, in case the first iteration iterator is constant, but is the
>minimum
>value, we can't use this trick.  Perhaps we could in that case just
>bias it by one, say if the reduction is with unsigned type emit e.g.:
># vect_vec_iv_.0_22 = PHI <vect_vec_iv_.0_23(9), { 1, 2, 3, 4, 5, 6, 7,
>8
>}(2)>
># vect_r_3.1_24 = PHI <vect_r_3.6_29(9), { 0, 0, 0, 0, 0, 0, 0, 0 }(2)>
>  # vectp_v.2_25 = PHI <vectp_v.2_26(9), &v(2)>
>...
>  vect_vec_iv_.0_23 = vect_vec_iv_.0_22 + vect_cst__21;
>  vect__1.4_27 = MEM[(int *)vectp_v.2_25];
>  vect_r_3.6_29 = VEC_COND_EXPR <vect__1.4_27 == vect_cst__28,
>vect_vec_iv_.0_22, vect_r_3.1_24>;
>...
>  <bb 18> [local count: 119292720]:
>  # vect_r_3.6_31 = PHI <vect_r_3.6_29(3)>
>  stmp_r_3.7_32 = REDUC_MAX (vect_r_3.6_31);
>  stmt_r_3.7_34 = stmp_r_3.7_32 - 1;
>stmp_r_3.7_33 = stmp_r_3.7_32 == 0 ? <original_r_value> :
>stmt_r_3.7_34;
>
>For the non-constant IV first value we actually emit really weird code:
>int v[8] = { 77, 1, 79, 3, 4, 5, 6, 7 };
>
>__attribute__((noipa)) void
>foo (int *v, int f)
>{
>  int k, r = -1;
>  for (k = f; k < f + 8; k++)
>    if (v[k] == 77)
>      r = k;
>  if (r != 0)
>    __builtin_abort ();
>}
>
>__attribute__((noipa)) void
>bar (int *v, int f)
>{
>  int k, r = 4;
>  for (k = f; k < f + 8; k++)
>    if (v[k] == 79)
>      r = k;
>  if (r != 2)
>    __builtin_abort ();
>}
>
>int
>main ()
>{
>  foo (v, 0);
>  bar (v, 0);
>  return 0;
>}
>
>where we emit 2 VEC_COND_EXPRs and 2 REDUC_MAX.  While that testcases
>passes,
>not really sure if it is correct generally, and furthermore,
>it seems unnecessarily complicated to me.  Can't we just emit what we'd
>emit
>for unsigned conditional reduction with first iteration 1, and only
>after the
>vectorized loop adjust it.
>So, say for the foo in the second case, emit:
>
>  vect_cst__21 = { 8, 8, 8, 8, 8, 8, 8, 8 };
>  vect_cst__28 = { 77, 77, 77, 77, 77, 77, 77, 77 };
>
>  <bb 3> [local count: 119292720]:
>...
># vect_vec_iv_.0_22 = PHI <vect_vec_iv_.0_23(9), { 1, 2, 3, 4, 5, 6, 7,
>8
>}(2)>
># vect_r_3.1_24 = PHI <vect_r_3.6_29(9), { 0, 0, 0, 0, 0, 0, 0, 0 }(2)>
>  # vectp_v.2_25 = PHI <vectp_v.2_26(9), &v(2)>
>...
>  vect_vec_iv_.0_23 = vect_vec_iv_.0_22 + vect_cst__21;
>  vect__1.4_27 = MEM[(int *)vectp_v.2_25];
>  vect_r_3.6_29 = VEC_COND_EXPR <vect__1.4_27 == vect_cst__28,
>vect_vec_iv_.0_22, vect_r_3.1_24>;
>...
>  <bb 18> [local count: 119292720]:
>  # vect_r_3.6_31 = PHI <vect_r_3.6_29(3)>
>  stmp_r_3.7_32 = REDUC_MAX (vect_r_3.6_31);
>  stmt_r_3.7_34 = f_9(D) + (stmp_r_3.7_32 - 1) * step;
>stmp_r_3.7_33 = stmp_r_3.7_32 == 0 ? <r_value_before_loop> :
>stmp_r_3.7_34;
>where _22, _24, _29 would be all in vectors of unsigned_type_for (r)?
>Or for signed start with { min, min, ... } as condition never seen
>value, and {
>min+1, min+2, min+3, ... } vector as the initial _22 value?

There's a dup for this (the existing vect.exp execute fail) and there is an approved patch for it.

Related to PR81179 and http://gcc.gnu.org/ml/gcc-patches/2017-11/msg02054.html
As the patch doesn't apply cleanly, can't easily verify it.

Created attachment 42840 [details]
gcc8-pr80631.patch

Untested fix.

Author: jakub
Date: Tue Dec 12 08:55:02 2017
New Revision: 255574

URL: https://gcc.gnu.org/viewcvs?rev=255574&root=gcc&view=rev
Log:
	PR tree-optimization/80631
	* tree-vect-loop.c (get_initial_def_for_reduction): Fix comment typo.
	(vect_create_epilog_for_reduction): Add INDUC_VAL and INDUC_CODE
	arguments, for INTEGER_INDUC_COND_REDUCTION use INDUC_VAL instead of
	hardcoding zero as the value if COND_EXPR is never true.  For
	INTEGER_INDUC_COND_REDUCTION don't emit the final COND_EXPR if
	INDUC_VAL is equal to INITIAL_DEF, and use INDUC_CODE instead of
	hardcoding MAX_EXPR as the reduction operation.
	(is_nonwrapping_integer_induction): Allow negative step.
	(vectorizable_reduction): Compute INDUC_VAL and INDUC_CODE for
	vect_create_epilog_for_reduction, if no value is suitable, don't
	use INTEGER_INDUC_COND_REDUCTION for now.  Formatting fixes.

	* gcc.dg/vect/pr80631-1.c: New test.
	* gcc.dg/vect/pr80631-2.c: New test.
	* gcc.dg/vect/pr65947-13.c: Expect integer induc cond reduction
	vectorization.

Added:
    trunk/gcc/testsuite/gcc.dg/vect/pr80631-1.c
    trunk/gcc/testsuite/gcc.dg/vect/pr80631-2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/vect/pr65947-13.c
    trunk/gcc/tree-vect-loop.c

Fixed on the trunk so far.

Author: jakub
Date: Fri Dec 15 17:51:36 2017
New Revision: 255701

URL: https://gcc.gnu.org/viewcvs?rev=255701&root=gcc&view=rev
Log:
	PR tree-optimization/80631
	* gcc.target/i386/avx2-pr80631.c: New test.

Added:
    trunk/gcc/testsuite/gcc.target/i386/avx2-pr80631.c
Modified:
    trunk/gcc/testsuite/ChangeLog

Author: jakub
Date: Fri Dec 15 22:12:46 2017
New Revision: 255726

URL: https://gcc.gnu.org/viewcvs?rev=255726&root=gcc&view=rev
Log:
	Backported from mainline
	2017-12-12  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/80631
	* tree-vect-loop.c (get_initial_def_for_reduction): Fix comment typo.
	(vect_create_epilog_for_reduction): Add INDUC_VAL argument, for
	INTEGER_INDUC_COND_REDUCTION use INDUC_VAL instead of
	hardcoding zero as the value if COND_EXPR is never true.  For
	INTEGER_INDUC_COND_REDUCTION don't emit the final COND_EXPR if
	INDUC_VAL is equal to INITIAL_DEF.
	(vectorizable_reduction): Compute INDUC_VAL for
	vect_create_epilog_for_reduction, if no value is suitable, don't
	use INTEGER_INDUC_COND_REDUCTION for now.  Formatting fixes.

	* gcc.dg/vect/pr80631-1.c: New test.
	* gcc.dg/vect/pr80631-2.c: New test.

	PR tree-optimization/80631
	* gcc.target/i386/avx2-pr80631.c: New test.

Added:
    branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr80631-1.c
    branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr80631-2.c
    branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/avx2-pr80631.c
Modified:
    branches/gcc-7-branch/gcc/ChangeLog
    branches/gcc-7-branch/gcc/testsuite/ChangeLog
    branches/gcc-7-branch/gcc/tree-vect-loop.c

Fixed for 7.3+ too.

Author: jakub
Date: Tue Dec 19 07:39:24 2017
New Revision: 255804

URL: https://gcc.gnu.org/viewcvs?rev=255804&root=gcc&view=rev
Log:
	PR tree-optimization/80631
	* tree-vect-loop.c (vect_create_epilog_for_reduction): Compare
	induc_code against MAX_EXPR or MIN_EXPR instead of reduc_fn against
	IFN_REDUC_MAX or IFN_REDUC_MIN.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vect-loop.c

GCC 6 branch is being closed, fixed in 7.x.