[Bug c/34156] New: gcc ignores the __may_alias__ attribute on a struct typedef

[Bug c/34156] New: gcc ignores the __may_alias__ attribute on a struct typedef

[acahalan at gmail dot com]

gcc ignores the __may_alias__ attribute on a struct typedef

This is gcc as of Mon Nov 19 21:35:13 2007 UTC.

There are numerous problems with forcing users to put
the attribute there. First of all, given the number of
people who put the attribute on the typedef, that is
clearly what people find to be natural. Second of all,
the struct definition may be coming from a header file
that the user does not control. Third of all, the need
for both aliasing and non-aliasing versions of a struct
creates data type incompatibilities if one can not
simply be a typedef that refers to the other.

See also: #28834, #29436, and the numerous duplicates
of both. (people REALLY expect this syntax to work)


-- 
           Summary: gcc ignores the __may_alias__ attribute on a struct
                    typedef
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: acahalan at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34156

[Bug c/34156] gcc ignores the __may_alias__ attribute on a struct typedef

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2007-11-20 02:24 -------
Please read the dicussion starting at:
http://gcc.gnu.org/ml/gcc/2007-11/msg00213.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34156

[Bug c/34156] gcc ignores the __may_alias__ attribute on a struct typedef

[acahalan at gmail dot com]

------- Comment #2 from acahalan at gmail dot com  2007-11-20 05:35 -------
(In reply to comment #1)
> Please read the dicussion starting at:
> http://gcc.gnu.org/ml/gcc/2007-11/msg00213.html

Discussion noted.

It seems like the 100% workable solution is to let the C++ compiler factor
attributes into the name mangling scheme.

I can also imagine trying to hide the distinction, possibly maintaining it up
until the point at which the compiler generates output. This may even be what
users would most desire, assuming the C++ exception stuff can be made to work.

Making this C-only is another option, though a rather crummy one.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34156

[Bug c/34156] gcc ignores the __may_alias__ attribute on a struct typedef

[vda dot linux at googlemail dot com]

------- Comment #3 from vda dot linux at googlemail dot com  2010-02-04 14:33 -------
I was bitten by this whet I was trying to get rid of
"warning: dereferencing type-punned pointer will break strict-aliasing rules"
on this fairly normal networking-related code:

if (cmsgptr->cmsg_level == IPPROTO_IP && cmsgptr->cmsg_type == IP_PKTINFO) {
# define pktinfo(cmsgptr) ((struct in_pktinfo*)(CMSG_DATA(cmsgptr)))
    to->sa_family = AF_INET;
    memcpy(&to4->sin_addr, &pktinfo(cmsgptr)->ipi_addr, sizeof(to4->sin_addr));

I can't modify struct in_pktinfo declaration, it's in system header, so I
wanted to create a "aliasing" version of it, but this doesn't work for structs.


Distilled, the problem is that this works:

typedef int aliased_int __attribute__((__may_alias__));

but the same thing on structs does not, even if struct is hidden behind an
intermediate typedef:

struct s { int i; };
typedef struct s t;
typedef struct s aliased_s __attribute__((__may_alias__));
typedef t aliased_t __attribute__((__may_alias__));

last two typedefs both throw:

warning: ignoring attributes applied to 'struct s' after definition


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34156

[Bug c/34156] gcc ignores the __may_alias__ attribute on a struct typedef

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2010-02-04 15:38 -------
The easiest way would be to expose the middle-end ref-all pointer annotation
so you could do typedef struct T *my_ptr __attribute__((ref_all)).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34156