public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug middle-end/106008] New: [12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] @ 2022-06-16 19:16 hjl.tools at gmail dot com 2022-06-16 22:27 ` [Bug middle-end/106008] " hjl.tools at gmail dot com ` (5 more replies) 0 siblings, 6 replies; 7+ messages in thread From: hjl.tools at gmail dot com @ 2022-06-16 19:16 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106008 Bug ID: 106008 Summary: [12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- Created attachment 53156 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53156&action=edit A testcase When building glibc master branch with -mavx512f, I got [hjl@gnu-tgl-2 tmp]$ gcc -O2 -march=x86-64 -S -Wall x.i -mavx512f dl-load.c: In function ‘_dl_map_object_from_fd.constprop’: dl-load.c:1158:30: warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] [hjl@gnu-tgl-2 tmp]$ The code looks like struct loadcmd *c = &loadcmds[nloadcmds++]; c->mapstart = ALIGN_DOWN (ph->p_vaddr, GLRO(dl_pagesize)); c->mapend = ALIGN_UP (ph->p_vaddr + ph->p_filesz, GLRO(dl_pagesize)); c->dataend = ph->p_vaddr + ph->p_filesz; c->allocend = ph->p_vaddr + ph->p_memsz; /* Remember the maximum p_align. */ if (powerof2 (ph->p_align) && ph->p_align > p_align_max) p_align_max = ph->p_align; c->mapoff = ALIGN_DOWN (ph->p_offset, GLRO(dl_pagesize)); /* Determine whether there is a gap between the last segment and this one. */ if (nloadcmds > 1 && c[-1].mapend != c->mapstart) has_holes = true; c[-1].mapend should always be initialized. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/106008] [12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] 2022-06-16 19:16 [Bug middle-end/106008] New: [12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] hjl.tools at gmail dot com @ 2022-06-16 22:27 ` hjl.tools at gmail dot com 2022-06-17 2:55 ` [Bug middle-end/106008] [11/12 " hjl.tools at gmail dot com ` (4 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: hjl.tools at gmail dot com @ 2022-06-16 22:27 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106008 H.J. Lu <hjl.tools at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed| |2022-06-16 --- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> --- Simply change the cost of integer store makes the warnings to go away: diff --git a/gcc/config/i386/x86-tune-costs.h b/gcc/config/i386/x86-tune-costs.h index 6c9066c84cc..b83bb79c065 100644 --- a/gcc/config/i386/x86-tune-costs.h +++ b/gcc/config/i386/x86-tune-costs.h @@ -3276,7 +3276,11 @@ struct processor_costs generic_cost = { {6, 6, 6}, /* cost of loading integer registers in QImode, HImode and SImode. Relative to reg-reg move (2). */ +#if 0 {6, 6, 6}, /* cost of storing integer registers */ +#else + {8, 8, 8}, /* cost of storing integer registers */ +#endif {6, 6, 6, 10, 15}, /* cost of loading SSE register in 32bit, 64bit, 128bit, 256bit and 512bit */ {6, 6, 6, 10, 15}, /* cost of storing SSE register ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/106008] [11/12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] 2022-06-16 19:16 [Bug middle-end/106008] New: [12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] hjl.tools at gmail dot com 2022-06-16 22:27 ` [Bug middle-end/106008] " hjl.tools at gmail dot com @ 2022-06-17 2:55 ` hjl.tools at gmail dot com 2022-06-20 10:01 ` [Bug middle-end/106008] [11/12/13 " rguenth at gcc dot gnu.org ` (3 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: hjl.tools at gmail dot com @ 2022-06-17 2:55 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106008 H.J. Lu <hjl.tools at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|12.0 |11.2.1 Summary|[12 Regression] warning: |[11/12 Regression] warning: |‘(((char *)loadcmds.113_68 |‘(((char *)loadcmds.113_68 |+ _933 + |+ _933 + |16))[329406144173384849].ma |16))[329406144173384849].ma |pend’ may be used |pend’ may be used |uninitialized |uninitialized |[-Wmaybe-uninitialized] |[-Wmaybe-uninitialized] --- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> --- GCC 11 has the same issue. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/106008] [11/12/13 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] 2022-06-16 19:16 [Bug middle-end/106008] New: [12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] hjl.tools at gmail dot com 2022-06-16 22:27 ` [Bug middle-end/106008] " hjl.tools at gmail dot com 2022-06-17 2:55 ` [Bug middle-end/106008] [11/12 " hjl.tools at gmail dot com @ 2022-06-20 10:01 ` rguenth at gcc dot gnu.org 2022-06-20 10:01 ` rguenth at gcc dot gnu.org ` (2 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: rguenth at gcc dot gnu.org @ 2022-06-20 10:01 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106008 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |needs-reduction Blocks| |24639 --- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- # VUSE <.MEM_699> _109 = MEM[(struct loadcmd *)_106 + -56B].mapend; my only suspicion is that we somehow isolate (and not optimize as unreachable) the nloadcmds < 1 case in the preceeding case. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/106008] [11/12/13 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] 2022-06-16 19:16 [Bug middle-end/106008] New: [12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] hjl.tools at gmail dot com ` (2 preceding siblings ...) 2022-06-20 10:01 ` [Bug middle-end/106008] [11/12/13 " rguenth at gcc dot gnu.org @ 2022-06-20 10:01 ` rguenth at gcc dot gnu.org 2023-03-29 13:35 ` rguenth at gcc dot gnu.org 2023-05-29 10:07 ` [Bug middle-end/106008] [11/12/13/14 " jakub at gcc dot gnu.org 5 siblings, 0 replies; 7+ messages in thread From: rguenth at gcc dot gnu.org @ 2022-06-20 10:01 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106008 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |diagnostic Target Milestone|--- |11.4 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/106008] [11/12/13 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] 2022-06-16 19:16 [Bug middle-end/106008] New: [12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] hjl.tools at gmail dot com ` (3 preceding siblings ...) 2022-06-20 10:01 ` rguenth at gcc dot gnu.org @ 2023-03-29 13:35 ` rguenth at gcc dot gnu.org 2023-05-29 10:07 ` [Bug middle-end/106008] [11/12/13/14 " jakub at gcc dot gnu.org 5 siblings, 0 replies; 7+ messages in thread From: rguenth at gcc dot gnu.org @ 2023-03-29 13:35 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106008 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P2 Keywords|missed-optimization, | |needs-reduction | Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Richard Biener from comment #3) > # VUSE <.MEM_699> > _109 = MEM[(struct loadcmd *)_106 + -56B].mapend; > > my only suspicion is that we somehow isolate (and not optimize as > unreachable) > the nloadcmds < 1 case in the preceeding case. Nope the statement we are diagnosing is guarded by nloadcmds > 1. A reduced testcase looks like the following, needs -Os -fno-ivopts to reproduce the diagnostics. It is somewhat of a fundamental limit of the analysis since when walking the virtual use-def chain we look for aliases but q[-1] doesn't alias q[0] but when walking the backedge we simply arrive at the very same stmt again and interpret it as if it were within the same context. That might also be a problem for passes using walk_aliased_vdefs for other purposes than diagnostics. I think that when walking a backedge walk_aliased_vdefs would need to be more careful with interpreting the defs it runs into. int foo (int n) { int *p = __builtin_malloc (n); int nloadcmds = 0; int found = 0; do { int *q = &p[nloadcmds++]; *q = n; if (nloadcmds > 1 && q[-1] != 7) found = 1; } while (nloadcmds < n); return found; } ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/106008] [11/12/13/14 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] 2022-06-16 19:16 [Bug middle-end/106008] New: [12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] hjl.tools at gmail dot com ` (4 preceding siblings ...) 2023-03-29 13:35 ` rguenth at gcc dot gnu.org @ 2023-05-29 10:07 ` jakub at gcc dot gnu.org 5 siblings, 0 replies; 7+ messages in thread From: jakub at gcc dot gnu.org @ 2023-05-29 10:07 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106008 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|11.4 |11.5 --- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- GCC 11.4 is being released, retargeting bugs to GCC 11.5. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-05-29 10:07 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-06-16 19:16 [Bug middle-end/106008] New: [12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] hjl.tools at gmail dot com 2022-06-16 22:27 ` [Bug middle-end/106008] " hjl.tools at gmail dot com 2022-06-17 2:55 ` [Bug middle-end/106008] [11/12 " hjl.tools at gmail dot com 2022-06-20 10:01 ` [Bug middle-end/106008] [11/12/13 " rguenth at gcc dot gnu.org 2022-06-20 10:01 ` rguenth at gcc dot gnu.org 2023-03-29 13:35 ` rguenth at gcc dot gnu.org 2023-05-29 10:07 ` [Bug middle-end/106008] [11/12/13/14 " jakub at gcc dot gnu.org
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).