aboutsummaryrefslogtreecommitdiff
path: root/gcc/expr.cc
diff options
context:
space:
mode:
authorJakub Jelinek <jakub@redhat.com>2022-06-09 17:42:31 +0200
committerJakub Jelinek <jakub@redhat.com>2022-06-09 17:42:31 +0200
commit4c334e0e4ff05d3a7ca9ebb832428c446cd0ae8d (patch)
tree3ba894c246f00c0e29db3dad41431cbf14c6c2fb /gcc/expr.cc
parent702a11ade2e87515a7dda1d1c028217bfe28e609 (diff)
downloadgcc-4c334e0e4ff05d3a7ca9ebb832428c446cd0ae8d.zip
gcc-4c334e0e4ff05d3a7ca9ebb832428c446cd0ae8d.tar.gz
gcc-4c334e0e4ff05d3a7ca9ebb832428c446cd0ae8d.tar.bz2
c++: Fix up ICE on __builtin_shufflevector constexpr evaluation [PR105871]
As the following testcase shows, BIT_FIELD_REF result doesn't have to have just integral type, it can also have vector type. And in that case cxx_eval_bit_field_ref just ICEs on it because it is unprepared for that case, creates the initial value with build_int_cst (sure, that one could be easily replaced with build_zero_cst) and then expects it can through shifts, ands and ors come up with the final value, but that doesn't work for vectors. We already call fold_ternary if whole is a VECTOR_CST, this patch does the same if the result doesn't have integral type. And, there is no guarantee fold_ternary will succeed and the callers certainly don't expect NULL being returned, so it also diagnoses those as non-constant and returns original t in that case. 2022-06-09 Jakub Jelinek <jakub@redhat.com> PR c++/105871 * constexpr.cc (cxx_eval_bit_field_ref): For BIT_FIELD_REF with non-integral result type use fold_ternary too like for BIT_FIELD_REFs from VECTOR_CST. If fold_ternary returns NULL, diagnose non-constant expression, set *non_constant_p and return t, instead of returning NULL. * g++.dg/pr105871.C: New test.
Diffstat (limited to 'gcc/expr.cc')
0 files changed, 0 insertions, 0 deletions