Linux: add GYP flag for -fno-strict-aliasing.

build/common.gypi

 # Copyright (c) 2009 The Chromium Authors. All rights reserved.
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 
 {
   'variables': {
     # .gyp files should set chromium_code to 1 if they build Chromium-specific
     # code, as opposed to external code.  This variable is used to control
     # such things as the set of warnings to enable, and whether warnings are
     # treated as errors.
@@ skipping 336 matching lines @@
       ],
     },
   },
   'conditions': [
     ['OS=="linux"', {
       'target_defaults': {
         # Enable -Werror by default, but put it in a variable so it can
         # be disabled in ~/.gyp/include.gypi on the valgrind builders.
         'variables': {
           'werror%': '-Werror',
+          'no_strict_aliasing%': 0,
         },
         'cflags': [
           '<(werror)',  # See note above about the werror variable.
           '-pthread',
           '-fno-exceptions',
           '-Wall',
           '-D_FILE_OFFSET_BITS=64',
         ],
         'cflags_cc': [
           '-fno-rtti',
@@ skipping 165 matching lines @@
               ['chromeos==1', {
                 'cflags': [
                   '-march=armv7-a',
                   '-mtune=cortex-a8',
                   '-mfpu=vfp',
                   '-mfloat-abi=softfp',
                 ],
               }],
             ],
           }],
+          ['no_strict_aliasing==1', {
+            'cflags': [
+              '-fno-strict-aliasing',
+            ],
+          }],
         ],
       },
     }],
     ['OS=="mac"', {
       'target_defaults': {
         'variables': {
           # This should be 'mac_real_dsym%', but there seems to be a bug
           # with % in variables that are intended to be set to different
           # values in different targets, like this one.
           'mac_real_dsym': 0,  # Fake .dSYMs are fine in most cases.
@@ skipping 209 matching lines @@
     # settings in target dicts.  SYMROOT is a special case, because many other
     # Xcode variables depend on it, including variables such as
     # PROJECT_DERIVED_FILE_DIR.  When a source group corresponding to something
     # like PROJECT_DERIVED_FILE_DIR is added to a project, in order for the
     # files to appear (when present) in the UI as actual files and not red
     # red "missing file" proxies, the correct path to PROJECT_DERIVED_FILE_DIR,
     # and therefore SYMROOT, needs to be set at the project level.
     'SYMROOT': '<(DEPTH)/xcodebuild',
   },
 }