Undeliverable: Toll increase report

[postmaster]

Delivery has failed to these recipients or distribution lists:

siuto...@deltadentalks.com
The recipient's e-mail address was not found in the recipient's e-mail system. 
Microsoft Exchange will not try to redeliver this message for you. Please check 
the e-mail address and try resending this message, or provide the following 
diagnostic text to your system administrator.


Sent by Microsoft Exchange Server 2007






Diagnostic information for administrators:

Generating server: global.deltadentalks.com

siuto...@deltadentalks.com
#550 5.1.1 RESOLVER.ADR.RecipNotFound; not found ##

Original message headers:

Received: from ddksexg03.deltadentalks.com (10.156.5.26) by
 DDKSEXGVM01.global.deltadentalks.com (10.156.1.61) with Microsoft SMTP Server
 (TLS) id 8.3.389.2; Tue, 19 May 2015 07:41:08 -0500
Received: from p01c11m075.mxlogic.net (208.65.144.247) by
 ddksexg03.deltadentalks.com (10.156.5.26) with Microsoft SMTP Server id
 8.3.327.1; Tue, 19 May 2015 07:40:59 -0500
Authentication-Results: p01c11m075.mxlogic.net; spf=softfail
Received: from unknown [85.31.195.58] (EHLO gnu.org)by
 p01c11m075.mxlogic.net(mxl_mta-8.4.0-1) over TLS secured channel   with 
ESMTP
 id e5f2b555.0.9226366.00-2357.19170389.p01c11m075.mxlogic.net (envelope-from
 );Tue, 19 May 2015 06:41:04 -0600 (MDT)
Received: from oLqM6.gnu.org (oLqM6.gnu.org [129.171.183.190])  by CO28eF.com
 (Postfix) with ESMTP id 57C9D40165 for ; Tue, 
19
 May 2015 14:41:01 +0100 (CEST)
Received: from [156.117.189.160] by 8aHk.XlTDiJrY.gnu.org (via HTTP); Tue, 19
 May 2015 14:41:01 +0100
Date: Tue, 19 May 2015 14:41:01 +0100
From: bug-gcc 
Message-ID: <555b2f5d.87985...@gnu.org>
To: 
Subject: Toll increase report
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="--09050100080209060701"
X-AnalysisOut: [v=2.1 cv=BaDM09d2 c=1 sm=1 tr=0 a=cDoOgBah9ZqUdf9C08b/pQ==]
X-AnalysisOut: [:117 a=cDoOgBah9ZqUdf9C08b/pQ==:17 a=BLceEmwcHowA:10 a=mDV]
X-AnalysisOut: [3o1hI:8 a=YlVTAMxI:8 a=olOGUkSe:8 a=h1PgugrvaO]
X-AnalysisOut: [0A:10 a=4xCTByIj4C25-_FgdyMA:9 a=CjuIK1q_8ugA:10 a=I7TjC_d]
X-AnalysisOut: [EBrwA:10 a=qc1Ymo3KQXUA:10 a=Z7bxiBghPAIA:10 a=WZNIhnmAJye]
X-AnalysisOut: [QfQF1HQsA:9 a=rA8_hIf25Q8PTfa9Kg4A:14 a=IKIoO-ieCDEA:10]
Received-SPF: SoftFail (p01c11m075.mxlogic.net: transitioning domain of gnu.org 
does not designate 85.31.195.58 as permitted sender)
X-Spam: [F=0.648000; B=0.500(0); spf=0.500; STSI=0.500(-1); STSM=0.450(-1); 
CM=0.500; CY=0.50; MH=0.900(2015051905); S=0.200(2014051901); SC=]
X-MAIL-FROM: 
X-SOURCE-IP: [85.31.195.58]
Return-Path: bug-...@gnu.org


-
Content-Type: message/delivery-status

Reporting-MTA: dns;global.deltadentalks.com
Received-From-MTA: dns;ddksexg03.deltadentalks.com
Arrival-Date: Tue, 19 May 2015 12:41:08 +

