public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/106389] [11/12/13 Regression] IPA modref breaks Safe Bitfields in C++
Date: Sun, 24 Jul 2022 09:05:46 +0000	[thread overview]
Message-ID: <bug-106389-4-pFyIwvBjDL@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-106389-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I agree with Richi that this is not modref bug. It merely exposes the fact that
we intentionally ignore this rule.

For single compilation unit this rule is already problematic since one can not
determine alias sets incrementally. If struct A and struct B share same initial
segment one needs to delay any TBAA decisions about them until the end of
translation unit when one knows if union of A and B exists and then one needs
to pesimize the optimization.

However standard does not seem to require union to be in the given translation
unit (think of comdat inlines where aliasing of A/B happens in one translation
unit and function is called from other). Moreover with LTO we do not stream
types not needed for a given partition of program and the union may thus be
lost on the way.

So I do not see how to implement this correctly short of
 1) giving up on base alias set disambiguations
 2) delaying all alias set constructions after finalizing all user defined
types, look for all possible initial segments and hack alias oracle to know
about this.  Even this is hard since we currently do disambiguations based on
pairs base_set, ref_set without knowing the offset of ref_set inside base_set
so given two pairs
 base_set1, ref_set1
 base_set2, ref_set2
we would not be able to disambiguate accesses with same ref sets that occurs
after the common initial part of the type.

So indeed I would prefer this to stay undefined and require may_alias attribute
in the user code...

  parent reply	other threads:[~2022-07-24  9:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-21 17:21 [Bug ipa/106389] New: " mpolacek at gcc dot gnu.org
2022-07-21 17:23 ` [Bug ipa/106389] [11/12/13 Regression] " mpolacek at gcc dot gnu.org
2022-07-21 17:26 ` mpolacek at gcc dot gnu.org
2022-07-22  7:09 ` [Bug c++/106389] " rguenth at gcc dot gnu.org
2022-07-22 12:53 ` mpolacek at gcc dot gnu.org
2022-07-24  9:05 ` hubicka at gcc dot gnu.org [this message]
2022-07-25  6:20 ` rguenth at gcc dot gnu.org
2023-05-29 10:07 ` [Bug c++/106389] [11/12/13/14 " jakub at gcc dot gnu.org
2023-07-08  1:45 ` pinskia at gcc dot gnu.org
2023-10-30 20:09 ` 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-106389-4-pFyIwvBjDL@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).