__restrict promotes incorrect vectorization, ICL 16.0

submitted as IPS 6000134001

s4113_ ( float * __restrict a, float * b,
        float * c,  int * ip) {

.......

      for (int i = 1; i <= i__2; ++i)
          a[ip[i]] = b[ip[i]] + c[i];

.....

icl -c -QxHost -Qopt-report4 s4113.cpp

ICL  16.0.0.110 vectorizes this (HSW laptop), although there is no way for the compiler to know whether changing the order of memory access will break it.  Besides, the vector code is slower, contrary to what opt_report says, apparently as a result of the cost of the scalar code being over-stated (as comparison with the case of CEAN notation shows).

So now it is dangerous to insert the __restrict or use the equivalent -Qrestrict extension, even though the arrays in fact don't overlap.

This vectorization might be expected if #pragma ivdep or #pragma simd were asserted, meaning that the programmer asserts there will be no repeated elements in ip[] and maybe doesn't care if vectorization is slower.  CEAN notation might imply such an assertion.