Final-Recipient: rfc822;siuto...@deltadentalks.com
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp;550 5.1.1 RESOLVER.ADR.RecipNotFound; not found

MDaemon Notification -- Attachment Removed

[Postmaster]

---
MDaemon has detected restricted attachments within an email message
---

>From  : bug-...@gnu.org
To: anca.ghi...@cargus.ro
Subject   : adjustment reminder 
Message-ID: <555b2f72.73251...@gnu.org>

-
Attachment(s) removed
-
Doc#106694.zip (fax2_data.exe)

Delivery report

[postmaster--- via Gcc-bugs]

Hello, this is the mail server on mailmarketingworldbee.live.

I am sending you this message to inform you on the delivery status of a
message you previously sent.  Immediately below you will find a list of
the affected recipients;  also attached is a Delivery Status Notification
(DSN) report in standard format, as well as the headers of the original
message.

delivery failed; will not continue trying
Reporting-MTA: dns;mailmarketingworldbee.live
X-PowerMTA-VirtualMTA: web1
Received-From-MTA: dns;msn.com (37.49.230.85)
Arrival-Date: Mon, 18 May 2020 11:49:04 +0800

Final-Recipient: rfc822;gcc-bugs@gcc.gnu.org
Action: failed
Status: 5.7.1 (delivery not authorized)
Remote-MTA: dns;gcc.gnu.org (8.43.85.97)
Diagnostic-Code: smtp;550 5.7.1 Blocked by SpamAssassin
X-PowerMTA-BounceCategory: spam-related
From: gcc.gnu.org 
To: gcc-bugs@gcc.gnu.org
Subject: You have 3 new pending mails on your email portal
Date: 18 May 2020 05:48:53 +0200
Message-ID: <20200518054852.4404bec11d810...@gcc.gnu.org>
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

[Bug target/71659] _xgetbv intrinsic missing

[postmaster at raasu dot org]

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

--- Comment #2 from postmaster at raasu dot org ---
Portability is one main reason to add missing intrinsics... with combination of
cpuid check and _xgetbv() we can cleanly check if AVX or MPX is available at
run-time. We can also check specific instructions during configure process to
see if we need to add workarounds for bad or missing functions/intrinsics.

Some developers think that cleanliness of the code is more important than need
to reduplicate hand-written assembler code every time for optimal performance.

We have to remember that gcc is not only used for BSD-like operating systems,
including OS/X, Linux, *BSD etc, but for Cygwin, MSYS/MSYS2 and MinGW which
benefit from gcc being as close as possible compiler of Visual C++ regarding
intrinsics support.

[Bug c/79938] New: gcc unnecessarily spills xmm register to stack when inserting vector items

