build/common.gypi: revert the change to GCC_STRICT_ALIASING:NO because some bots have a too-old xco…

build/common.gypi: revert the change to GCC_STRICT_ALIASING:NO because some bots have a too-old xcode.

In particular, rolling chromium_revision in webrtc from 211877 to 211878 broke
the webrtc mac Release bots:
http://build.chromium.org/p/client.webrtc/builders/Mac64%20Release/builds/296
http://build.chromium.org/p/client.webrtc/builders/Mac32%20Release/builds/312
http://build.chromium.org/p/client.webrtc/builders/Mac%20Asan/builds/304

The breakage did not repro on the webrtc trybots which use ninja (filed
https://code.google.com/p/webrtc/issues/detail?id=2135 to fix the inconsistency)
nor did it repro in an xcode build on my MBP (4.6.3).  My theory is that the
xcode on the bots (e.g. vm674-m3) is too old (4.5.1).

R=thakis@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=214260

[Ami GONE FROM CHROMIUM, 2013-07-26 06:19:37]

Nico: this is the minimum I needed to do to get back to working order for the
webrtc roll.  I hope you can take over any longer-term changes to gyp if you
really want to make this transition from explicit flag to xcode setting.
(namely, probably need to find a list of the xcode settings supported in each
version and declare a minimum for builders that use build/common.gypi in any
way)

[Nico, 2013-07-26 16:20:26]

All of the builder links the in the CL description give me a "not found".

Reverting this will break v8 as far as I understand. If this only works in Xcode
4.6+, v8 shouldn't use GCC_STRICT_ALIASING either though.

Can you add a comment that says "Don't use GCC_STRICT_ALIASING as this only
works in Xcode 4.6+"?

[Nico, 2013-07-26 16:22:08]

…but someone tells me that GCC_STRICT_ALIASING should work since at least 3.2
(they aren't sure tho), so maybe webrtc tries to flip this switch using the old
mechanism, and just using GCC_STRICT_ALIASING instead of OTHER_CFLAGS in some
webrtc file will make things work? You can check the xcode build output to see
if it actually uses -fno-strict-aliasing with GCC_STRICT_ALIASING

[Ami GONE FROM CHROMIUM, 2013-07-26 16:48:57]

xcodebuild output shows it does _not_ specify -fno-strict-aliasing when
GCC_STRICT_ALIASING=NO on the bots (but does on my MBP).
Your theory about an errant 'OTHER_CFLAGS!' or similar is interesting, but
I see no evidence of it.
Also, we _want_ the "no" value for webrtc - so if anything we should be
seeing _both_ GCC_STRICT_ALIASING and OTHER_CFLAGS incarnations of the
no-strict-aliasing flag, but we don't - it looks like webrtc has always
inherited this from chromium's common.gypi.

Is there a chrome mac bot that still builds with xcode?  It would be
informative to see whether -fno-strict-aliasing disappeared silently when
your change landed.  I want to revert this in chromium's build/common.gypi
(and not simply add the OTHER_CFLAGS to a webrtc common.gypi) because (I'm
told) this causes a real quality regression in webrtc and I want to avoid
that quality regression in xcode-built chromiums.  If such a thing even
exists, hence the q at the top of this paragraph :)

What is the v8 issue?


On Fri, Jul 26, 2013 at 9:22 AM, <thakis@chromium.org> wrote:

> …but someone tells me that GCC_STRICT_ALIASING should work since at least
> 3.2
> (they aren't sure tho), so maybe webrtc tries to flip this switch using
> the old
> mechanism, and just using GCC_STRICT_ALIASING instead of OTHER_CFLAGS in
> some
> webrtc file will make things work? You can check the xcode build output to
> see
> if it actually uses -fno-strict-aliasing with GCC_STRICT_ALIASING
>
>
https://codereview.chromium.**org/20666002/<https://codereview.chromium.org/2...
>

[Dirk Pranke, 2013-07-26 16:52:31]

On 2013/07/26 16:48:57, Ami Fischman wrote:
> 
> What is the v8 issue?
> 

The v8 issue is https://codereview.chromium.org/19384011/ (and some earlier
patches), which uncovered this issue. We're trying to speed up the debug build
of v8.

[Ami GONE FROM CHROMIUM, 2013-07-26 16:55:28]

http://developer.apple.com/library/ios/#releasenotes/developertools/rn-xcode/
implies
that GCC_STRICT_ALIASING was born in 4.6, so I think that's pretty good
motivation to not use it yet.

Dirk: would you mind adding to your CL an OTHER_CFLAGS! section to undo the
explicit -fno-strict-aliasing I'm proposing to add here, in the branch(es)
where now you have GCC_STRICT_ALIASING=YES?


On Fri, Jul 26, 2013 at 9:52 AM, <dpranke@chromium.org> wrote:

> On 2013/07/26 16:48:57, Ami Fischman wrote:
>
>  What is the v8 issue?
>>
>
>
> The v8 issue is
https://codereview.chromium.**org/19384011/<https://codereview.chromium.org/1...
some earlier
> patches), which uncovered this issue. We're trying to speed up the debug
> build
> of v8.
>
>
https://codereview.chromium.**org/20666002/<https://codereview.chromium.org/2...
>

