https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org
--- Comment #33 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
From IRC discussion today about this:
<jakub> so, for PR79671 would you be ok with say new may_alias_field attribute
allowed on FIELD_DECLs only that forces has_zero_child on the containing type?
<jakub> or may_alias_fields type attribute that would force has_zero_child on
that type
<jakub> I have no idea what else boost/libstdc++ could use for the mess they
want/need to do
<richi> didn't I provide a solution for them?
<richi> IMHO the bug is still INVALID
<richi> not sure if adding has_zero_child will have any effect - the same issue
exists for B with char[] array member you placement new into
<jakub> the problem with that solution is that you need to move it to the
outermost type, say if somebody puts that weirdo boost class into
some other class, then assignments will not work again
<richi> iff the FE decides that copying PODs is semantically equivalent to
memcpy (alias-wise) then it has to emit it that way (but as said in comment #28
there is no evidence the standard suggests that)
<richi> yes, because C++ doesnt' work that way
<richi> it's very simple...
<richi> and I bet adding ->has_zero_child = 1 to B doesn't actually help in
general
<jakub> my understanding was that jason disagrees with that
<richi> I see no comment in the bug from jason
<jakub> let's discuss it later today when jason/jwakely are both around
<richi> the C++ FE can simply use alias-set zero for POD assignments then
<richi> thus change c = *p; to MEM[&c, alias-set-zero] = MEM[p,
alias-set-zero];
<richi> the important thing to notice is that it is 'c = *p' that is undefined
