public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Jason Merrill <jason@redhat.com>
Cc: Bernd Edlinger <bernd.edlinger@hotmail.de>,
	    Jakub Jelinek <jakub@redhat.com>,
	Jonathan Wakely <jwakely@redhat.com>,
	    Florian Weimer <fweimer@redhat.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	    Jeff Law <law@redhat.com>, Jan Hubicka <jh@suse.de>
Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671)
Date: Tue, 11 Apr 2017 11:53:00 -0000	[thread overview]
Message-ID: <alpine.LSU.2.20.1704111337490.30715@zhemvz.fhfr.qr> (raw)
In-Reply-To: <alpine.LSU.2.20.1704111226090.30715@zhemvz.fhfr.qr>

[-- Attachment #1: Type: text/plain, Size: 5857 bytes --]

On Tue, 11 Apr 2017, Richard Biener wrote:

> On Mon, 10 Apr 2017, Jason Merrill wrote:
> 
> > On Mon, Apr 10, 2017 at 11:30 AM, Richard Biener <rguenther@suse.de> wrote:
> > > On Mon, 10 Apr 2017, Jason Merrill wrote:
> > >> On Mon, Apr 10, 2017 at 8:50 AM, Richard Biener <rguenther@suse.de> wrote:
> > >> >         * tree.c (build_cplus_array_type): Set TYPE_TYPELESS_STORAGE
> > >> >         for arrays of unsigned char or std::byte.
> > >>
> > >> I think it would be good to have a flag to select whether these
> > >> semantics apply to any char variant and std::byte, only unsigned char
> > >> and std::byte, or only std::byte.
> > >
> > > Any suggestion?  Not sure we really need it (I'm hesitant to write
> > > all the testcases to verify it actually works).
> > 
> > Well, there's existing code that uses plain char (e.g. boost) that I
> > want to support.  If there's a significant optimization penalty for
> > allowing that, we probably also want to be able to limit the impact.
> > If there isn't much penalty, let's just support all char variants.
> 
> I haven't assessed the penalty involved but it can't be worse than
> the situation we had in GCC 6.  So I think it's reasonable to support
> all char variants for now.  One could add some instrumenting to
> alias_set_subset_of / alias_sets_conflict_p but it would only yield
> an upper bound on the number of failed queries (TBAA is a quite early
> out before PTA info is used for example).
> 
> The following variant -- added missing
> 
> Index: gcc/cp/tree.c
> ===================================================================
> --- gcc/cp/tree.c       (revision 246832)
> +++ gcc/cp/tree.c       (working copy)
> @@ -972,6 +979,7 @@ build_cplus_array_type (tree elt_type, t
>                  as it will overwrite alignment etc. of all variants.  */
>               TYPE_SIZE (t) = TYPE_SIZE (m);
>               TYPE_SIZE_UNIT (t) = TYPE_SIZE_UNIT (m);
> +             TYPE_TYPELESS_STORAGE (t) = TYPE_TYPELESS_STORAGE (m);
>             }
>  
>           TYPE_MAIN_VARIANT (t) = m;
> 
> that caused LTO bootstrap to fail and removed the tree-ssa-structalias.c
> change (committed separately) [LTO] bootstrapped and tested ok on 
> x86_64-unknown-linux-gnu.
> 
> I've tested some template examples and they seem to work fine.
> 
> Ok for trunk?
> 
> Disclaimer: there might still be an issue with cross-language LTO
> support, but it might at most result in TYPE_TYPELESS_STORAGE
> getting lost.  Trying to craft a testcase to verify my theory.

Not too difficult in the end (see below).  A fix (below) is to
not treat arrays with differing TYPE_TYPELESS_STORAGE as
compatible for the purpose of computing TYPE_CANONICAL (and
thus recursively structures containing them).  While they'd
still alias each other (because currently a TYPE_TYPELESS_STORAGE
member makes the whole thing effectively alias anything) this
results in warnings in case such a type is used in the interface
between C and C++ (it's also considered a ODR type).

t.C:17:17: warning: type of Β‘barΒ’ does not match original declaration 
[-Wlto-type-mismatch]
 extern "C" void bar (X *);
                 ^
t2.c:5:6: note: Β‘barΒ’ was previously declared here
 void bar (struct X *p) {}
      ^

if you add a struct X * parameter to bar().

So it's not the optimal solution here.  Another fix would be to
somehow make TYPE_TYPELESS_STORAGE "sticky" when merging canonical
types but there's not precedent in doing this kind of thing and
I'm not sure we'll get everything merged before computing alias
sets.

CCing Honza.

Richard.

2017-04-11  Richard Biener  <rguenther@suse.de>

	PR middle-end/79671
	* tree.c (gimple_canonical_types_compatible_p): Do not treat
	arrays with differing TYPE_TYPELESS_STORAGE as compatible.

	* g++.dg/lto/pr79671_0.C: New testcase.
	* g++.dg/lto/pr79671_1.c: Likewise.

Index: gcc/tree.c
===================================================================
*** gcc/tree.c	(revision 246835)
--- gcc/tree.c	(working copy)
*************** gimple_canonical_types_compatible_p (con
*** 13709,13715 ****
  						trust_type_canonical)
  	  || TYPE_STRING_FLAG (t1) != TYPE_STRING_FLAG (t2)
  	  || TYPE_REVERSE_STORAGE_ORDER (t1) != TYPE_REVERSE_STORAGE_ORDER (t2)
! 	  || TYPE_NONALIASED_COMPONENT (t1) != TYPE_NONALIASED_COMPONENT (t2))
  	return false;
        else
  	{
--- 13709,13716 ----
  						trust_type_canonical)
  	  || TYPE_STRING_FLAG (t1) != TYPE_STRING_FLAG (t2)
  	  || TYPE_REVERSE_STORAGE_ORDER (t1) != TYPE_REVERSE_STORAGE_ORDER (t2)
! 	  || TYPE_NONALIASED_COMPONENT (t1) != TYPE_NONALIASED_COMPONENT (t2)
! 	  || TYPE_TYPELESS_STORAGE (t1) != TYPE_TYPELESS_STORAGE (t2))
  	return false;
        else
  	{
Index: gcc/testsuite/g++.dg/lto/pr79671_0.C
===================================================================
*** gcc/testsuite/g++.dg/lto/pr79671_0.C	(nonexistent)
--- gcc/testsuite/g++.dg/lto/pr79671_0.C	(working copy)
***************
*** 0 ****
--- 1,26 ----
+ // { dg-lto-do run }
+ 
+ void *operator new(__SIZE_TYPE__, void *p2) { return p2; }
+ struct B { B(int i_) : i(i_) {} int i; };
+ struct X
+ {
+   unsigned char buf[sizeof (B)];
+ };
+ 
+ int __attribute__((noinline)) foo()
+ {
+   X x alignas (B), y alignas (B);
+   new (&x) B (0);
+   y = x;
+   B *q = reinterpret_cast <B *>(&y);
+   asm volatile ("" : "=r" (q) : "r" (q));
+   return q->i;
+ }
+ extern "C" void bar ();
+ int main()
+ {
+   if (foo() != 0)
+     __builtin_abort ();
+   bar ();
+   return 0;
+ }
Index: gcc/testsuite/g++.dg/lto/pr79671_1.c
===================================================================
*** gcc/testsuite/g++.dg/lto/pr79671_1.c	(nonexistent)
--- gcc/testsuite/g++.dg/lto/pr79671_1.c	(working copy)
***************
*** 0 ****
--- 1,5 ----
+ struct X
+ {
+   unsigned char buf[sizeof (int)];
+ };
+ void bar () { struct X x; *(volatile char *)x.buf = 1; }

  reply	other threads:[~2017-04-11 11:53 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-05  9:46 Bernd Edlinger
2017-04-05 13:28 ` Jakub Jelinek
2017-04-05 15:20   ` Richard Biener
2017-04-05 17:41     ` Bernd Edlinger
2017-04-05 20:18       ` Jason Merrill
2017-04-05 20:46         ` Bernd Edlinger
2017-04-05 22:54           ` Pedro Alves
2017-04-06 10:08           ` Jonathan Wakely
2017-04-06  7:23         ` Richard Biener
2017-04-05 15:27   ` Bernd Edlinger
2017-04-05 15:29     ` Jakub Jelinek
2017-04-05 14:50 ` Florian Weimer
2017-04-05 15:23   ` Richard Biener
2017-04-05 15:38     ` Bernd Edlinger
2017-04-05 16:03       ` Jonathan Wakely
2017-04-05 16:08         ` Jakub Jelinek
2017-04-05 17:23           ` Bernd Edlinger
2017-04-05 21:02             ` Bernd Edlinger
2017-04-05 23:17               ` Sandra Loosemore
2017-04-06  5:40                 ` Jakub Jelinek
2017-04-06  7:47               ` Richard Biener
2017-04-06  7:51                 ` Jakub Jelinek
2017-04-06  7:55                   ` Richard Biener
2017-04-06 14:11                     ` Bernd Edlinger
2017-04-06 14:17                       ` Florian Weimer
2017-04-06 14:23                         ` Richard Biener
2017-04-06 14:43                           ` Jonathan Wakely
2017-04-06 14:51                             ` Florian Weimer
2017-04-06 15:05                               ` Jakub Jelinek
2017-04-06 15:10                                 ` Florian Weimer
2017-04-06 19:13                               ` Richard Biener
2017-04-11 10:43                                 ` Florian Weimer
2017-04-11 10:48                                   ` Richard Biener
2017-04-06 17:39                         ` Bernd Edlinger
2017-04-06 17:48                           ` Florian Weimer
2017-04-06 18:12                             ` Bernd Edlinger
2017-04-06 18:19                               ` Florian Weimer
2017-04-06 18:49                                 ` Bernd Edlinger
2017-04-06 19:05                                   ` Florian Weimer
2017-04-06 19:20                                     ` Bernd Edlinger
2017-04-07  6:47                                       ` Richard Biener
2017-04-07 12:58                                         ` Bernd Edlinger
2017-04-06 19:16                               ` Richard Biener
2017-04-07  6:56                                 ` Florian Weimer
2017-04-07  8:01                                   ` Richard Biener
2017-04-06 19:14                           ` Richard Biener
2017-04-06 19:51                             ` Bernd Edlinger
2017-04-06 14:22                       ` Richard Biener
2017-04-06 21:00                 ` Bernd Edlinger
2017-04-07  6:54                   ` Richard Biener
2017-04-07 13:37                     ` Bernd Edlinger
2017-04-07 15:10                       ` Richard Biener
2017-04-07 15:33                         ` Bernd Edlinger
2017-04-07 20:22                           ` Jason Merrill
2017-04-10 12:50                             ` Richard Biener
2017-04-10 14:41                               ` Jason Merrill
2017-04-10 15:31                                 ` Richard Biener
2017-04-10 16:35                                   ` Jason Merrill
2017-04-11 10:32                                     ` Richard Biener
2017-04-11 11:53                                       ` Richard Biener [this message]
2017-04-11 13:35                                         ` Richard Biener
2017-04-11 18:47                                           ` Jason Merrill
2017-04-10 21:40                               ` Pedro Alves
2017-04-11  7:37                                 ` Richard Biener
2017-04-06 20:20               ` Bernd Edlinger

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=alpine.LSU.2.20.1704111337490.30715@zhemvz.fhfr.qr \
    --to=rguenther@suse.de \
    --cc=bernd.edlinger@hotmail.de \
    --cc=fweimer@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=jason@redhat.com \
    --cc=jh@suse.de \
    --cc=jwakely@redhat.com \
    --cc=law@redhat.com \
    /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).