https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122483
--- Comment #33 from Richard Sandiford <rsandifo at gcc dot gnu.org> --- (In reply to Alex Coplan from comment #32) > (In reply to Richard Sandiford from comment #31) > > That said, perhaps a simpler approach would be define a new return type for > > TARGET_COMP_TYPE_ATTRIBUTES. E.g. -1 could mean that the type attributes > > are “strongly” incompatible and mustn't be merged. I can't remember whether > > that's already been discussed. > > I hadn't considered that. While it avoids introducing a new target hook, it > seems that it has the potential to be a bit more invasive to the front-end / > middle-end code. I can certainly give it a go, though. Ah, ok. It's probably not worth it then. The main justification was that it theoretically allowed targets to have both attributes that are incompatible yet mergeable and attributes that are “strongly” incompatible. But since TARGET_COMP_TYPE_ATTRIBUTES applies to two lists, the new return value wouldn't tell callers which attributes are which. That wouldn't be very convenient and wouldn't give good diagnostics. It would also make the hook harder to write, if a target really did support both. (I suppose the hook already has that problem with the return value of 2.)
