On 11/11/20 1:33 AM, Stefan Kanthak wrote:
> Jakub Jelinek wrote:
>
>> On Tue, Nov 10, 2020 at 04:48:10PM -0700, Jeff Law via Gcc-patches wrote:
@@ -486,10 +425,10 @@
SItype
__bswapsi2 (SItype u)
{
- return u) & 0xff00) >> 24)
- | (((u) & 0x00ff)
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
On 11/25/20 2:22 PM, Stefan Kanthak wrote:
> 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
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 infinite recursion there too.
>>
>> JFTR:
On 11/25/20 1:22 PM, Stefan Kanthak wrote:
> 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, plus a
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 infinite recursion there too.
>
> JFTR: does GCC emit a warning then?
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, plus a counter
>> example to your "argument"!
>> I recommend careful
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
On Nov 24 2020, Stefan Kanthak wrote:
> Pinpoint deficiencies and bugs in GCC and libgcc, plus a counter
> example to your "argument"!
In which way?
> I recommend careful reading.
Yes, I do.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510
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
On Nov 24 2020, Stefan Kanthak wrote:
> 'nuff said
What's your point?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
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 at least on i386 and AMD64. Since
GCC knows how to
On 11/10/20 2:09 PM, Jeff Law wrote:
> On 11/10/20 1:14 PM, Jakub Jelinek via Gcc-patches wrote:
>> On Tue, Nov 10, 2020 at 08:44:32PM +0100, Stefan Kanthak wrote:
>>> Eric Botcazou wrote:
>>>
> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3()
> functions
> is
On 11/11/20 2:55 AM, Jakub Jelinek wrote:
> On Wed, Nov 11, 2020 at 09:33:00AM +0100, Stefan Kanthak wrote:
>> Ouch: that's but not the point here; what matters is the undefined behaviour
>> of
>> ((u) & 0x00ff) << 24
>>
>> 0x00ff is a signed int, so (u) & 0x00ff is signed
On Wed, 11 Nov 2020, Jakub Jelinek via Gcc-patches wrote:
> So indeed, 0x80 << 24 is UB in C99/C11 and C++98, unclear in C89 and
> well defined in C++11 and later. I don't know if C2X is considering
> mandating two's complement and making it well defined like C++20 did.
C2x requires two's
On Wed, Nov 11, 2020 at 09:33:00AM +0100, Stefan Kanthak wrote:
> Ouch: that's but not the point here; what matters is the undefined behaviour
> of
> ((u) & 0x00ff) << 24
>
> 0x00ff is a signed int, so (u) & 0x00ff is signed too -- and producing
> a negative value (or overflow)
Jakub Jelinek wrote:
> On Tue, Nov 10, 2020 at 04:48:10PM -0700, Jeff Law via Gcc-patches wrote:
>> > @@ -486,10 +425,10 @@
>> > SItype
>> > __bswapsi2 (SItype u)
>> > {
>> > - return u) & 0xff00) >> 24)
>> > - | (((u) & 0x00ff) >> 8)
>> > - | (((u) & 0xff00) << 8)
>> >
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 at least on i386 and AMD64. Since
>>> GCC knows how to shift integers twice the register size these
On Tue, Nov 10, 2020 at 04:48:10PM -0700, Jeff Law via Gcc-patches wrote:
> > @@ -486,10 +425,10 @@
> > SItype
> > __bswapsi2 (SItype u)
> > {
> > - return u) & 0xff00) >> 24)
> > - | (((u) & 0x00ff) >> 8)
> > - | (((u) & 0xff00) << 8)
> > - | (((u) & 0x00ff)
On 11/10/20 10:59 AM, Stefan Kanthak via Gcc-patches wrote:
> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions
> is rather bad, it yields bad machine code at least on i386 and AMD64.
> Since GCC knows how to shift integers twice the register size these functions
> can
On 11/10/20 2:17 PM, Jakub Jelinek wrote:
> On Tue, Nov 10, 2020 at 02:09:20PM -0700, Jeff Law wrote:
>> On 11/10/20 1:14 PM, Jakub Jelinek via Gcc-patches wrote:
>>> On Tue, Nov 10, 2020 at 08:44:32PM +0100, Stefan Kanthak wrote:
Eric Botcazou wrote:
>> The implementation of the
On 11/10/20 1:14 PM, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Nov 10, 2020 at 08:44:32PM +0100, Stefan Kanthak wrote:
>> Eric Botcazou wrote:
>>
The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3()
functions
is rather bad, it yields bad machine code at least
On 11/10/20 12:44 PM, Stefan Kanthak wrote:
> Eric Botcazou wrote:
>
>>> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions
>>> is rather bad, it yields bad machine code at least on i386 and AMD64. Since
>>> GCC knows how to shift integers twice the register size these
On Tue, Nov 10, 2020 at 02:09:20PM -0700, Jeff Law wrote:
>
> On 11/10/20 1:14 PM, Jakub Jelinek via Gcc-patches wrote:
> > On Tue, Nov 10, 2020 at 08:44:32PM +0100, Stefan Kanthak wrote:
> >> Eric Botcazou wrote:
> >>
> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3()
>
On 11/10/20 1:14 PM, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Nov 10, 2020 at 08:44:32PM +0100, Stefan Kanthak wrote:
>> Eric Botcazou wrote:
>>
The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3()
functions
is rather bad, it yields bad machine code at least
On Tue, Nov 10, 2020 at 08:44:32PM +0100, Stefan Kanthak wrote:
> Eric Botcazou wrote:
>
> >> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3()
> >> functions
> >> is rather bad, it yields bad machine code at least on i386 and AMD64. Since
> >> GCC knows how to shift integers
Eric Botcazou wrote:
>> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions
>> is rather bad, it yields bad machine code at least on i386 and AMD64. Since
>> GCC knows how to shift integers twice the register size these functions can
>> be written as one-liners.
>
>
On 11/10/20 11:09 AM, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Nov 10, 2020 at 06:59:30PM +0100, Stefan Kanthak via Gcc-patches
> wrote:
>> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions
>> is rather bad, it yields bad machine code at least on i386 and AMD64.
On Tue, Nov 10, 2020 at 06:59:30PM +0100, Stefan Kanthak via Gcc-patches wrote:
> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions
> is rather bad, it yields bad machine code at least on i386 and AMD64.
> Since GCC knows how to shift integers twice the register size
On Tue, Nov 10, 2020 at 06:59:30PM +0100, Stefan Kanthak via Gcc-patches wrote:
> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions
> is rather bad, it yields bad machine code at least on i386 and AMD64.
> Since GCC knows how to shift integers twice the register size
> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions
> is rather bad, it yields bad machine code at least on i386 and AMD64. Since
> GCC knows how to shift integers twice the register size these functions can
> be written as one-liners.
These functions are precisely
The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions
is rather bad, it yields bad machine code at least on i386 and AMD64.
Since GCC knows how to shift integers twice the register size these functions
can be written as one-liners.
The implementation of the __bswapsi2()
32 matches
Mail list logo
