This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/56025] ARM NEON polynomial types have broken overload resolution


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56025

--- Comment #5 from Tejas Belagod <belagod at gcc dot gnu.org> ---
ACLE states that

"poly8_t and poly16_t are defined as unsigned integer types. It is unspecified
whether these are the same type as uint8_t and  uint16_t for overloading and
mangling purposes"

Presently, poly types are implemented as distinct types in the ARM backend with
default mangling which is wrong. This obviates the need for their own mangling
scheme in the ABI which it does not specify. Therefore, it cannot be modelled
as a distinct type until the ABI says that it is a distinct type. Also, poly8_t
and poly16_t are presently modelled as signed types which is incorrect. When we
change this to an unsigned type, it will be incompatible with legacy anyway wrt
mangling among other things. So, till the time the ABI decides to make poly
types as distinct types, we can model it as an unsigned type or as another type
name for uint8_t or uint16_t. This will disallow overloading of uint8_t and
poly8_t for eg and break current overloads, but correcting poly to unsigned
type is a greater good. This is also future-proof because if the ABI decides to
model poly and unsigned types as distinct types, previously disallowed
overloading will then be allowed which isn't breaking legacy in the broad
sense.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]