On 01/09/2017 08:18 PM, Richard W.M. Jones wrote:
On Mon, Jan 09, 2017 at 09:20:20AM +0100, Jakub Jelinek wrote:
> On Sat, Jan 07, 2017 at 11:15:28PM +0000, Richard W.M. Jones wrote:
>> On Fri, Jan 06, 2017 at 02:47:35AM +0100, Pavel Raiskup wrote:
>>> On Thursday, January 5, 2017 5:08:16 PM CET Stephen Gallagher wrote:
>>>> Two suggestions were raised as alternatives to the container approach:
>>>>
>>>> * Switch to using the Debian style of multi-arch layout, which instead
of
>>>> /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this
would
>>>> include the emergence of a de-facto standard for system layout between
the major
>>>> distributions.
>>>
>>> Isn't this just result of good marketing of "multi-arch"
distros? Because
>>> I fail to see where that approach is superior compared to what we have.
>>
>> Partly because there exist more than 2 architectures (think:
>> RV64G/RV64GC/RV128G, ARMv5/6/7/8, or less esoterically, having various
>
> Not all of ARM v5/6/7/8 is ABI incompatible. The FHS way of using suffixes
> for */lib<suffix> is able to deal with more than 2 multilibs, e.g. MIPS has
> 3 I think. And ISA flags you meantion (SSE, AVX) should not be separate
> multilib, those are just optimizations you can do in the same multilib, that
> can and should be resolved either completely inside of libraries that want
> to have optimized parts (using IFUNC, target_clones, ...)
I should note that RV64G vs RV64GC (compressed) is not something that
could be handled by ifuncs. It's a deep change that affects all the
generated code. I'm hoping that every other RISC-V extension _can_ be
handled only using ifuncs/target_clones etc.
Could you clarify why IFUNC doesn't work?
--
Cheers,
Carlos.