[gn] Restore strict-aliasing for gn on mac

[gn] Restore strict-aliasing for gn on mac

BUG=chromium:474921, chromium:626064
NOTRY=true

[Michael Achenbach, 2016-07-14 12:36:56]

Description was changed from

==========
[gn] Restore strict-aliasing for gn on mac

BUG=
==========

to

==========
[gn] Restore strict-aliasing for gn on mac

BUG=chromium:474921
==========

[Michael Achenbach, 2016-07-14 12:36:57]

machenbach@chromium.org changed reviewers:
+ jochen@chromium.org, thakis@chromium.org

[Michael Achenbach, 2016-07-14 12:37:38]

Description was changed from

==========
[gn] Restore strict-aliasing for gn on mac

BUG=chromium:474921
==========

to

==========
[gn] Restore strict-aliasing for gn on mac

BUG=chromium:474921
NOTRY=true
==========

[Michael Achenbach, 2016-07-14 12:43:42]

PTAL. I'm not so sure about this change. This would restore what we had in gyp
on the v8 side, e.g.:

https://cs.chromium.org/chromium/src/v8/gypfiles/toolchain.gypi?q=strict-alia...
https://cs.chromium.org/chromium/src/tools/gyp/pylib/gyp/xcode_emulation.py?q...

But in gn there seems to exist a chromium-wide default that sets
no-strict-aliasing:

https://cs.chromium.org/chromium/src/build/config/compiler/BUILD.gn?q=strict-...

As long as this exists for mac, the two flags would live side-by-side (not sure
which takes precedence). Did it maybe get migrated wrong? In common.gypi it was
conditioned by 'os_posix==1 and OS!="mac" and OS!="ios"':
https://cs.chromium.org/chromium/src/build/common.gypi?q=strict-aliasing+file...

In gn it's only conditioned by !is_win, which now includes mac.

[Michael Achenbach, 2016-07-14 12:44:12]

Description was changed from

==========
[gn] Restore strict-aliasing for gn on mac

BUG=chromium:474921
NOTRY=true
==========

to

==========
[gn] Restore strict-aliasing for gn on mac

BUG=chromium:474921, chromium:626064
NOTRY=true
==========

[Nico, 2016-07-14 13:37:30]

Adding this just on mac looks weird to me. I think we generally should try to
have matching compiler flags across platforms (where reasonable).

If v8 doesn't have any reinterpret_casts or feels comfortable building with this
flag for other reasons, adding it for v8 seems fine. Chromium pretty certainly
has code that will be miscompiled without -fno-strict-aliasing. (I thought I saw
a bunch of type punning in v8 as well.)

From what I understand, v8 previously only used the flag in standalone builds,
not when it was built as part of Chromium, right? If you add this to gn, it'll
be used in Chromium builds as well.

If you do want to do this, I think the way to do this would be to move
-fno-strict-aliasing in the chromium repo into its own config, and then remove
that config for v8, so that you don't have to hope that flags appear in the
right order.

[Michael Achenbach, 2016-07-14 13:44:24]

> From what I understand, v8 previously only used the flag in standalone builds,
> not when it was built as part of Chromium, right? If you add this to gn, it'll
> be used in Chromium builds as well.

No, v8 used it also in chromium builds. It's defined in our toolchain.gypi.

[Michael Achenbach, 2016-07-15 08:34:21]

Correction: -fno-strict-aliasing was also set for mac before:
https://cs.chromium.org/chromium/src/build/common.gypi?q=strict-aliasing&sq=p...

It looks like in gyp, for v8 objects on mac we passed -fno-strict-aliasing and
-fstrict-aliasing. We'd do the same with this change. I'm hesitating to remove
-fno-strict-aliasing for v8 as this might really change behavior.

I suggest we keep the chromium wide default -fno-strict-aliasing and submit a
bug for analyzing if
1) -fstrict-aliasing gives a performance improvement for v8 and
2) -fstrict-aliasing doesn't expose any undefined behavior in v8 code.