sure, but ivdep is supposed to explicitly tells the compiler that there are no loop carried dependencies between iterations, so iteration i-1 couldn't possibly write to a memory location read by iteration i.
Ah sorry, I read your ivdep sentence and the second part of your post as independent, i.e,. that the compiler should be able to assume this (even without ivdep).
I realize now you were saying "[With ivdep] and in this specific case, the compiler should be able to assume..."
It makes sense now.
It's not that the size field is a function of the iteration variable (i?) but that the previous write may have overwritten the size field, because the size field is located at some arbitrary place in memory, and the array backing the vector is located at some other arbitrary place and they may overlap (but only because the vector type is uint8_t/char - if it other than a char type the compiler can be sure they don't overlap because the size() fields are pointers which have a distinct type from uint32_t and are not subject to the "char aliasing loophole" rule).