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...
next prev 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: 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).