On Fri, 1 Jun 2018, Joseph Myers wrote: > On Fri, 1 Jun 2018, Michael Meissner wrote: > > > I'm wondering if there are other suggestions to make this patch acceptable. > > > > As I mentioned previously, the initialization process needs to go through > > all > > of the widening tables in order to initialize all FP types, so we can't just > > arbitrarily eliminate IFmode from the widening table. > > Initialization that's meant to cover all floating-point modes logically > should not rely on everything being reachable by the "wider" relation. > > That is, I'd expect it to do something equivalent to > FOR_EACH_MODE_IN_CLASS (mode, MODE_FLOAT) rather than something based on > "wider".
The unfortunate thing is that all iterators are wrapped around the "wider" relationship - we do not have any other way to find related modes. So the concept that all modes in a class can be ordered after their width is baked in very deeply. That's IMHO something we need to eventually fix to avoid this kind of target-hook "hacks". Richard. > But if the initialization relies on some form of partial > ordering (initializing some modes relies on other modes having been > initialized first, in a way somehow related to the "wider" relation), it > may be more complicated than that.
