Re: Dealing with target variance

[Florian Weimer <fweimer at redhat dot com>]

* 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>?

Thanks,
Florian