Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov

Subject: Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2013-11-15 08:50:39

 2013/11/15 Steven Watanabe <watanabesj_at_[hidden]>

> AMDG
>
> On 11/14/2013 12:29 PM, Niall Douglas wrote:
> > On 14 Nov 2013 at 7:01, Steven Watanabe wrote:
> >
> >> No, it is not harmless.  You cannot safely assume
> >> that undefined behavior is ever harmless, just
> >> because you can't think of anything that can go wrong.
> >> In particular, the compiler is free to make assumptions
> >> that can cause your code to miscompile with optimizations on.
> >
> > For the purposes of my peer review report, can you say if you know of
> > any misoperation which any major compiler might do in this
> > circumstance?
> >
>
> I believe that this was a problem for Boost.Move with gcc,
> which does something similar.  It's actually quite common
> for old C code that casts between different structs to fail
> with newer compilers.  For instance, Python does not work
> without -fno-strict-aliasing.

Looks like I've got what are you talking about. It's an optimization in
GCC, that assumes that if there is a reference to two different types and
neither of those types is char, than those types are different in memory
(are not aliases):

void foo(int64_t& v1, int32_t& v2) {
    /* GCC assumes that address of v1 is not a part of v2 adresses*/
    v2 = 2;
    cout << v1;
}

int64_t i64 = 1;
foo(i64, reinterpret_cast<int32_t>(i64)); // outputs 1

But this error appears only when we mutate data (
https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines search
for "strict-aliasing rules")

-- 
Best regards,
Antony Polukhin