https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123279
--- Comment #11 from Robin Dapp <rdapp at gcc dot gnu.org> --- Hmm, I'm not sure how partitioning the function codes would help us. The problem is that TARGET_XTHEADVECTOR removes/takes away builtins that are usually available (those where LMUL < 1). So when "polluting" (enabling all available extensions in order to enable all builtins) we would actually need to _disable_ XTHEADVECTOR so the LMUL<1 functions become available. However, when doing so we run into type aliasing issues: During first builtin type registration XTHEADVECTOR is still enabled and we use 128-bit vectors. At that point we don't enable LMUL<1 types. In the second builtin type registration (after polluting the flags) XTHEADVECTOR is disabled but we use 4096-bit vectors. We enable LMUL<1 types. However as we left some types uninitialized in the first phase, very small LMUL 1/4 or LMUL 1/8 types of the second phase start aliasing very large types e.g. LMUL4, LMUL8 types from the first phase. That leads to ambiguous builtin definitions. Not fun :) Maybe I can't see the forest for the trees and there's a simple approach.
