public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jl_gccbugs at conductive dot de" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/100801] New: Aggressive loop optimizations cause incorrect warning Date: Thu, 27 May 2021 14:03:54 +0000 [thread overview] Message-ID: <bug-100801-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100801 Bug ID: 100801 Summary: Aggressive loop optimizations cause incorrect warning Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: jl_gccbugs at conductive dot de CC: marxin at gcc dot gnu.org Target Milestone: --- The following warning is triggered > $ gcc-11 -c constproploopopt.c -O2 -Wall -mavx -g > constproploopopt.c: In function ‘test’: > constproploopopt.c:22:18: warning: iteration 4611686018427387903 invokes undefined behavior [-Waggressive-loop-optimizations] > 22 | dest[i] = src[i]; > | ^ > constproploopopt.c:21:12: note: within this loop > 21 | for (; i < count; ++i) { // handle residual elements > | ~~^~~~~~~ by this (minimal) code: > #include <stdint.h> > #include <stdio.h> > #if defined(_MSC_VER) > #include <intrin.h> > #else > #include <x86intrin.h> > #endif > > void copy_32_unaligned(uint32_t* dest, const uint32_t* src, size_t count) { > // invariant/nop > __m128i shufmask = _mm_set_epi8(15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0); > > size_t i; > for (i = 0; i + 4 <= count; i += 4) { > __m128i input = _mm_loadu_si128((const __m128i*)(&src[i])); > __m128i output = input; > // no warning without the shuffle: > output = _mm_shuffle_epi8(input, shufmask); > _mm_storeu_si128((__m128i*)(&dest[i]), output); > } > for (; i < count; ++i) { // handle residual elements > dest[i] = src[i]; > } > } > > void test(uint32_t* buf1, uint32_t* buf2) { > copy_32_unaligned(buf2, buf1, > // multiples of 4 and greater or equal then 12 trigger it: > 12); > } >From objdump output I believe the generated code is correct though. The warning seems to be incorrect in this context, especially since the "residual" loop should be skipped for count=n*4 anyways.
next reply other threads:[~2021-05-27 14:03 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-27 14:03 jl_gccbugs at conductive dot de [this message] 2021-05-28 10:54 ` [Bug tree-optimization/100801] " rguenth at gcc dot gnu.org 2021-05-28 12:45 ` jl_gccbugs at conductive dot de 2021-07-31 0:41 ` matthijsvanduin at gmail dot com 2021-12-20 0:55 ` [Bug tree-optimization/100801] [9/10/11/12 Regression] " pinskia at gcc dot gnu.org 2022-01-05 14:29 ` rguenth at gcc dot gnu.org 2022-05-27 9:45 ` [Bug tree-optimization/100801] [10/11/12/13 " rguenth at gcc dot gnu.org 2022-06-28 10:45 ` jakub at gcc dot gnu.org 2023-07-07 10:40 ` [Bug tree-optimization/100801] [11/12/13/14 " rguenth at gcc dot gnu.org 2024-03-11 3:42 ` [Bug tree-optimization/100801] [11/12 " law 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-100801-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).