https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108580
--- Comment #8 from postmaster at raasu dot org ---
I know enough C that you can't write code like:
int i = 0x;
This is not equal to:
int i = -1;
or
int i = (-1);
---
Largest literal you can assign to "int" is "0x7FFF". Any lar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108580
--- Comment #6 from postmaster at raasu dot org ---
There is wrong assumption again... Literal "1" is always unsigned as there is
no implicit signed literals, even though there is explicit signed literals...
When somebody writes "-1" it is treate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108580
--- Comment #4 from postmaster at raasu dot org ---
I'm not mixing things... The assembly code clearly says it's using 32-bit
shift. Both with 32-bit and 64-bit architectures by default left-hand side of
shift operation is 32 bits (EAX instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108580
--- Comment #2 from postmaster at raasu dot org ---
If I try to shift to highest bit of signed type, the compiler will reject the
code and that is correct behaviour. The point here is that left-hand side of
the shift operation is by default same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108580
Bug ID: 108580
Summary: gcc treats shifts as signed operation, does wrong
promotion
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79938
--- Comment #6 from postmaster at raasu dot org ---
I tried identical code using intrinsics with both clang and gcc:
clang:
movdqa xmm1,XMMWORD PTR [rip+0xd98]# 402050 <_IO_stdin_used+0x50>
pand xmm1,xmm0
movdqa xmm2,xmm0
pshufb xm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79938
--- Comment #5 from postmaster at raasu dot org ---
My brains think it's basically four shuffles and three vector additions. It's
part of vectorized adler32 implementation, so there is real-life use for the
optimization.
