Undeliverable: Toll increase report

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 a

MDaemon Notification -- Attachment Removed

--- MDaemon has detected restricted attachments within an email message --- >From : bug-...@gnu.org To: anca.ghi...@cargus.ro Subject : adjustment reminder

Delivery report

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 st

[Bug target/71659] _xgetbv intrinsic missing

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

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

: 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

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

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.

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

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

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

--- 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:

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

tion 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

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

-- 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

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

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

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

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

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

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

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

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

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

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

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

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