Slava points out that I am writing about use of bit_cast for pointer types (eg casting an Object** to a Class**), but ignoring the other use of bit_cast (eg casting a float to a uint32_t). It's only the pointer types that are problematic, I think.
On 3 December 2015 at 13:37, Erik Corry <[email protected]> wrote: > Some investigation by ager and some asking around has resulted in the > conclusion that bit_cast only serves to prevent warnings. It doesn't > actually fix the program's use of undefined behaviour. Mads was able to > get gcc to generate broken code for a function with strict aliasing issues > both with and without bit_cast. > > We have ripped bit_cast out of Fletch, replacing it with reinterpret_cast > everywhere. > > We have also added the -fno-strict-aliasing, since there's no sensible way > to fix a GC and a runtime for a dynamic language so it doesn't alias > pointers. (The only way I can think of involves getting rid of the C++ > "Object" class and treating the heap as a char array, which would be > horrible beyond belief). This flag is available on both Clang and gcc, and > is the default behaviour for MSVC. If you add the same flag to V8 you may > see a small performance regression on Linux, but not on Mac and Windows > where I think it already is the default. > > -- > Erik Corry > > Google Denmark ApS > Frederiksborggade 20B, 1 sal > 1360 København K > Denmark > CVR nr. 28 86 69 84 > -- Erik Corry Google Denmark ApS Frederiksborggade 20B, 1 sal 1360 København K Denmark CVR nr. 28 86 69 84 -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
