https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77823
--- Comment #4 from Zdenek Sojka <zsojka at seznam dot cz> --- (In reply to Jakub Jelinek from comment #3) > Created attachment 39735 [details] > gcc7-pr77823.patch > > Short patch to fix the ICE. > > That said, we should think of what to do with the generic vector extension > for -fsanitize=undefined, right now we don't instrument anything. > For stuff like shift, division, signed-integer-overflow, maybe also > bool/enum for vectors of bool or enum, float-divide/float-cast, we either > should modify > the libubsan library, so that it would handle TK_Vector_Integer and > TK_Vector_Float, likely use always passing by reference and somehow encode > both the bit width of the elements and their kinds and also the number of > elements in the vector (or log2 thereof) in the TypeInfo field and teach it > how to print vectors {El1, El2, El3, El4} etc.? - then we could at least for > some of the tests use also vector operations, e.g. for vector << vector > shifts compare the second operand against vector containing element > precision repeated, etc., or instead instrument it as a loop over number of > elements, checking each operation separately (and reporting the individual > overflow on each element separately, then as value we'd just use the > scalars). Adding ubsan support would be very useful, since when auto-reducing a wrong-code bug, I often end up with useless code like: typedef unsigned V __attribute__((vector_size(64))); int foo(V v) { /* returning out-of-bounds item, not handled by ubsan */ return v[127]; } or V foo(V v) { /* out-of-range shift, not handled by ubsan */ return v << 127; } even though I am using -fsanitize=undefined.