[postmaster at raasu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79938

Bug ID: 79938
   Summary: gcc unnecessarily spills xmm register to stack when
inserting vector items
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: 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 adding together values from one vector and storing the results to another,
gcc uses two xmm registers instead of one and spills the second xmm register to
stack when it runs out of general purpose registers.

Instead of spilling the second xmm register to stack, it should use only one
xmm register as destination, because the addition is already being done using
four general purpose registers.

Using gcc -msse4.1 -O3 -S hadd.c -Wall -Wextra -fno-strict-aliasing -fwrapv -o
hadd.s

mika@LENOVO:~$ gcc --version
gcc (Ubuntu 6.2.0-3ubuntu11~14.04) 6.2.0 20160901
---
#include 
#include 
#include 

typedef uint8_t   v1si __attribute__ ((vector_size (16)));
typedef uint16_t  v2si __attribute__ ((vector_size (16)));
typedef uint32_t  v4si __attribute__ ((vector_size (16)));
typedef uint64_t  v8si __attribute__ ((vector_size (16)));

static __m128i haddd_epu8(__m128i a)
{
  v1si b = (v1si)a;
  v4si ret;
  ret[0]  = (b[ 0] + b[ 1]) + (b[ 2] + b[ 3]);
  ret[1]  = (b[ 4] + b[ 5]) + (b[ 6] + b[ 7]);
  ret[2]  = (b[ 8] + b[ 9]) + (b[10] + b[11]);
  ret[3]  = (b[12] + b[13]) + (b[14] + b[15]);
  return (__m128i)ret;
}

int main(int argc, char *argv[])
{
  __m128i a = _mm_set1_epi8(atoi(argv[1]));
  __m128i b = haddd_epu8(a);
  v4si c = (v4si)b;
  printf("b[0] = %i, b[1] = %i, b[2] = %i, b[3] = %i\n", c[0], c[1], c[2],
c[3]);
}

[Bug c/79938] gcc unnecessarily spills xmm register to stack when inserting vector items

[postmaster at raasu dot org]

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.0 and
gcc -msse4.1 -mtune=core2 -O3 -S hadd.c -Wall -Wextra -fno-strict-aliasing
-fwrapv -o hadd.s

The resulting assembler output is almost perfect, but adding -mtune=core2 kinda
makes the code optimal only for Intel processors.

---
...
pxor%xmm1, %xmm1
movl$1, %edi
movd%eax, %xmm0
pshufb  %xmm1, %xmm0
pextrb  $1, %xmm0, %edx
pextrb  $0, %xmm0, %eax
addl%edx, %eax
pextrb  $2, %xmm0, %edx
addl%edx, %eax
pextrb  $4, %xmm0, %ecx
pextrb  $3, %xmm0, %edx
addl%eax, %edx
pextrb  $5, %xmm0, %eax
addl%eax, %ecx
pextrb  $6, %xmm0, %eax
addl%eax, %ecx
pextrb  $9, %xmm0, %esi
pextrb  $7, %xmm0, %eax
addl%eax, %ecx
pextrb  $8, %xmm0, %eax
addl%esi, %eax
pextrb  $10, %xmm0, %esi
addl%esi, %eax
pextrb  $11, %xmm0, %esi
addl%esi, %eax
pextrb  $13, %xmm0, %esi
movd%eax, %xmm1
pextrb  $12, %xmm0, %eax
addl%esi, %eax
pextrb  $14, %xmm0, %esi
addl%eax, %esi
pextrb  $15, %xmm0, %eax
movd%edx, %xmm0
addl%esi, %eax
pinsrd  $1, %ecx, %xmm0
movl$.LC0, %esi
pinsrd  $1, %eax, %xmm1
xorl%eax, %eax
punpcklqdq  %xmm1, %xmm0
...

[Bug c/79938] gcc unnecessarily spills xmm register to stack when inserting vector items

[postmaster at raasu dot org]

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  %xmm0, %xmm4
pshufb  %xmm1, %xmm4
movaps  %xmm4, (%rsp)
movzbl  (%rsp), %eax
movaps  %xmm4, 224(%rsp)
movzbl  225(%rsp), %edx
movaps  %xmm4, 208(%rsp)
movaps  %xmm4, 192(%rsp)
movaps  %xmm4, 176(%rsp)
addl%edx, %eax
movzbl  210(%rsp), %edx
movaps  %xmm4, 160(%rsp)
movaps  %xmm4, 144(%rsp)
movaps  %xmm4, 128(%rsp)
movaps  %xmm4, 112(%rsp)
addl%edx, %eax
movzbl  195(%rsp), %edx
movaps  %xmm4, 96(%rsp)
movzbl  105(%rsp), %ecx
movaps  %xmm4, 80(%rsp)
movaps  %xmm4, 64(%rsp)
movaps  %xmm4, 48(%rsp)
addl%edx, %eax
movzbl  165(%rsp), %edx
movaps  %xmm4, 32(%rsp)
movd%eax, %xmm0
movzbl  180(%rsp), %eax
movaps  %xmm4, 16(%rsp)
movaps  %xmm4, 240(%rsp)
addl%edx, %eax
movzbl  150(%rsp), %edx
addl%edx, %eax
movzbl  135(%rsp), %edx
addl%eax, %edx
movzbl  120(%rsp), %eax
movd%edx, %xmm6
punpckldq   %xmm6, %xmm0
addl%ecx, %eax
movzbl  90(%rsp), %ecx
addl%ecx, %eax
movzbl  75(%rsp), %ecx
addl%ecx, %eax
movzbl  45(%rsp), %ecx
movd%eax, %xmm1
movzbl  60(%rsp), %eax
addl%ecx, %eax
movzbl  30(%rsp), %ecx
addl%ecx, %eax
movzbl  15(%rsp), %ecx
addl%ecx, %eax
movd%eax, %xmm5
xorl%eax, %eax
punpckldq   %xmm5, %xmm1
punpcklqdq  %xmm1, %xmm0
movdqa  %xmm0, %xmm2
movd%xmm0, %edx
pshufd  $255, %xmm0, %xmm3
punpckhdq   %xmm0, %xmm2
pshufd  $85, %xmm0, %xmm1
...
---

Notice all the lines starting with "movaps  %xmm4,"
Same register contents are polluted all over the stack.

[Bug middle-end/21786] Segmentation fault under FreeBSD 5.3-RELEASE-p15

[postmaster at t-hosting dot hu]

--- Comment #4 from postmaster at t-hosting dot hu  2005-10-28 14:31 ---
(In reply to comment #3)
> Seems fixed in "3.4.5 20050809".  Can you try a newer 3.4.5?
> 

It's okay now, but there's a build error. I susoect the code is not for gcc
3.4.5. I got this:

CC='/usr/local/bin/gcc34' mkdep -f .depend -a -DCRT_BEGIN   -DIN_GCC
-DHAVE_LD_EH_FRAME_HDR -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config
-I/usr/src/gnu/lib/csu/../../../contrib/gcc -I.
-I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools
/usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c
/usr/local/bin/gcc34 -s -Os -pipe -march=athlon64  -DIN_GCC
-DHAVE_LD_EH_FRAME_HDR -finhibit-size-directive -fno-inline-functions 
-fno-exceptions -fno-zero-initialized-in-bss  -fno-omit-frame-pointer
-fno-unit-at-a-time -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config
-I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. 
-I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools  -g0 -DCRT_BEGIN  -c -o
crtbegin.o /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c
/usr/local/bin/gcc34 -s -Os -pipe -march=athlon64  -DIN_GCC
-DHAVE_LD_EH_FRAME_HDR -finhibit-size-directive -fno-inline-functions 
-fno-exceptions -fno-zero-initialized-in-bss  -fno-omit-frame-pointer
-fno-unit-at-a-time -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config
-I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. 
-I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools  -g0 -DCRT_END  -c -o crtend.o
/usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c
/usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:451: error: mode `SI'
applied to inappropriate type
*** Error code 1


-- 

postmaster at t-hosting dot hu changed:

   What|Removed |Added

 Status|WAITING |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21786

[Bug c/21786] New: Segmentation fault under FreeBSD 5.3-RELEASE-p15

[postmaster at t-hosting dot hu]

While doing a full recompile of the whole FreeBSD 5.3-RELEASE-p15 source tree
the gcc 3.4.5 snapshot crashed with a segfault.



The comamnd line that triggered the error:

/usr/local/bin/gcc34 -s -Os -pipe -march=athlon64 -I.
-I/usr/src/gnu/usr.bin/binutils/libbfd
-I/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd
-I/usr/obj/usr/src/amd64/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd
-I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/include
-D_GNU_SOURCE
-I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd
-DSELECT_ARCHITECTURES="&bfd_i386_arch" -DHAVE_bfd_elf64_x86_64_vec
-DHAVE_bfd_elf32_i386_freebsd_vec -DSELECT_VECS=" &bfd_elf64_x86_64_vec
,&bfd_elf32_i386_freebsd_vec" -DDEFAULT_VECTOR=bfd_elf64_x86_64_vec 
-I/usr/obj/usr/src/amd64/legacy/usr/include -c
/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf.c
/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf.c: In
function `_bfd_elf_compute_section_file_positions':
/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf.c:3143:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
*** Error code 1



The snapshot version information:

[EMAIL PROTECTED] /usr/local/bin/gcc34 -v
Reading specs from /usr/local/lib/gcc/x86_64-portbld-freebsd5.3/3.4.5/specs
Configured with: ./..//gcc-3.4-20050524/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=34
--with-gxx-include-dir=/usr/local/lib/gcc/x86_64-portbld-freebsd5.3/3.4.5/include/c++/
--disable-shared --disable-libgcj --prefix=/usr/local x86_64-portbld-freebsd5.3
Thread model: posix
gcc version 3.4.5 20050524 (prerelease) [FreeBSD]



The uname -a output of the computer:

[EMAIL PROTECTED] uname -a
FreeBSD server.t-hosting.hu 5.3-RELEASE-p15 FreeBSD 5.3-RELEASE-p15 #0: Thu May
26 14:21:20 CEST 2005
[EMAIL PROTECTED]:/usr/src/sys/amd64/compile/FREEBSD  amd64


The used macros and flags:

CC=/usr/local/bin/gcc34
CFLAGS=-s -Os -pipe -march=athlon64
COPTFLAGS=-s -Os -march=athlon64 -pipe



The same code compiles in same circumstances with the stock gcc 3.4.2. If You
need further information, contact me.

Regards,

Gábor Kövesdán

-- 
   Summary: Segmentation fault under FreeBSD 5.3-RELEASE-p15
   Product: gcc
   Version: 3.4.5
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: postmaster at t-hosting dot hu
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21786

[Bug c/21786] Segmentation fault under FreeBSD 5.3-RELEASE-p15

[postmaster at t-hosting dot hu]

-- 
   What|Removed |Added

   GCC host triplet||amd64
 GCC target triplet||amd64


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21786

[Bug c/108580] New: gcc treats shifts as signed operation, does wrong promotion

[postmaster at raasu dot org via Gcc-bugs]

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
  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 << bits);
   char* b = (char*)malloc(1 << bits);
   memcpy(b, a, 1 << bits);
   return 0;
}