[Ami GONE FROM CHROMIUM, 2013-07-26 16:57:36]

Uploaded new patchset with explanatory comment about requiring >=4.6 for
GCC_STRICT_ALIASING.

https://codereview.chromium.**org/20666002/<https://codereview.chromium.org/2...
>>
>
>

[Nico, 2013-07-26 16:57:48]

On Fri, Jul 26, 2013 at 9:48 AM, Ami Fischman <fischman@chromium.org> wrote:

> xcodebuild output shows it does _not_ specify -fno-strict-aliasing when
> GCC_STRICT_ALIASING=NO on the bots (but does on my MBP).
> Your theory about an errant 'OTHER_CFLAGS!' or similar is interesting, but
> I see no evidence of it.
> Also, we _want_ the "no" value for webrtc - so if anything we should be
> seeing _both_ GCC_STRICT_ALIASING and OTHER_CFLAGS incarnations of the
> no-strict-aliasing flag, but we don't - it looks like webrtc has always
> inherited this from chromium's common.gypi.
>

Can you ssh into the bot (or find some Xcode 4.5 elsewhere) and do:

$ cat > foo.gyp
{
  'targets': [
    {
      'target_name': 'aliasing_yes',
      'type': 'executable',
      'sources': [ 'aliasing.cc', ],
      'xcode_settings': {
        'GCC_STRICT_ALIASING': 'YES',
        'GCC_OPTIMIZATION_LEVEL': 2,
      },
    },
    {
      'target_name': 'aliasing_no',
      'type': 'executable',
      'sources': [ 'aliasing.cc', ],
      'xcode_settings': {
        'GCC_STRICT_ALIASING': 'NO',
        'GCC_OPTIMIZATION_LEVEL': 2,
      },
    },
    {
      'target_name': 'aliasing_default',
      'type': 'executable',
      'sources': [ 'aliasing.cc', ],
      'xcode_settings': {
        'GCC_OPTIMIZATION_LEVEL': 2,
      },
    },
  ],
}
$ path/go/gyp --depth . foo.gyp
$ xcodebuild

and paste the output of this?

(This is similar to test/mac/xcode-gcc/test-aliasing.gyp which runs on
http://build.chromium.org/f/client/gyp/ which has xcode 4.4 or so, and that
passes, but maybe that's because 'NO' just results in the flag being off
and xcodebuild relying on the compiler to keep this off by default.)


> Is there a chrome mac bot that still builds with xcode?
>

Yes, the official builder, and on the main waterfall the clobber builder
and the release (I think; otherwise debug) builder.


