public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "postmaster at raasu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/108580] New: gcc treats shifts as signed operation, does wrong promotion Date: Sat, 28 Jan 2023 07:42:06 +0000 [thread overview] Message-ID: <bug-108580-4@http.gcc.gnu.org/bugzilla/> (raw) 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 call malloc@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 call malloc@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 call memcpy@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
next reply other threads:[~2023-01-28 7:42 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-28 7:42 postmaster at raasu dot org [this message] 2023-01-28 7:53 ` [Bug c/108580] " pinskia at gcc dot gnu.org 2023-01-28 8:04 ` postmaster at raasu dot org 2023-01-28 8:09 ` pinskia at gcc dot gnu.org 2023-01-28 8:55 ` postmaster at raasu dot org 2023-01-28 9:21 ` pinskia at gcc dot gnu.org 2023-01-28 12:21 ` postmaster at raasu dot org 2023-01-28 13:22 ` pinskia at gcc dot gnu.org 2023-01-28 15:36 ` postmaster at raasu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-108580-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).