On Thu, Jan 15, 2026 at 12:23 PM Jeffrey Law <[email protected]> wrote: > > > > On 1/8/2026 6:16 AM, Peter Damianov wrote: > > The C and C++ frontends were incorrectly generating RDIV_EXPR instead of > > TRUNC_DIV_EXPR for division of vectors with enum element types. > > > > The issue was that the division operator handling only checked for > > INTEGER_TYPE (and BITINT_TYPE in the C frontend) when determining whether > > to use integer division. However, ENUMERAL_TYPE is also represents an > > integral type. When enum types were used in vectors, the frontend would > > incorrectly fall through to RDIV_EXPR, causing an ICE during the > > veclower2 pass because RDIV_EXPR is only valid for floating-point types. > > > > The fix adds ENUMERAL_TYPE to the type checks. Note that scalar enum > > operands are promoted to int before reaching this code, but enum > > *vectors* are not promoted. > > > > gcc/c/ChangeLog: > > > > PR c/123437 > > * c-typeck.cc (build_binary_op): Include ENUMERAL_TYPE in > > integer division check for vectors. > > > > gcc/cp/ChangeLog: > > > > PR c/123437 > > * typeck.cc (cp_build_binary_op): Include ENUMERAL_TYPE in > > integer division check. > > > > gcc/testsuite/ChangeLog: > > > > PR c/123437 > > * c-c++-common/pr123437.c: New test. > I think Jakub's comment probably points to a slightly better patch. In > particular his patch/comment only allow the ENUMERAL_TYPE for tcode > when the code is a VECTOR_TYPE. Seems safer at this point. > > OK with that change (which I think makes it idential to Jakub's patch in > c#5 in the bugzilla case.
Jakub posted his patch here already: https://gcc.gnu.org/pipermail/gcc-patches/2026-January/705874.html Thanks, Andrew > > Jeff