when assembled with "gcc -S", the result is

main:
.LFB6:
.cfi_startproc
endbr64
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$32, %rsp
movl$8, -20(%rbp)
movl-20(%rbp), %eax
movl$1, %edx
movl%eax, %ecx
sall%cl, %edx
movl%edx, %eax
cltq
movq%rax, %rdi
callmalloc@PLT
movq%rax, -16(%rbp)
movl-20(%rbp), %eax
movl$1, %edx
movl%eax, %ecx
sall%cl, %edx
movl%edx, %eax
cltq
movq%rax, %rdi
callmalloc@PLT
movq%rax, -8(%rbp)
movl-20(%rbp), %eax
movl$1, %edx
movl%eax, %ecx
sall%cl, %edx
movl%edx, %eax
movslq  %eax, %rdx
movq-16(%rbp), %rcx
movq-8(%rbp), %rax
movq%rcx, %rsi
movq%rax, %rdi
callmemcpy@PLT
movl$0, %eax
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc

The part that is incorrect is:

sall%cl, %edx
movl%edx, %eax
cltq
movq%rax, %rdi

It should zero-extend before the shift, but instead it sign-extends after the
shift... Bit shifting is always unsigned operation. It correctly determines the
function requires 64-bit parameter, but fails to determine it's unsigned.
Integer promotion rules say that unsigned type in expression must be promoted
to larger unsigned type if it can hold the result. As bit shift is unsigned
operation, the temporary should also be unsigned.

