Add SkMSAN.h

Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.


(Sometimes we have another option, to rewrite the code to avoid branching:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to assert anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }
These approaches to fixing MSAN false positives are orthogonal.)

BUG=chromium:574114
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1658913005
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot

Committed: https://skia.googlesource.com/skia/+/1059b1fc9f8711592a81836512850d123d75146d

[mtklein_C, 2016-02-02 19:05:19]

Description was changed from

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Most code requires initialized inputs, of course.  This is mostly for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g.

static uint8_t max(uint8_t x, uint8_t y) {
    // This function uses branching, so if MSAN find a problem here, we might
    // want to assert x and y are initialized:
    sk_msan_assert_initialized(&x, &x+1);
    sk_masn_assert_initialized(&y, &y+1);
    return x > y ? x : y;
}

static uint8_t max_branchfree(uint8_t x, uint8_t y) {
    // This function is branchfree, so MSAN is unlikely to complain in here.
    // No real need to tag anything as requiring initialization.
}

By starting with an assertion that the input must be initialized, it makes it
clear that code's not the root problem.

BUG=skia:
==========

to

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:

  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

Or possibly do this:
  static uint8_t max_branchfree(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to tag anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.

BUG=skia:
==========

[mtklein_C, 2016-02-02 19:06:31]

Description was changed from

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:

  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

Or possibly do this:
  static uint8_t max_branchfree(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to tag anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.

BUG=skia:
==========

to

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

Or possibly do this:
  static uint8_t max_branchfree(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to tag anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.

BUG=skia:
==========

[mtklein_C, 2016-02-02 19:06:57]

Description was changed from

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

Or possibly do this:
  static uint8_t max_branchfree(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to tag anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.

BUG=skia:
==========

to

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

(Or of course we might do something like this:)
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to tag anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.

BUG=skia:
==========

[mtklein_C, 2016-02-02 19:07:13]

Description was changed from

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

(Or of course we might do something like this:)
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to tag anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.

BUG=skia:
==========

to

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

(Or of course we might do something like this:)
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to assert anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.

BUG=skia:
==========

[mtklein_C, 2016-02-02 19:08:00]

Description was changed from

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

(Or of course we might do something like this:)
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to assert anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.

BUG=skia:
==========

to

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.


Sometimes we have another option, to rewrite the code to avoid branching:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to assert anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }
This is an orthogonal approach to fixing MSAN false positives.

BUG=skia:
==========

[mtklein_C, 2016-02-02 19:08:38]

Description was changed from

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.


Sometimes we have another option, to rewrite the code to avoid branching:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to assert anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }
This is an orthogonal approach to fixing MSAN false positives.

BUG=skia:
==========

to

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.


(Sometimes we have another option, to rewrite the code to avoid branching:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to assert anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }
This is an orthogonal approach to fixing MSAN false positives.)

BUG=skia:
==========

[mtklein_C, 2016-02-02 19:12:31]

The CQ bit was checked by mtklein@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-02 19:12:37]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1658913005/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1658913005/1

[mtklein_C, 2016-02-02 19:13:12]

Description was changed from

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.


(Sometimes we have another option, to rewrite the code to avoid branching:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to assert anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }
This is an orthogonal approach to fixing MSAN false positives.)

BUG=skia:
==========

to

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.


(Sometimes we have another option, to rewrite the code to avoid branching:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to assert anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }
This is an orthogonal approach to fixing MSAN false positives.)

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
==========

[mtklein_C, 2016-02-02 19:17:34]

Description was changed from

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.


(Sometimes we have another option, to rewrite the code to avoid branching:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to assert anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }
This is an orthogonal approach to fixing MSAN false positives.)

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
==========

to

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.


(Sometimes we have another option, to rewrite the code to avoid branching:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to assert anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }
This is an orthogonal approach to fixing MSAN false positives.)

BUG=chromium:574114
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
==========

[mtklein_C, 2016-02-02 19:22:41]

The CQ bit was checked by mtklein@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-02 19:22:50]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1658913005/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1658913005/40001

[mtklein_C, 2016-02-02 19:25:06]

Description was changed from

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.


(Sometimes we have another option, to rewrite the code to avoid branching:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to assert anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }
This is an orthogonal approach to fixing MSAN false positives.)

BUG=chromium:574114
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
==========

to

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.


(Sometimes we have another option, to rewrite the code to avoid branching:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to assert anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }
These approaches to fixing MSAN false positives are orthogonal.)

BUG=chromium:574114
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
==========

[mtklein_C, 2016-02-02 19:29:41]

mtklein@chromium.org changed reviewers:
+ eugenis@google.com, reed@google.com

[eugenis, 2016-02-02 19:44:45]

eugenis@chromium.org changed reviewers:
+ eugenis@chromium.org

[eugenis, 2016-02-02 19:44:46]

LGTM

[commit-bot: I haz the power, 2016-02-02 20:47:52]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-02 20:47:52]

Dry run: This issue passed the CQ dry run.

[mtklein, 2016-02-03 15:24:08]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2016-02-03 15:24:19]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1658913005/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1658913005/40001

[commit-bot: I haz the power, 2016-02-03 15:25:04]

Description was changed from

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.


(Sometimes we have another option, to rewrite the code to avoid branching:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to assert anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }
These approaches to fixing MSAN false positives are orthogonal.)

BUG=chromium:574114
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
==========

to

==========
Add SkMSAN.h

This lets us tag up pieces of code as requiring initialized inputs.

Almost all code requires initialized inputs, of course.  This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN.  E.g., imagine MSAN's found use of uninitialized
data in this max function:

  static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }

There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.

So we might do this:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function uses branching, so if MSAN finds a problem here, 
      // we can assert x and y are initialized.  This will remind us the
      // problem somewhere in the caller or above, not here.
      sk_msan_assert_initialized(&x, &x+1);
      sk_masn_assert_initialized(&y, &y+1);
      return x > y ? x : y;
  }

By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.


(Sometimes we have another option, to rewrite the code to avoid branching:
  static uint8_t max(uint8_t x, uint8_t y) {
      // This function is branchfree, so MSAN won't complain here.
      // No real need to assert anything as requiring initialization.
      int diff = x - y;
      int negative = diff >> (sizeof(int)*8 - 1);
      return (y & negative) | (x & ~negative);
  }
These approaches to fixing MSAN false positives are orthogonal.)

BUG=chromium:574114
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot

Committed:
https://skia.googlesource.com/skia/+/1059b1fc9f8711592a81836512850d123d75146d
==========

[commit-bot: I haz the power, 2016-02-03 15:25:05]

Committed patchset #3 (id:40001) as
https://skia.googlesource.com/skia/+/1059b1fc9f8711592a81836512850d123d75146d