[PATCH] get rid of POPCOUNTCST* macros in libgcc2.c

2022-04-16 Thread Stefan Kanthak via Gcc-patches
Hi @ll, the "magic" constants 0x55...55, 0x33...33, 0x0f...0f and 0x01...01 used in the popcountsi2() and popcountdi2() functions defined in libgcc2.c are currently generated iterative via the 4 macros POPCOUNTCST, POPCOUNTCST8, POPCOUNTCST4 and POPCOUNTCST2 from 2 nibbles over 4 and 8 nibbles to

Re: [PATCH] Overflow-trapping integer arithmetic routines7code

2020-12-07 Thread Stefan Kanthak
Jeff Law wrote Wednesday, November 25, 2020 7:11 PM: > On 11/25/20 6:18 AM, Stefan Kanthak wrote: >> Jeff Law wrote: [...] >>> My inclination is to leave the overflow checking double-word multiplier >>> as-is. >> See but <https://gcc.gnu.org/piperm

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

2020-11-25 Thread Stefan Kanthak
Jeff Law wrote: [...] > By understanding how your proposed changes affect other processors, you > can write better changes that are more likely to get included. > Furthermore you can focus efforts on things that matter more in the real > world. DImode shifts in libgcc are _not_ useful to try an

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

2020-11-25 Thread Stefan Kanthak
Jakub Jelinek wrote: > On Wed, Nov 25, 2020 at 09:22:53PM +0100, Stefan Kanthak wrote: >> > 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 infin

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

2020-11-25 Thread Stefan Kanthak
Jeff Law 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

Re: [PATCH] Overflow-trapping integer arithmetic routines7code

2020-11-25 Thread Stefan Kanthak
Jeff Law wrote: > On 11/10/20 10:21 AM, Stefan Kanthak wrote: > >>> So with all that in mind, I installed everything except the bits which >>> have the LIBGCC2_BAD_CODE ifdefs after testing on the various crosses. >>> If you could remove the ifdefs on the a

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

2020-11-24 Thread Stefan Kanthak
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. Stefan

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

2020-11-24 Thread Stefan Kanthak
Andreas Schwab wrote 2020-11-11: > On Nov 10 2020, Stefan Kanthak wrote: > >> Eric Botcazou wrote: >> >>>> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() >>>> functions >>>> is rather bad, it yields bad machine code a

Re: [PATCH] Simplified construction of constants for __popcountSI2/__popcountDI2 in libgcc2.c

2020-11-20 Thread Stefan Kanthak
Jakub Jelinek wrote: > On Fri, Nov 20, 2020 at 11:08:41AM +0100, Stefan Kanthak wrote: >> The construction of the "magic" constants 0x55...55, 0x33...33, 0x0f...0f >> and 0x01...01 in __popcountSI2 and __popcountDI2 with macros is awkward; >> these constants can si

[PATCH] Simplified construction of constants for __popcountSI2/__popcountDI2 in libgcc2.c

2020-11-20 Thread Stefan Kanthak
The construction of the "magic" constants 0x55...55, 0x33...33, 0x0f...0f and 0x01...01 in __popcountSI2 and __popcountDI2 with macros is awkward; these constants can simply be written as ((UWtype) ~0 / 3), ((UWtype) ~0 / 5), ((UWtype) ~0 / 17) and ((UWtype) ~0 / 255) Stefan Kantha

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

2020-11-11 Thread Stefan Kanthak
, so (u) & 0x00ff is signed too -- and producing a negative value (or overflow) from the left-shift of a signed int, i.e. shifting into (or beyond) the sign bit, is undefined behaviour! JFTR: both -fsanitize=signed-integer-overflow and -fsanitize=undefined fail to catch this BUGBUGBUG, which surfaces on i386 and AMD64 with -O1 or -O0! Stefan Kanthak PS: even worse, -fsanitize=signed-integer-overflow fails to catch 1 << 31 or 128 << 24!

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

2020-11-10 Thread Stefan Kanthak
u]subDI3() functions ... which are but missing from libgcc.a Stefan Kanthak

[PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

2020-11-10 Thread Stefan Kanthak via Gcc-patches
() function uses SIGNED instead of unsigned mask values; cf. __bswapdi2() Stefan Kanthak libgcc2.diff Description: Binary data

Re: [PATCH] Overflow-trapping integer arithmetic routines7code

2020-11-10 Thread Stefan Kanthak
Jeff Law wrote: > On 10/5/20 10:49 AM, Stefan Kanthak wrote: >> The implementation of the functions __absv?i2(), __addv?i3() etc. for >> trapping integer overflow provided in libgcc2.c is rather bad. >> Same for __cmp?i2() and __ucmp?i2() >> >> At least for AMD6

[PATCH] Overflow-trapping integer arithmetic routines7code

2020-10-05 Thread Stefan Kanthak
The implementation of the functions __absv?i2(), __addv?i3() etc. for trapping integer overflow provided in libgcc2.c is rather bad. Same for __cmp?i2() and __ucmp?i2() At least for AMD64 and i386 processors GCC creates awful to horrible code for them: see