On 01/11/2024 11:24, Richard Earnshaw (lists) wrote: > On 01/11/2024 11:22, Jakub Jelinek wrote: >> On Fri, Nov 01, 2024 at 11:12:29AM +0000, Richard Earnshaw (lists) wrote: >>> As Jakub said in the PR, this is really just papering over a general >>> problem in the compiler. As such, it's OK for the gcc-14 branch, if we >>> really need it, but not really suitable for trunk. >>> >>> I think the problem is related to failing to correclty canonicalize >>> non-standard bool types in trunk_int_for_mode. The code there has: >>> >>> /* Canonicalize BImode to 0 and STORE_FLAG_VALUE. */ >>> if (smode == BImode) >>> return c & 1 ? STORE_FLAG_VALUE : 0; >>> >>> and that means we fail to generate canonical boolean values, so later on >>> the compiler asserts when trying to pick non-standard values out. >>> >>> Perhaps instead we need something like: >>> >>> /* Canonicalize scalar boolean modes to 0 and STORE_FLAG_VALUE. */ >>> if (smode >= MIN_MODE_BOOL && smode <= MAX_MODE_BOOL) >>> return c & 1 ? STORE_FLAG_VALUE : 0; >>> >>> Jakub? >> >> A mode which has 4 or 16 possible valid values, not just 2, shouldn't be >> considered a boolean mode, it is a partial int. >> >> Jakub >> > > Its a bool in just the same way that a bool is stored in a char. In this > case it's packed into 2 or 4 bits when put in a vector. > > R.
Actually, no it's not that simple. I need to go think about this some more... R.
