Bug 34156 - gcc ignores the __may_alias__ attribute on a struct typedef
Summary: gcc ignores the __may_alias__ attribute on a struct typedef
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-20 02:18 UTC by Albert Cahalan
Modified: 2024-03-28 04:11 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Albert Cahalan 2007-11-20 02:18:50 UTC
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)
Comment 1 Andrew Pinski 2007-11-20 02:24:47 UTC
Please read the dicussion starting at:
http://gcc.gnu.org/ml/gcc/2007-11/msg00213.html
Comment 2 Albert Cahalan 2007-11-20 05:35:21 UTC
(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.
Comment 3 Denis Vlasenko 2010-02-04 14:33:24 UTC
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
Comment 4 Richard Biener 2010-02-04 15:38:59 UTC
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)).