Stock gcc headers don't have UINTPTR_C() macro which could be used to
explicitly cast the constant "1" to pointer size to give hint that the shift is
indeed unsigned operation.

gcc version is: gcc (Ubuntu 12.2.0-3ubuntu1) 12.2.0

[Bug c/108580] gcc treats shifts as signed operation, does wrong promotion

[postmaster at raasu dot org via Gcc-bugs]

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 size as "int", as in 32 bits, which
means it can't be promoted to "int" again. 

This behaviour is same with gcc, clang and Visual C++, but Visual C++ correctly
gives warning that the code is ambiguous (exact message is "Arithmetic
overflow"), however it's also C++ compiler, which might validate the code with
C++ rules, not C.

[Bug c/108580] gcc treats shifts as signed operation, does wrong promotion

[postmaster at raasu dot org via Gcc-bugs]

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 RAX) and right-hand size is 8 bits
(CL instead of CX, ECX or RCX). 

Using "1U << bits" to explicitly force unsigned 32-bit shift would be incorrect
code. "(size_t)1 << bits", which is also "incorrect" code, would surprisingly
result in correct code generation with both 32-bit and 64-bit targets.

Result of any left shift involving negative numbers, including left-shifting
non-zero bit to highest bit of signed integer, is undefined.

[Bug c/108580] gcc treats shifts as signed operation, does wrong promotion

