https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532
--- Comment #12 from kelvin at gcc dot gnu.org --- After further digging, I have uncovered some additional clues: after initial gimple expansion (i.e. the 005t.gimple trace file): vec_extract (vi, 3) is represented by __builtin_vec_ext_v4si (vi, 3) But vec_extract (vi, 10) is represented by __BIT_FIELD_REF <vi, 32, 64> Apparently, the difference in handling of these two cases is that the selector argument of the latter is known to be a constant greater than the number of elements in the vector. However, when the same code is expanded after in-lining the doextractbybuiltin function of comment #4, the two expressions expand into __builtin_vec_ext_v4si (vi, 3) and __builtin_vec_ext_v4si (vi, 10) respectively. This behavior is first manifest in the .047t.local-fnsummary2 trace file. Later, when we "process" __builtin_vec_ext_v4si with a constant selector whose value exceeds the vector length, we issue the erroneous error message. With non-constant selector values for __builtin_vec_ext_v4si, we do not issue the error message. I think the place to fix this is in the processing of the __builtin_vec_ext_v4si function (and all of its lookalikes). Rather than issue the error message, we may have to emit slightly different implementations of the code or maybe not even that. Maybe i can just remove the error message. I need to study this a little more. At the same time, I'm wondering if the "real problem" is in the local-fnsummary2 pass. During in-lining, it could be argued that it should have produced the same intermediate form as the original gimple expansion: BIT_FIELD_REF instead of __builtin_vec_ext_v4si. Does anyone have further suggestions before I begin implementing a "solution"? Thanks.