[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline

[kelvin at gcc dot gnu.org]

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.