public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Uecker, Martin" <Martin.Uecker@med.uni-goettingen.de>
To: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Cc: "richard.guenther@gmail.com" <richard.guenther@gmail.com>,
	"joseph@codesourcery.com" <joseph@codesourcery.com>
Subject: compatibility of structs/unions/enums in the middle end
Date: Tue, 01 Oct 2019 17:49:00 -0000	[thread overview]
Message-ID: <1569952166.3711.7.camel@med.uni-goettingen.de> (raw)



Hi,

I have a proposal for making changes to the rules for
compatibility of tagged types in C2X  (N2366). This was
received with interest by WG14, so there is a chance
that this could get accepted into C2X.

In particular, the idea is to make structs (+ unions, enums)
with the same tag and the same members compatible. The
current C standards says that such structs are compatible
between different TUs but not inside the same TU, which
is very strange and - as pointed out by Joseph
in DR314 - this leads to "interesting" scenarios
where types across different TU cannot be partitioned
into equivalence classes in a consistent way.

The new rules would fix these inconsistencies and also
make some useful programming patterns possible: E.g. one
could declare structs/union/enums types in a macro so
that another invocation produces a compatible type.
For example:

#define MAYBE(T) struct foo_##T { _Bool flag; T value }; 

MAYBE(int) x = { true, 0 };
MAYBE(int) y = x;


I am working on a patch for GCC which adds this as an
optional feature. So far, I have a working patch to the
C front end which changes the concept of type compatibility
to match the proposed model. It uses the existing code
for type compatibility, so is relatively simple.

The question is now how this should interact with the
middle end. So far, I have to insert some VIEW_CONVERT_EXPR
to avoid "useless type conversion" errors during gimple
verification. 

I am also wonder how to make TBAA do the right thing
for the new rules. Currently, GCC assumes 's1p' and 's2p'
cannot alias in the following example and outputs '2'
in 'f', but this would not be true anymore according
to the proposal. 


#include <stdio.h>

typedef struct { int i; } st1;
typedef struct { int i; } st2;

void f(void* s1v, void* s2v)
{
  st1 *s1p = s1v;
  st2 *s2p = s2v;
  s1p->i = 2;
  s2p->i = 3;
  printf("f: s1p->i = %i\n", s1p->i);
}

int main()
{
  st1 s = { .i = 1 };
  f(&s, &s);
  printf("s.i = %i\n", s.i);
}

BTW: According to current rules when 'f' is
moved into a different TU, there is no UB.
As both 'st1'
and 'st2' in one TU are compatible
to both 'st1' and 'st2' in the other TU there
is no UB. Still, GCC
incorrectly assumes that
's1p' and 's1p' do not alias.


I would appreciate any information about how to
approach this.

Best,
Martin


             reply	other threads:[~2019-10-01 17:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-01 17:49 Uecker, Martin [this message]
2019-10-02 10:46 ` Richard Biener
2019-10-02 10:47   ` Richard Biener
2019-10-02 11:57     ` Uecker, Martin
2019-10-02 12:18       ` Richard Biener
2019-10-02 12:35         ` Uecker, Martin
2019-10-02 13:10           ` Richard Biener
2019-10-02 13:13             ` Richard Biener
2019-10-02 13:55               ` Uecker, Martin
2019-10-02 15:37                 ` Richard Biener
2019-10-02 18:24                   ` Uecker, Martin
2019-10-04 10:30                     ` Richard Biener
2019-10-04 11:55                       ` Uecker, Martin
2019-10-04 12:28                         ` Richard Biener
2019-10-04 12:40                           ` Uecker, Martin

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=1569952166.3711.7.camel@med.uni-goettingen.de \
    --to=martin.uecker@med.uni-goettingen.de \
    --cc=gcc@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=richard.guenther@gmail.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).