The warning looks to helpfully pre-warn about possible link failures, but it's warning exclusively in places where we're doing things right.
The worst that happens ignoring this warning is a missing-symbol linker error.
I've taken the opportunity to batch in a few other de-escalations:
- Wconditional-uninitialized is done better by MSAN
- It'll take some work to dig Wformat-literal out of our shader compiler, but nothing looks unsafe
- Most of Wshift-sign-overflow is 0xff << 24. Don't want to ban that.
- Wdeprecated is mostly warning about features C++11 technically deprecated that might be removed in later releases. Punt!
- Wcovered-switch-default is pretty much the opposite of what we want.
- Wshadow is triggering too often to fix quickly. Probably mostly false positives.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2620
Change-Id: I20a85a77d2e19ed05a536b23037bd988350f821e
Reviewed-on: https://skia-review.googlesource.com/2620
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
It was not a fan of this (blatant) aliasing.
I suspect this best_non_simd_srcover_srgb_srgb() function has several
other aliasing issues that use undefined behavior, but this is all it's
complaining about for now.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2606
Change-Id: I25a8800e810bccf5068c8a10e9c8c8f565e57304
Reviewed-on: https://skia-review.googlesource.com/2606
Commit-Queue: Mike Klein <mtklein@chromium.org>
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Significantly reduces the diff between legacy and sRGB/F16 on about 25
GMs. This is just the biggest piece of low-hanging fruit. Many GMs create
N32 raster surfaces to procedurally generate source textures, and I'd like
to fix all of them. It's much easier to reason about the GMs (is sRGB
doing the right thing) when everything is tagged like this - the only
expected differences are due to filtering and blending.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2368933003
Review-Url: https://codereview.chromium.org/2368933003
This cleans up 3 remaining sites using , that probably meant ;
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2605
Change-Id: I5e48bcd85d72a205d2b0c860461dab1ec793dd18
Reviewed-on: https://skia-review.googlesource.com/2605
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Like the other change, it makes SkAlignN(x) macros work for pointers, and makes the macros themselves just syntax sugar for SkAlign<N>(x). We can still decide if we want to sed away the macros independently.
This just does it in a somewhat less repetitive way, and adds some tests.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2368293002
No public API changes.
TBR=reed@google.com
Review-Url: https://codereview.chromium.org/2368293002
Clang's got a warning -Wcomma that warns about possible unintentional uses of
the comma operator, usually where a semicolon looks itended.
I don't think there's a bug here, but a semicolon does work just as well
and reads a bit more conventionally. Though, I'm not actually sure how this
parses, as fp = ...; glslFP = ...; or fp = (..., glsl = ...). The second
would most definitely be a bug.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2365403002
NOTREECHECKS=true
Review-Url: https://codereview.chromium.org/2365403002
In one case the fuzzer was switching the picture's op code to an invalid value
In the other two the fuzzer was maxing out the number of points passed to drawPoints and the number of characters passed to drawTextRSXform. In these cases the validation would fail but still return a pointer into the data stream.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2593
Change-Id: Id6d4e6b7bcbae38ace7ad1d92ffcfa5c02f9fb61
Reviewed-on: https://skia-review.googlesource.com/2593
Reviewed-by: Mike Reed <reed@google.com>
This reverts commit I09c3487adfeb26a6fb07e1939cb927c5d7de3107.
Reason for revert: -Wover-aligned on x86 Android bots
Original issue's description:
> GN: detect is_clang, use it to switch Clang to warning blacklist.
>
> BUG=skia:
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2599
>
> Change-Id: I09c3487adfeb26a6fb07e1939cb927c5d7de3107
> Reviewed-on: https://skia-review.googlesource.com/2599
> Reviewed-by: Ben Wagner <bungeman@google.com>
> Commit-Queue: Mike Klein <mtklein@chromium.org>
>
TBR=mtklein@chromium.org,bungeman@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: Ic07bf7896a305be6c377f14a573cb10836f1a6f8
Reviewed-on: https://skia-review.googlesource.com/2601
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Angle's existing GN files only work in Chrome, so I've written a new one.
This won't work on Windows, but our GN build doesn't work on Windows anyway. So this CL is an attempt to get a ahead of that curve on ANGLE. It looks large but fairly straightforward.
Now working on Linux:
$ gn gen angle --args=skia_use_angle=true
$ ninja -C angle
$ angle/dm --config angle-gl --src gm -w dm-out
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2361983002
Review-Url: https://codereview.chromium.org/2361983002
properties (color space), bounds, and (optional) alphaType.
We were being pretty inconsistent before. Raster was honoring all
components of the info. GPU was using the supplied color type, but
propagating the source's color space. All call sites were saying N32.
What we want to do is propagate the original device's color space, and
pick a good format from that. Rather than force all the clients to
jump through hoops constructing an SkImageInfo that meets our criteria,
just have them supply the few bits we care about, and do everything else
internally.
This also lets us always use RGBA on GPU, but N32 on raster.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2349373004
Committed: https://skia.googlesource.com/skia/+/53c38087949252d27cde668368a3eeb59cc2eb00
Review-Url: https://codereview.chromium.org/2349373004
This comes from the Skia fuzzer where it is inverting the RRect's rect which causes trouble down the line.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2591
Change-Id: I5c34105a47369492d2df99d39a4e29116060ad37
Reviewed-on: https://skia-review.googlesource.com/2591
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This is now required to build our GPU testing tools.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2587
NOTREECHECKS=true
Change-Id: I219665fbe50e9bbea9abb88a6d63c34b76ca92e6
Reviewed-on: https://skia-review.googlesource.com/2587
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Reason for revert:
DM crash and/or TSAN failure
Original issue's description:
> Change SkSpecialImage::makeSurface and makeTightSurface to take output
> properties (color space), bounds, and (optional) alphaType.
>
> We were being pretty inconsistent before. Raster was honoring all
> components of the info. GPU was using the supplied color type, but
> propagating the source's color space. All call sites were saying N32.
>
> What we want to do is propagate the original device's color space, and
> pick a good format from that. Rather than force all the clients to
> jump through hoops constructing an SkImageInfo that meets our criteria,
> just have them supply the few bits we care about, and do everything else
> internally.
>
> This also lets us always use RGBA on GPU, but N32 on raster.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2349373004
>
> Committed: https://skia.googlesource.com/skia/+/53c38087949252d27cde668368a3eeb59cc2eb00TBR=robertphillips@google.com,reed@google.com,bsalomon@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review-Url: https://codereview.chromium.org/2366723004
Can be run like
gn gen out/debug --ide=json --json-ide-script=../../gn/gn_to_cmake.py
or
gn gen out/debug --ide=json
python gn/gn_to_cmake.py out/debug/project.json
This first pass creates CMakeLists.txt with just enough information for an
ide. Each target is just a static library with sources, include
directories, and defines.
NOTRY=true
This isn't automatically tested.
Review-Url: https://codereview.chromium.org/2363873002
properties (color space), bounds, and (optional) alphaType.
We were being pretty inconsistent before. Raster was honoring all
components of the info. GPU was using the supplied color type, but
propagating the source's color space. All call sites were saying N32.
What we want to do is propagate the original device's color space, and
pick a good format from that. Rather than force all the clients to
jump through hoops constructing an SkImageInfo that meets our criteria,
just have them supply the few bits we care about, and do everything else
internally.
This also lets us always use RGBA on GPU, but N32 on raster.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2349373004
Review-Url: https://codereview.chromium.org/2349373004
Net effect of the two calls is (basically) the same, but given that we're
propagating from isGammaCorrect on the DC, I figured it makes sense to use
the same-named API.
More importantly, a couple places had slipped through, so those draws would
ignore sRGB-ness of inputs entirely.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2357413004
Review-Url: https://codereview.chromium.org/2357413004