[postmaster at raasu dot org via Gcc-bugs]

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 treated as expression "0 - 1", not a literal
"negative one"... This is because subtract operator has higher precedence.
Empty literal always equals to literal "0".

[Bug c/108580] gcc treats shifts as signed operation, does wrong promotion

[postmaster at raasu dot org via Gcc-bugs]

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 larger value must
be either result of expression or another variable, otherwise it will result in
"arithmetic" overflow warning.

Some literals and operations are inherently unsigned, no matter what generic
rules say. As I already said, writing "1u << bits" would be incorrect, and
strict-conforming or "pedantic" compiler would throw warning as the types don't
match and implicit conversion doesn't happen with sizes larger than 32 bits.
Type modifiers are otherwise case-insensitive, but don't support mixed-case.

C standard doesn't even mention anything about "size_t" or have type modifier
for it. Even though printf() and alike support "%z", it is considered extension
and will be rejected when using strict/pedantic mode.

[Bug tree-optimization/79938] gcc unnecessarily spills xmm register to stack when inserting vector items

[postmaster at raasu dot org via Gcc-bugs]

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.

[Bug tree-optimization/79938] gcc unnecessarily spills xmm register to stack when inserting vector items

[postmaster at raasu dot org via Gcc-bugs]

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 xmm2,XMMWORD PTR [rip+0xd97]# 402060 <_IO_stdin_used+0x60>
 movdqa xmm3,xmm0
 pshufb xmm3,XMMWORD PTR [rip+0xd9a]# 402070 <_IO_stdin_used+0x70>
 paddd  xmm2,xmm1
 psrld  xmm0,0x18
 paddd  xmm0,xmm3
 paddd  xmm0,xmm2

gcc:

 movdqa  %xmm0, %xmm1
 movdqa  %xmm0, %xmm2
 movdqa  %xmm0, %xmm3
 pshufb  .LC0(%rip), %xmm1
 pshufb  .LC1(%rip), %xmm2
 pshufb  .LC2(%rip), %xmm3
 pshufb  .LC3(%rip), %xmm0
 paddd   %xmm3, %xmm0
 paddd   %xmm2, %xmm0
 paddd   %xmm1, %xmm0


This is the function using intrinsics:

static __m128i __attribute__((noinline)) haddd_epu8(__m128i a)
{
   __m128i b1 = _mm_shuffle_epi8(a, _mm_set_epi8(0x80, 0x80, 0x80, 12, 0x80,
0x80, 0x80,  8, 0x80, 0x80, 0x80,  4, 0x80, 0x80, 0x80,  0));
   __m128i b2 = _mm_shuffle_epi8(a, _mm_set_epi8(0x80, 0x80, 0x80, 13, 0x80,
0x80, 0x80,  9, 0x80, 0x80, 0x80,  5, 0x80, 0x80, 0x80,  1));
   __m128i b3 = _mm_shuffle_epi8(a, _mm_set_epi8(0x80, 0x80, 0x80, 14, 0x80,
0x80, 0x80, 10, 0x80, 0x80, 0x80,  6, 0x80, 0x80, 0x80,  2));
   __m128i b4 = _mm_shuffle_epi8(a, _mm_set_epi8(0x80, 0x80, 0x80, 15, 0x80,
0x80, 0x80, 11, 0x80, 0x80, 0x80,  7, 0x80, 0x80, 0x80,  3));
   __m128i c = _mm_add_epi32(b1, _mm_add_epi32(b2, _mm_add_epi32(b3, b4)));
   return c;
}