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 &q
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
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 (E
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
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: postmaster at raasu dot org
Target Milestone: ---
I have a simple program that fails to compile correctly on any common compiler:
int main()
{
int bits = 8;
char* a = (char*)malloc(1
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79938
--- Comment #3 from postmaster at raasu dot org ---
With -mssse3 instead of -msse4.1, the issue gets even worse:
---
...
pxor%xmm1, %xmm1
movl$.LC0, %esi
movl$1, %edi
movd%eax, %xmm0
movdqa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79938
--- Comment #2 from postmaster at raasu dot org ---
(In reply to Richard Biener from comment #1)
> The situation is slightly better with GCC 7, only two spill/loads are
> remaining.
> Possibly BIT_INSERT_EXPR helps here.
With gcc 6.2.
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: postmaster at raasu dot org
Target Milestone: ---
Created attachment 40906
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40906&action=edit
assembler output
When
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71659
postmaster at raasu dot org changed:
What|Removed |Added
CC||postmaster at raasu dot org
11 matches
Mail list logo
