Re: Dealing with target variance

[Florian Weimer <fweimer at redhat dot com>]

* Florian Weimer:

> * Joseph Myers:
>
>> On Wed, 2 Oct 2019, Florian Weimer wrote:
>>
>>> The only concern I would have is something like generic → m68k →
>>> coldfire, where coldfire goes back to the generic default.  At that
>>
>> In that particular case you'd put it in sysdeps/m68k/m680x0/.
>
> Ah, good to know.
>
>>> point, it's no longer obvious in which direction the override works, you
>>> need to look at the file contents, and there is risk that we end up with
>>> the existing multitude of override mechanisms.
>>
>> In quite a few of these cases you need to look at the file contents 
>> anyway, because the override is conditional within the file in some 
>> architecture-specific way that might not correspond to sysdeps 
>> directories.  For example, sysdeps/mips/nan-high-order-bit.h tests 
>> __mips_nan2008.
>>
>>> Can we make the default definition the one for future targets?  Even if
>>
>> I think that's the right way to go.
>>
>> (In some cases there may not be a clear default that most future 
>> architectures are definitely going to choose.  E.g. tininess.h is an 
>> architecture property; the default is more or less arbitrarily "before 
>> rounding" but new architectures might choose either "before rounding" or 
>> "after rounding".)
>
> There are also cases where we'd prefer support, but new ISAs just may
> not have it (like PI_STATIC_AND_HIDDEN).
>
> For these property headers, should we add a new subdirectory for them?
> And use header names like <pros/inifini.h>?

Sorry, I meant to write <props/inifini.h>.

Florian