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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
