Jeff Law <l...@redhat.com> wrote: > On 11/24/20 8:40 AM, Stefan Kanthak wrote: >> Andreas Schwab wrote: >> >>> On Nov 24 2020, Stefan Kanthak wrote: >>> >>>> 'nuff said >>> What's your point? >> Pinpoint deficiencies and bugs in GCC and libgcc, plus a counter >> example to your "argument"! >> I recommend careful reading. > Umm, you should broaden your horizons.
My horizon is as wide as the cap^Winability of GCC available for the machines I use. > The world is not an x86. The GCC available for the machines I use is only able to generate x86 code. > I'm pretty sure Andreas was referring to non-x86 targets. | On most 32-bit targets with -Os. Are avr or cr16 32-bit processors? > As Jakub has already indicated, your change will result in infinite > recursion on avr. I happened to have a cr16 handy and it looks like > it'd generate infinite recursion there too. JFTR: does GCC emit a warning then? If not: why not? Since I neither have an avr nor a cr16 here, and also no TR-440, no S/3x0, no Spectra-70, no PDP-11, no VAX, no SPARC, no MIPS, no PowerPC, no MC68k, no NSC16xxx and no NSC32xxx any more, GCC only gives me access to the x86 code it generates. > On other targets the routines you're changing won't be used because they > either have 64 bit shifts or the compiler can synthesize them from other > primitives that are available. These routines are documented in <https://gcc.gnu.org/onlinedocs/gccint/Integer-library-routines.html> and might be called by your users. > It's pointless to keep arguing on the shift stuff. What you've > submitted is fundamentally wrong in the context of gcc's libgcc2 > routines. It's that simple. If you keep arguing about it you're likely > just going to annoy those who can help you to the point where they won't > bother. Is there any documentation for (the design and restrictions of) libgcc2? The patches I sent for the shift and the comparision routines are based on the assumption that GCC generates code for "double-word" arithmetic inline. If it doesn't: where are __addDI3 and __subDI3 defined, and where are __adddi3, __addti3, __subdi3 and __subti3 documented? Since libgcc2.[hc] don't define them, and <https://gcc.gnu.org/onlinedocs/gccint/Integer-library-routines.html> doesn't document them, I had reason to believe that my assumption holds. > I think the bswapsi2 change will go forward, but it needs to be tested. Stefan