We've failed to get these bots to report where issues happen
any more finely than the name of the executable, which makes
them a real pain to fix when they go red.
We don't expect we'll be able to run cleanly in this mode for
long without bots enforcing it, so remove support from GN too.
Change-Id: Ie86f0cbf2f5f859ac2ddb869da7e5b8d31b33fa0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/237195
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I127c979670c3dc7dac2e35908a795afbdefca8f6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/234902
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
If you just use the right compiler driver wrapper, recent NDKs automate
lots of the stuff we used to have to do ourselves.
Simplifying further, bump baseline ndk_api from 16 (Jellybean) on 32-bit
machines and 21 (Lollipop) on 64-bit to 21 across the board. This makes
using libc++ a lot easier, as it hooks into a bunch of APIs that were
added in 18 and 21. There's probably some way to work around this, but
the easiest thing is to just roll up.
Tested building {x86,arm}x{32,64} from a Linux host,
and running { arm}x{32,64}.
Kind of flailing around in later CLs trying to get linking not to hang
on Windows. I figure it's got something to do with lld?
Cq-Include-Trybots: skia.primary:Build-Win-Clang-arm64-Release-Android
Change-Id: I340b06fb9d372281146679d932417aaba3196045
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/225506
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Something's trying to link libc++.so by default,
so ask it to link libc++.a with -static-libstdc++.
Either way, the linker can't find libc++ without
adding another library directory path.
I think both changes should be harmlessly ignored
before r20.
Change-Id: I5b67e1dcb8b40548dae5a8300151e4392ae551f9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/225436
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
-dead_strip works just fine there without those flags,
and they interfere with embedded bitcode.
Change-Id: If3766d245334fd9fa275e90fe67216ababafcecb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/222450
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This will ensure that the headers from the dependencies will have
precedent over system headers, thus preventing situations where system
headers will block dependency headers and prevent compilation.
Change-Id: I0d480a6d3898f2da99cf2706c5335aaac05b4e4d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220276
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Start out with spinlock. I tried to be more extensive, but some
of our abstractions confused the analysis. Will expand further
in following CLs.
Change-Id: I3e320c957d8ef427065a2b7e7d2187b7c6b0aef1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/213060
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Most external users complain about -Werror,
and I've heard anecdotally that devs find it annoying too.
This turns it off by default, but keeps it on the bots.
Change-Id: I6e87c92215261ebf6e961f816177386d5d58f28e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/209787
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Nothing too tricky...
1) tell clang-cl to --target=arm64-windows
2) work around minor libpng issue temporarily
Change-Id: I4f0d792438610268821b67b92caf08fd78dcec4f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/208882
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
These changes let us build a non-official component build on Windows,
using either MSVC or clang
Change-Id: Ia3279aa19e007e70ff28925ff70a0bfe8144d96f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/207307
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
I've been setting this in extra_cflags for a couple years...
maybe it's time everyone gets color in their warnings.
Change-Id: I1fed38a521fe9331b60fbb0688d39b5188a86aca
Reviewed-on: https://skia-review.googlesource.com/c/196360
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Just a few strays.
Change-Id: Ib209bc8dd228850b837b850dce14967a2112593e
Reviewed-on: https://skia-review.googlesource.com/c/191161
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
a54104803d..52d861bd49
git log a54104803d72..52d861bd49cc --date=short --no-merges --format='%ad %ae %s'
2019-02-02 syoussefi@chromium.org Disable -Wextra-semi-stmt
2019-02-02 ianelliott@google.com Implement EGL_ANDROID_recordable for Vulkan back-end.
2019-02-01 jonahr@google.com Fix unnecessary copy of for loop variables in ANGLE
2019-02-01 syoussefi@chromium.org Use env variable to select default backend
2019-02-01 jmadill@chromium.org Enable -Wextra-semi and -Wextra-semi-stmt.
2019-02-01 syoussefi@chromium.org Initial support for compiler AST validation
2019-02-01 jmadill@chromium.org Roll glslang.
2019-02-01 ckulakowski@opera.com Fix for linking of non-component angle_unittests
Created with:
gclient setdep -r third_party/externals/angle2@52d861bd49cc
The AutoRoll server is located here: https://autoroll.skia.org/r/angle-skia-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.
CQ_INCLUDE_TRYBOTS=skia.primary:Build-Debian9-Clang-x86_64-Release-ANGLE;skia.primary:Perf-Win10-Clang-AlphaR2-GPU-RadeonR9M470X-x86_64-Debug-All-ANGLE;skia.primary:Perf-Win10-Clang-NUC5i7RYH-GPU-IntelIris6100-x86_64-Debug-All-ANGLE;skia.primary:Perf-Win10-Clang-NUC6i5SYK-GPU-IntelIris540-x86_64-Debug-All-ANGLE;skia.primary:Perf-Win10-Clang-NUCD34010WYKH-GPU-IntelHD4400-x86_64-Debug-All-ANGLE;skia.primary:Perf-Win10-Clang-ShuttleC-GPU-GTX960-x86_64-Debug-All-ANGLE;skia.primary:Test-Win10-Clang-AlphaR2-GPU-RadeonR9M470X-x86_64-Debug-All-ANGLE;skia.primary:Test-Win10-Clang-NUC6i5SYK-GPU-IntelIris540-x86_64-Debug-All-ANGLE;skia.primary:Test-Win10-Clang-NUCD34010WYKH-GPU-IntelHD4400-x86_64-Debug-All-ANGLE;skia.primary:Test-Win10-Clang-ShuttleC-GPU-GTX960-x86_64-Debug-All-ANGLE
TBR=borenet@google.com
Change-Id: I008df064f6301658404c371cf47a5656d8c11621
Reviewed-on: https://skia-review.googlesource.com/c/188852
Reviewed-by: Eric Boren <borenet@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: skia-autoroll <skia-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
This enables four different options in the compiler, described
below. I also added enough masks to satisfy RTCc when running
all GMs in both 8888 and gl configs.
---
/RTCc - Detects when a value is assigned to a smaller data
type and results in data loss. This happens even when casting.
Masking is required to suppress this.
/RTCs - Various stack-related checks, including uninitialized
data (by initializing locals to a non-zero value), array bounds
checking, and stack pointer corruption that can occur with a
calling convention mismatch.
/RTCu - Reports when a variable is used without having been
initialized. Mostly redundant with compile-time checks.
/guard:cf - This is more of a security option, that computes
all possible targets for indirect calls at compile time, and
verifies that those are the only targets reached at compile
time. Also generates similar logic around switch statements
that turn into jump tables.
Bug: skia:
Change-Id: I7b527af8fd67dec0b6556f38bcd0efc3fd505856
Reviewed-on: https://skia-review.googlesource.com/c/188625
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:
Change-Id: I09c2312c3678bdb1c48b427f446cb5865acb92a2
Reviewed-on: https://skia-review.googlesource.com/c/177074
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Might open up some neat options like LTO builds.
If nothing it's nice to use each whole toolchain consistently.
Move around some bonus quotes a bit.
LLD doesn't understand /DEBUG:FASTLINK.
Change-Id: I27e3c97acea6980c5bd006394aebb1e103007edd
Reviewed-on: https://skia-review.googlesource.com/c/175981
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I9ba1caa4862bdf9ffc9c0e637bd69cce91fd8468
Reviewed-on: https://skia-review.googlesource.com/c/168740
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This is a reland of 166dbd3135
Since last attempt,
- update SkPath::Direction docs
- kIllegal is not an advanced blend mode
Original change's description:
> make enum santizer fatal
>
> This enum sanitizer checks that all the values of the enum we use fall
> within the range of the enumerated values.
>
> The main thing this helps point out is that the size of enum types in
> C++ need only be large enough to hold the largest declared value; larger
> values are undefined. In practice, most enums are implemented as ints
> for compatibility with C, so while this hasn't pointed out anything
> egregiously broken, the sanitizer has found a couple possibly dangerous
> situations in our codebase.
>
> For most types using values outside the enum range, we can just
> explicitly size them to int. This makes their de facto size de jure.
>
> But we need to actually make GrBlendEquation and GrBlendCoeff not store
> values outside their enumerated range. They're packed into bitfields
> that really can't represent those (negative) values. So for these I've
> added new kIllegal values to the enums, forcing us to deal with our
> once-silent illegal values a bit more explicitly.
>
> Change-Id: Ib617694cf1aaa83ae99289e9e760f49cb6393a2f
> Reviewed-on: https://skia-review.googlesource.com/c/168484
> Reviewed-by: Brian Osman <brianosman@google.com>
Cq-Include-Trybots: skia.primary:Housekeeper-PerCommit-Bookmaker,Test-Android-Clang-AndroidOne-GPU-Mali400MP2-arm-Debug-All-Android
Change-Id: Id93b80bbeae11872542c9b76715e3c3cb10609fd
Reviewed-on: https://skia-review.googlesource.com/c/168582
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This reverts commit 166dbd3135.
Reason for revert: illegal is not advanced, docs
Original change's description:
> make enum santizer fatal
>
> This enum sanitizer checks that all the values of the enum we use fall
> within the range of the enumerated values.
>
> The main thing this helps point out is that the size of enum types in
> C++ need only be large enough to hold the largest declared value; larger
> values are undefined. In practice, most enums are implemented as ints
> for compatibility with C, so while this hasn't pointed out anything
> egregiously broken, the sanitizer has found a couple possibly dangerous
> situations in our codebase.
>
> For most types using values outside the enum range, we can just
> explicitly size them to int. This makes their de facto size de jure.
>
> But we need to actually make GrBlendEquation and GrBlendCoeff not store
> values outside their enumerated range. They're packed into bitfields
> that really can't represent those (negative) values. So for these I've
> added new kIllegal values to the enums, forcing us to deal with our
> once-silent illegal values a bit more explicitly.
>
> Change-Id: Ib617694cf1aaa83ae99289e9e760f49cb6393a2f
> Reviewed-on: https://skia-review.googlesource.com/c/168484
> Reviewed-by: Brian Osman <brianosman@google.com>
TBR=mtklein@chromium.org,mtklein@google.com,brianosman@google.com
Change-Id: I691c08092340a6273e442c0f098b844f7d0363ba
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/168581
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This enum sanitizer checks that all the values of the enum we use fall
within the range of the enumerated values.
The main thing this helps point out is that the size of enum types in
C++ need only be large enough to hold the largest declared value; larger
values are undefined. In practice, most enums are implemented as ints
for compatibility with C, so while this hasn't pointed out anything
egregiously broken, the sanitizer has found a couple possibly dangerous
situations in our codebase.
For most types using values outside the enum range, we can just
explicitly size them to int. This makes their de facto size de jure.
But we need to actually make GrBlendEquation and GrBlendCoeff not store
values outside their enumerated range. They're packed into bitfields
that really can't represent those (negative) values. So for these I've
added new kIllegal values to the enums, forcing us to deal with our
once-silent illegal values a bit more explicitly.
Change-Id: Ib617694cf1aaa83ae99289e9e760f49cb6393a2f
Reviewed-on: https://skia-review.googlesource.com/c/168484
Reviewed-by: Brian Osman <brianosman@google.com>
This is a reland of c766370d86
Original change's description:
> always optimize third_party code
>
> Change-Id: I5b2244460a4760e9336640f597d0f74c374a0d04
> Reviewed-on: https://skia-review.googlesource.com/155641
> Commit-Queue: Mike Klein <mtklein@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Auto-Submit: Mike Klein <mtklein@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I63e7f9ca852fc99728d7a01d9987b3506115d266
Reviewed-on: https://skia-review.googlesource.com/155760
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This reverts commit c766370d86.
Reason for revert: speculative -- trying to fix Debian breaks (pdf?)
Original change's description:
> always optimize third_party code
>
> Change-Id: I5b2244460a4760e9336640f597d0f74c374a0d04
> Reviewed-on: https://skia-review.googlesource.com/155641
> Commit-Queue: Mike Klein <mtklein@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Auto-Submit: Mike Klein <mtklein@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
TBR=mtklein@google.com,brianosman@google.com
Change-Id: I5467c95f9487c31e6f538f13579e490cdaeeee2e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/155607
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Change-Id: I5b2244460a4760e9336640f597d0f74c374a0d04
Reviewed-on: https://skia-review.googlesource.com/155641
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Without this, debug clang builds on windows have very little debug info.
Fix is based on Chromium's handling of this (they have several tactics,
depending on linker, etc...)
https://cs.chromium.org/chromium/src/build/config/compiler/BUILD.gn?l=2194
Change-Id: Ib1b3aa4cdf4e2daa762d994bea94dc3c691cf359
Reviewed-on: https://skia-review.googlesource.com/154540
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
People using is_official_build don't really want to see warnings.
They're for devs, not users.
The somewhat odd update to gn/BUILDCONFIG.gn keeps command
line flag precedence (later == more important) unchanged.
Change-Id: I1a04a35f066b7408021d474535f0dbf4928e21d3
Reviewed-on: https://skia-review.googlesource.com/151380
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
We're close enough that it's easier to use "undefined"
to turn on all supported UBSAN sanitizers and then
keep a couple in fyi_sanitizers as a blacklist.
I'm going to try to fix "enum" next too, so hopefully
that won't be in there too long.
I did a little flag cleanup too. -fno-omit-frame-pointer
was harmlessly in there twice for Android builds.
Change-Id: I8216fb0685423b2ff56db2e2be5bbeb4b48f932f
Reviewed-on: https://skia-review.googlesource.com/146760
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Change-Id: Ibfead1121f22277297e16196b37e6e86dc2d2166
Reviewed-on: https://skia-review.googlesource.com/146649
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This sanitizer checks for overaligned reads and writes,
or put another way, use of underaligned pointers.
This usually happens when you cast, e.g. char* to int*
without checking that the char* is 4-byte aligned. Each
of the changes under src/ fixes something just like that.
The unusual setup for tools/xsan.blacklist is there to
force a rebuild whenever tools/xsan.blacklist changes.
I spent a good few minutes debugging rebuilds not happening
this morning, perhaps from some strange ccache interaction.
Align SkTextBlobs as void* (today they're just 4-byte) so the
SkTextBlob::RunRecords we put after them in SkTextBlobBuilder
buffers are properly aligned (for the SkTypeface* inside).
There's no obvious error in void SkRRect::computeType(),
but one bot seems to have seen some sort of issue with
SK_AT_SCOPE_EXIT(SkASSERT(this->isValid()));
I can't reproduce it locally, so I'm just going to unroll it.
Change-Id: I904d94f65f695e1b626b684c32216a4930b72b0c
Reviewed-on: https://skia-review.googlesource.com/146104
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
build debug on linux for gdb
Building with this define enables additional
checks for standard library functions when
running gdb, and allows printing std::string.
R=halcanary@google.com
Bug: skia:
Change-Id: I7f2dc12336f9239443328f13264be7a6b285c4b5
Reviewed-on: https://skia-review.googlesource.com/140786
Commit-Queue: Cary Clark <caryclark@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-on: https://skia-review.googlesource.com/141083
Commit-Queue: Cary Clark <caryclark@skia.org>
This reverts commit 3c3db72e69.
Reason for revert: I suspect this is breaking the Build-Debian9-Clang-arm-Debug-Chromebook_GLES bot
Original change's description:
> build debug on linux for gdb
>
> Building with this define enables additional
> checks for standard library functions when
> running gdb, and allows printing std::string.
>
> R=halcanary@google.com
>
> Bug: skia:
> Change-Id: Ib71c179d8cbacbcd7f17a1c85f912072918e6be8
> Reviewed-on: https://skia-review.googlesource.com/140786
> Commit-Queue: Cary Clark <caryclark@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
TBR=mtklein@google.com,halcanary@google.com,caryclark@google.com
Change-Id: I56ae1c6c02032e6445f5585de51c48423d283636
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/140840
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Building with this define enables additional
checks for standard library functions when
running gdb, and allows printing std::string.
R=halcanary@google.com
Bug: skia:
Change-Id: Ib71c179d8cbacbcd7f17a1c85f912072918e6be8
Reviewed-on: https://skia-review.googlesource.com/140786
Commit-Queue: Cary Clark <caryclark@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Change-Id: I4bbf3e5e6d9d4e11e968a0bc88ce43444047a382
Reviewed-on: https://skia-review.googlesource.com/130903
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
I know SkRasterPipelineBlitter will add back offsets
to the mask pointer to make these fMaskPtr.pixels safe.
SkImageInfo wasn't making out-of-bounds pointers, but was moving
between two in-bounds pointers by subtracting large (negative)
size_t. Switching to explicit negate and add quiets this down.
Bug: chromium:836282
Change-Id: Ia65e380ec41dbfedce0659106830fbacb1a5cf4a
Reviewed-on: https://skia-review.googlesource.com/131147
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Bug: skia:
Change-Id: Ic5efe371b6365913a47d833c698958cc842d16ae
Reviewed-on: https://skia-review.googlesource.com/128685
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
We haven't done this in a while.
The only interesting change I've noticed so far is that we no longer
need to link libandroid_support when targeting API 21+.
Change-Id: I6506fbe7bd02534f1ea136f2164acab7f44c29e0
Reviewed-on: https://skia-review.googlesource.com/128009
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: I4a0259f82272099e08df0e7dea91489f6d641ca4
Reviewed-on: https://skia-review.googlesource.com/113670
Commit-Queue: Ben Wagner <benjaminwagner@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
The only tangible effect this CL should have is to use __vectorcall on
all Windows builds, including scalar ones. The code generation is a
little better there with __vectorcall than not, so might as well. This
is a baby step towards vector stages with MSVC, but a very baby step
indeed.
Mostly this refactors and regroups a bunch of logic to reflect my
current thoughts. The BUILD.gn changes are essentially no-ops, but they
simplify things and make our flags more similar to how those targets are
built in Chromium.
(And I cleaned up other /arch: uses so this works.)
Change-Id: I73dd39d15cdc7b3d268231a707952bbbfd91496e
Reviewed-on: https://skia-review.googlesource.com/115644
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This suppresses the noexcept-type warning, since Skia doesn't have a
stable ABI in any event. GCC now warns on more printf style formats,
so we have to hide our bad test formats a little better. GCC now
also warns on implicit enum to bool conversions, which did catch two
issues.
Change-Id: Ib81769c421757186506873f0fe298ecd0106ae87
Reviewed-on: https://skia-review.googlesource.com/114263
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Enable /arch:SSE2 for Win x86 builds (both MSVC and Clang).
Change-Id: I0618e938b6542b60fae3947b7e0dcde22650ba54
Reviewed-on: https://skia-review.googlesource.com/56721
Commit-Queue: Ben Wagner <benjaminwagner@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:7643
Change-Id: Ieeca5414f51c7c113c54b47578ec840fc7d684e0
Reviewed-on: https://skia-review.googlesource.com/109520
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Bug: skia:
Change-Id: I97bf83ca001acc762a42d26207a394faee6d90fb
Reviewed-on: https://skia-review.googlesource.com/107782
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Android+ASAN was already using libc++, so don't confuse it with the host
library.
Bug: skia:
Change-Id: Ibdeb40007f9d346a84adb39de240299049c0c55e
Reviewed-on: https://skia-review.googlesource.com/107721
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
