public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/107206] Bogus -Wuninitialized in std::optional
Date: Tue, 11 Oct 2022 10:20:17 +0000	[thread overview]
Message-ID: <bug-107206-4-GqMLmcvuBa@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-107206-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107206

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jamborm at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
So this goes wrong in SRA somewhere where we decide to scalarize yD.11526
with its std::optional member which isn't engaged.  Before early SRA we have

  MEM[(struct YD.10174 *)&yD.11526] ={v} {CLOBBER};
  MEM[(struct YD.10174 *)&yD.11526].xD.10179.iD.10156 = 0;
  MEM[(struct optionalD.10180 *)&yD.11526 + 4B] ={v} {CLOBBER};
  MEM[(union _StorageD.10576 *)&yD.11526 + 4B] ={v} {CLOBBER};
  MEM[(struct _Optional_payload_baseD.10507 *)&yD.11526 + 4B]._M_engagedD.10644
= 0;
  D.11546 ={v} {CLOBBER};
  MEM[(struct XD.10147 *)&D.11546] ={v} {CLOBBER};
  _22 = MEM[(const struct XD.10147 &)&yD.11526].iD.10156;
  MEM[(struct XD.10147 *)&D.11546].iD.10156 = _22;
  D.11546.oD.11384 = yD.11526.oD.11384;
  MEM[(struct YD.10174 *)&zD.11527] ={v} {CLOBBER};
  MEM[(struct XD.10147 *)&zD.11527] ={v} {CLOBBER};
  _21 = MEM[(const struct XD.10147 &)&D.11546].iD.10156;
  MEM[(struct XD.10147 *)&zD.11527].iD.10156 = _21;
  MEM[(struct YD.10174 *)&zD.11527].oD.11384 = MEM[(const struct YD.10174
&)&D.11546].oD.11384;
  D.11546 ={v} {CLOBBER(eol)};
  MEM[(struct _Optional_baseD.10197 *)&D.11678] ={v} {CLOBBER};
  MEM[(struct __as_base D.10805 &)&D.11678] ={v} {CLOBBER};
  MEM[(union _StorageD.10576 *)&D.11678] ={v} {CLOBBER};
  MEM[(union _StorageD.10576 *)&D.11678]._M_valueD.10616 = 1;
  MEM[(struct _Optional_payload_baseD.10507 *)&D.11678]._M_engagedD.10644 = 1;
  zD.11527.yD.11476.oD.11384 = D.11678;
  D.11678 ={v} {CLOBBER(eol)};
  MEM[(struct YD.10174 *)&wD.11680] ={v} {CLOBBER};
  MEM[(struct XD.10147 *)&wD.11680] ={v} {CLOBBER};
  _19 = MEM[(const struct XD.10147 &)&zD.11527].iD.10156;
  MEM[(struct XD.10147 *)&wD.11680].iD.10156 = _19;
  MEM[(struct YD.10174 *)&wD.11680].oD.11384 = MEM[(const struct YD.10174
&)&zD.11527].oD.11384;
  fD.11523 (&wD.11680.yD.11476);

and SRA possibly follows the copy chains eventually seeing the
value accesses to D.11678 and deciding based on that the type to use
to access the value union of std::optional which is (simplified)

      struct _Empty_byte { };
      union _Storage {
          _Empty_byte _M_empty;
          _Up _M_value;
      }

with _Up being int in this testcase.  Note that _M_empty is properly
initialized but as the store is to an empty type this store is elided
by gimplification.

Note that SRA doesn't dump anything on yD.11526 but still generates

  D.11546.oD.11384 = yD.11526.oD.11384;
  SR.19_9 = MEM <intD.9> [(struct optionalD.10180 *)&yD.11526 + 4B];
  SR.20_6 = MEM <unsigned char> [(struct optionalD.10180 *)&yD.11526 + 8B];

possibly from the scalarization of D.11546:

Created a replacement for D.11546 offset: 0, size: 32: SR.18D.11910
Created a replacement for D.11546 offset: 32, size: 32: SR.19D.11911
Changing the type of a replacement for D.11546 offset: 64, size: 8  to an
integer.
Created a replacement for D.11546 offset: 64, size: 8: SR.20D.11912
...
access { base = (11546)'D.11546', offset = 32, size = 64, expr = D.11546.o,
type = struct optional, reverse = 0, grp_read = 1, grp_write = 1,
grp_assignment_read = 1, grp_assignment_write = 1, grp_scalar_read = 0,
grp_scalar_write = 0, grp_total_scalarization = 0, grp_hint = 0, grp_covered =
0, grp_unscalarizable_region = 0, grp_unscalarized_data = 1,
grp_same_access_path = 1, grp_partial_lhs = 0, grp_to_be_replaced = 0,
grp_to_be_debug_replaced = 0}

here D.11546.o is of an aggregate type containing a union member.  Somehow
there's

* access { base = (11546)'D.11546', offset = 32, size = 32, expr =
D.11546.o.D.11379._M_payload.D.10892._M_payload._M_value, type = int, reverse =
0, grp_read = 1, grp_write = 1, grp_assignment_read = 1, grp_assignment_write =
1, grp_scalar_read = 0, grp_scalar_write = 0, grp_total_scalarization = 0,
grp_hint = 0, grp_covered = 1, grp_unscalarizable_region = 0,
grp_unscalarized_data = 0, grp_same_access_path = 0, grp_partial_lhs = 0,
grp_to_be_replaced = 1, grp_to_be_debug_replaced = 0}

but I don't see any such access in the IL before SRA?!

  parent reply	other threads:[~2022-10-11 10:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-10 23:14 [Bug c++/107206] New: " ed at catmur dot uk
2022-10-11  8:16 ` [Bug libstdc++/107206] " rguenth at gcc dot gnu.org
2022-10-11 10:10 ` redi at gcc dot gnu.org
2022-10-11 10:20 ` rguenth at gcc dot gnu.org [this message]
2022-10-11 10:22 ` [Bug tree-optimization/107206] " rguenth at gcc dot gnu.org
2022-10-14 16:53 ` jamborm at gcc dot gnu.org
2022-10-16 17:27 ` rguenther at suse dot de
2022-10-19 12:59 ` cvs-commit at gcc dot gnu.org
2022-11-16 12:13 ` cvs-commit at gcc dot gnu.org
2022-11-16 12:14 ` jamborm at gcc dot gnu.org
2022-11-28 22:22 ` pinskia 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-107206-4-GqMLmcvuBa@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: link
Be 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).