Possible narrowing conversion build fix for Compositor API example.

ppapi/examples/compositor/compositor.cc

 // Copyright 2014 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.
 
 // Needed on Windows to get |M_PI| from math.h.
 #ifdef _WIN32
 #define _USE_MATH_DEFINES
 #endif
 
 #include <math.h>
@@ skipping 291 matching lines @@
 
   {
     // Set the image layer
     if (image_layer_.is_null()) {
       image_layer_ = compositor_.AddLayer();
       assert(!image_layer_.is_null());
     }
     float x = frame % 800;
     float y = 200 - 200 * factor_sin;
     const float transform[16] = {
-      fabs(factor_sin) + 0.2f, 0.0f, 0.0f, 0.0f,
-      0.0f, fabs(factor_sin) + 0.2f, 0.0f, 0.0f,
+      fabsf(factor_sin) + 0.2f, 0.0f, 0.0f, 0.0f,
+      0.0f, fabsf(factor_sin) + 0.2f, 0.0f, 0.0f,

[dmichael (off chromium), 2014/06/17 16:16:00]

factor_sin is a float, and fabs is supposed to have an overload for float...
http://www.cplusplus.com/reference/cmath/fabs/
(see also 26.5p6 in C++03, 26.8p9 in C++11).

This seems to me like a bug GCC 4.9's C++11 support. We also don't yet build
Chromium in C++11 mode, so I'd be surprised if you didn't run in to other
problems.

You might consider making a small reproducer and filing a bug with GCC.

       0.0f, 0.0f, 1.0f, 0.0f,
          x,    y, 0.0f, 1.0f,
     };
     rv = image_layer_.SetTransform(transform);
     assert(rv == PP_OK);
 
     pp::ImageData image = PrepareImage();
     uint8_t *p = static_cast<uint8_t*>(image.data());
     for (int x = 0; x < kImageWidth; ++x) {
       for (int y = 0; y < kImageHeight; ++y) {
@@ skipping 106 matching lines @@
 };
 
 }  // anonymous namespace
 
 namespace pp {
 // Factory function for your specialization of the Module object.
 Module* CreateModule() {
   return new DemoModule();
 }
 }  // namespace pp