Hello, On Wed, 18 Mar 2026, Andrew Stubbs wrote:
> On 17/03/2026 15:25, Andrew Stubbs wrote: > > I have run out of places that ICE or cause test failures (for C) when the > > mode is a vector. Do you have any other suggestions to find them? > > > > (I already plan to test C++ and Fortran.) > > I found some problems .... > > TARGET_POINTER_MODE and TARGET_ADDR_SPACE_POINTER mode only return one > mode, but now we have multiple valid modes: DImode, V2DImode, V4DImode, > etc. They also return scalar_int_mode so I can't even invent a new > address space for the vector pointers. > > Same for TARGET_ADDR_SPACE_ADDRESS_MODE. > > TARGET_VALID_POINTER_MODE and TARGET_ADDR_SPACE_VALID_POINTER_MODE only > accept scalar_int_mode, so automatically exclude vector pointers. > > These can be patched to use plain machine_mode, perhaps, or keep them > all scalar and add a new TARGET_ADDR_SPACE_ALLOWS_VECTOR_POINTERS to fix > the problem at the call sites, which might make more sense? IMHO: In my mind "being a pointer" (pointer_mode) and "being a multitude of things" (vector) are orthogonal. So, everything about validity of POINTER_MODE would remain unchanged, in particular it would remain one of the scalar_int_modes (and one depending on address-space while at it). But what is added is a differentiation between what a valid pointer mode is, and what a valid MEM address mode is. The latter would now become "a vector (possibly 1-sized) of valid_pointer_mode() entities". To properly implement that differentiation might involve some legwork in the middle end, I don't know :) Possibly its easier to conflate the two concepts and accept vector_int_mode for pointer_mode. It feels wrong, though. Ciao, Michael.
