This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/65892] gcc fails to implement N685 aliasing of union members


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892

--- Comment #33 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #30)
> Richard, I offered to write a proposal (with Clark) to improve the rules. 
> With the object model proposals already in the pipeline (N2223) this is a
> good time to review them and see if it makes sense to extend or change them
> to also cover this case in an acceptable way.  It would be helpful if you
> could take some time to summarize your main concerns or suggestions for
> changes in this area.  I can start working on the proposal for the fall 2018
> WG14 meeting.

That's a load of information dangling from
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2223.htm (if I googled that
correctly).  It seems to be mostly
questions and observations plus opinions being raised, sometimes obvious cases
missing and "recent" (> GCC 4.5) GCC behavior not correctly reflected.

I'm not sure in which form I can provide useful feedback here, just to mention
a few misconceptions the authors have from browsing part of the material:

- they say memcpy transfers the effective type, in other parts of the standard
  it says that memcpy accesses use a character type.  That raises the question
  whether a memcpy implementation using a sequence of char reads/writes matches
  this semantics and thus what the effective type of the memory location
written
  to via a character type is -- is it allowed to access that via any other
  effective type (or just the effective type of the source if that is somehow
  visible to the compiler)?

- when asking for a char[] array to be treated the same as allocated storage
  with respect to changing its effective type (declared objects have a fixed
  effective type) they fail to consider the issue that we recently ran into
  with C++:
   struct { int i; char buf[4]; } s, r;
   *(float *)s.buf = 1.;
   r = s;
  how does the aggregate copying work?  The effective type of the access
  is not compatible with the emplaced float which means it doesn't work
  in GCC.  Same if you replace all of the above with allocated storage.
  Does that mean a structure with char members are somehow special?

So overall there's too much material to go over - what's the exact standard
wording changes suggested?  Maybe I just didn't find them ...

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]