> It would be informative to see whether -fno-strict-aliasing disappeared
> silently when your change landed.  I want to revert this in chromium's
> build/common.gypi (and not simply add the OTHER_CFLAGS to a webrtc
> common.gypi) because (I'm told) this causes a real quality regression in
> webrtc and I want to avoid that quality regression in xcode-built
> chromiums.  If such a thing even exists, hence the q at the top of this
> paragraph :)
>
> What is the v8 issue?
>

V8 tries to override what's set in build/common.gypi by explicitly setting
GCC_STRICT_ALIASING to something else.


>
>
> On Fri, Jul 26, 2013 at 9:22 AM, <thakis@chromium.org> wrote:
>
>> …but someone tells me that GCC_STRICT_ALIASING should work since at least
>> 3.2
>> (they aren't sure tho), so maybe webrtc tries to flip this switch using
>> the old
>> mechanism, and just using GCC_STRICT_ALIASING instead of OTHER_CFLAGS in
>> some
>> webrtc file will make things work? You can check the xcode build output
>> to see
>> if it actually uses -fno-strict-aliasing with GCC_STRICT_ALIASING
>>
>>
https://codereview.chromium.**org/20666002/<https://codereview.chromium.org/2...
>>
>
>

[Ami GONE FROM CHROMIUM, 2013-07-26 17:17:21]

> Can you ssh into the bot (or find some Xcode 4.5 elsewhere) and do:
>

The result (from both the Bot and my MBP) is at
https://gist.github.com/fischman/7028d9fece1b1ddd2dc8 and shows that while
aliasing_yes gets -fstrict-aliasing, neither aliasing_no nor
aliasing_default gets -fno-strict-aliasing (or -fstrict-aliasing, for
_default) on the bot.  Contrarily, on my MBP each of the targets gets a
relevant flag, and the default is strict.  Updated commentary even more.

V8 tries to override what's set in build/common.gypi by explicitly setting
> GCC_STRICT_ALIASING to something else.
>

yeah, I think v8 will need to unset the cflag explicitly.


>
https://codereview.chromium.**org/20666002/<https://codereview.chromium.org/2...
>>>
>>
>>
>

[Nico, 2013-07-27 21:13:09]

lgtm, thanks for the research!

dpranke: can you make sure v8 does the right thing

[commit-bot: I haz the power, 2013-07-28 15:45:41]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/fischman@chromium.org/20666002/17001

[commit-bot: I haz the power, 2013-07-28 17:22:45]

Retried try job too often on win7_aura for step(s) interactive_ui_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win7_aura&...

[commit-bot: I haz the power, 2013-07-28 18:08:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/fischman@chromium.org/20666002/17001

[commit-bot: I haz the power, 2013-07-28 19:54:46]

Retried try job too often on win7_aura for step(s) interactive_ui_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win7_aura&...

[commit-bot: I haz the power, 2013-07-28 22:46:36]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/fischman@chromium.org/20666002/17001

[commit-bot: I haz the power, 2013-07-29 00:08:04]

Retried try job too often on win7_aura for step(s) interactive_ui_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win7_aura&...

[commit-bot: I haz the power, 2013-07-29 00:56:54]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/fischman@chromium.org/20666002/17001

[commit-bot: I haz the power, 2013-07-29 02:32:35]

Retried try job too often on win7_aura for step(s) interactive_ui_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win7_aura&...

[commit-bot: I haz the power, 2013-07-29 04:43:08]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/fischman@chromium.org/20666002/17001

[commit-bot: I haz the power, 2013-07-29 06:29:24]

Retried try job too often on win7_aura for step(s) interactive_ui_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win7_aura&...

[commit-bot: I haz the power, 2013-07-29 07:03:52]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/fischman@chromium.org/20666002/17001

[commit-bot: I haz the power, 2013-07-29 08:43:10]

Retried try job too often on win7_aura for step(s) interactive_ui_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win7_aura&...

[commit-bot: I haz the power, 2013-07-29 16:05:07]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/fischman@chromium.org/20666002/17001

[Ami GONE FROM CHROMIUM, 2013-07-29 23:35:52]

Committed patchset #3 manually as r214260 (presubmit successful).