https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
--- Comment #11 from Tavian Barnes ---
Yeah I reported the Boost bug as https://svn.boost.org/trac/boost/ticket/12183.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
--- Comment #10 from Richard Biener ---
Hmm, so trying to preserve alias-set zero from the BIT_FIELD_REF folding using
a MEM_REF and reference_alias_ptr_type doesn't work as the latter doesn't
preserve the langhook effects (duh, that's some inter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
--- Comment #9 from Richard Biener ---
So optimize_bit_field_compare does make a difference implementation-wise
(but not really fixes the undefinedness in the boost code wrt the access
of the non-active union-member when reading from is_short).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
--- Comment #8 from Richard Biener ---
Note that ultimatively the error is still that is_short () accesses the wrong
union member.
I'll still see whether there is a bug in optimize_bit_field_compare.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
--- Comment #6 from rguenther at suse dot de ---
On Mon, 9 May 2016, tavianator at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
>
> --- Comment #5 from Tavian Barnes ---
> > But if it is not POD then assuming it ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
--- Comment #5 from Tavian Barnes ---
> But if it is not POD then assuming it gets copied correctly when
> init-constructing a POD union where they placed such object is
> an interesting assumption...
Hrm? They seem to always copy it manually w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
--- Comment #4 from rguenther at suse dot de ---
On Mon, 9 May 2016, tavianator at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
>
> --- Comment #3 from Tavian Barnes ---
> Because their long_t is not POD. I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
--- Comment #3 from Tavian Barnes ---
Because their long_t is not POD. I don't know why that is though. It could be
POD if they removed the default/copy constructors and assignment operator.
Actually they're probably worried about custom alloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
--- Comment #2 from Richard Biener ---
The issue is similar to that in PR70054 in that for example string::swap_data
copy-initializes repr_t which has the long_raw_t member that is not of the
type that it is modified as (for some odd reason).
(j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
11 matches
Mail list logo
