public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/113359] New: [13 Regression] LTO miscompilation of ceph on aarch64 Date: Fri, 12 Jan 2024 18:31:06 +0000 [thread overview] Message-ID: <bug-113359-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 Bug ID: 113359 Summary: [13 Regression] LTO miscompilation of ceph on aarch64 Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- As mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=2241339 when ceph is compiled with LTO on aarch64 _M_emplace_equal<std::pair<std::chrono::time_point<ceph::mono_clock, std::chrono::duration<unsigned long, std::ratio<1l, 1000000000l> > > const, Context*>&> is changed by SRA to only store 64 + 32 bits into the std::pair rather than 64 + 64 bits. Reproducer: ./xg++ -B ./ -O2 -flto=auto -ffat-lto-objects -fexceptions -g -Wall -Wno-complain-wrong-lang -Werror=format-security -fstack-protector-strong -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -std=c++20 -fPIC -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel -Woverloaded-virtual -fstack-protector-strong -fdiagnostics-color=auto -c Timer.ii ./xg++ -B ./ -O2 -flto=auto -ffat-lto-objects -fexceptions -g -Wall -Wno-complain-wrong-lang -Werror=format-security -fstack-protector-strong -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -std=c++20 -fPIC -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel -Woverloaded-virtual -fstack-protector-strong -fdiagnostics-color=auto -c SloppyCRCMap.ii ./xg++ -B ./ -O2 -c CrtStuff.i ./xg++ -B ./ -flto=auto -shared -o out.so SloppyCRCMap.o Timer.o CrtStuff.o -nostdlib grep_cleanup() { c++filt | grep -A16 '_M_emplace_equal<std::pair<std::chrono.*>:' | sed 's/[^:]*: *//' } diff -u <(aarch64-linux-gnu-objdump -d Timer.o | grep_cleanup) <(aarch64-linux-gnu-objdump -d out.so | grep_cleanup) which prints --- /dev/fd/63 2024-01-12 19:24:37.317433462 +0100 +++ /dev/fd/62 2024-01-12 19:24:37.318433448 +0100 @@ -7,11 +7,11 @@ d2800600 mov x0, #0x30 // #48 f90013f5 str x21, [sp, #32] aa0103f5 mov x21, x1 - 94000000 bl 0 <operator new(unsigned long)> + 97fff0bc bl 6ee0 <operator new(unsigned long)@plt> aa0003f4 mov x20, x0 f9400a62 ldr x2, [x19, #16] 91002263 add x3, x19, #0x8 f94002a7 ldr x7, [x21] f9001007 str x7, [x0, #32] - f94006a0 ldr x0, [x21, #8] - f9001680 str x0, [x20, #40] + b9400aa1 ldr w1, [x21, #8] + b9002801 str w1, [x0, #40] i.e. the -ffat-lto-objects non-LTO compilation stores 64-bit pointers at the new returned pointer + 32 and + 40, while LTO stores 64-bit pointer only to the former and 32-bit into the latter. In *.cplxlower1 I still see MEM[(struct pair *)_37 + 32B] = ISRA.253; where struct pair ISRA.253; but sra has: Created a replacement for ISRA.253 offset: 0, size: 64: SR.256D.22298 Created a replacement for ISRA.253 offset: 64, size: 32: SR.257D.22299 From what I can see, that should be std::multimap<clock_t::time_point, Context*>::value_type, i.e. std::pair<const clock_t::time_point, Context*>
next reply other threads:[~2024-01-12 18:31 UTC|newest] Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-01-12 18:31 jakub at gcc dot gnu.org [this message] 2024-01-12 18:31 ` [Bug tree-optimization/113359] " jakub at gcc dot gnu.org 2024-01-12 18:32 ` jakub at gcc dot gnu.org 2024-01-12 18:32 ` jakub at gcc dot gnu.org 2024-01-12 18:33 ` jakub at gcc dot gnu.org 2024-01-12 18:34 ` [Bug ipa/113359] " jakub at gcc dot gnu.org 2024-01-12 19:54 ` jakub at gcc dot gnu.org 2024-01-12 19:56 ` jakub at gcc dot gnu.org 2024-01-12 20:29 ` pinskia at gcc dot gnu.org 2024-01-15 8:24 ` rguenth at gcc dot gnu.org 2024-02-05 21:48 ` jamborm at gcc dot gnu.org 2024-02-06 8:29 ` rguenth at gcc dot gnu.org 2024-02-06 10:00 ` hubicka at gcc dot gnu.org 2024-02-06 12:39 ` jakub at gcc dot gnu.org 2024-02-06 12:47 ` rguenther at suse dot de 2024-02-07 17:01 ` jamborm at gcc dot gnu.org 2024-02-19 15:31 ` jamborm at gcc dot gnu.org 2024-03-09 21:44 ` pinskia at gcc dot gnu.org 2024-03-09 21:45 ` sjames at gcc dot gnu.org 2024-03-09 21:45 ` [Bug ipa/113359] [13/14 " pinskia at gcc dot gnu.org 2024-03-15 15:02 ` law at gcc dot gnu.org 2024-03-15 15:13 ` avieira at gcc dot gnu.org 2024-03-15 15:25 ` law at gcc dot gnu.org 2024-03-26 10:42 ` [Bug ipa/113359] [13/14 Regression] LTO miscompilation of ceph on aarch64 and x86_64 rguenth at gcc dot gnu.org 2024-03-28 8:59 ` jamborm at gcc dot gnu.org 2024-04-04 11:40 ` hubicka at gcc dot gnu.org 2024-04-04 21:22 ` jamborm at gcc dot gnu.org 2024-04-08 16:57 ` cvs-commit at gcc dot gnu.org 2024-04-08 16:59 ` jamborm at gcc dot gnu.org 2024-04-08 17:01 ` [Bug ipa/113359] [13 " jakub at gcc dot gnu.org 2024-04-09 6:33 ` rguenth at gcc dot gnu.org 2024-05-14 11:22 ` cvs-commit at gcc dot gnu.org 2024-05-14 11:58 ` jamborm at gcc dot gnu.org 2024-05-14 12:00 ` jamborm at gcc dot gnu.org 2024-05-17 14:29 ` dkm at gcc dot gnu.org 2024-05-20 15:10 ` jamborm at gcc dot gnu.org 2024-05-20 15:13 ` dkm at gcc dot gnu.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-113359-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).