The conversion was done with c2rust and then manually cleaned up some.
There's still lots of unsafe code remaining but I'd rather do the rest
of the cleanup in-tree so that it's easier to catch and revert
regressions.
I've dropped support for SSE1 (Firefox requires SSE2) and Altivec
(not wanting to deal with fixing Rust's Altivec support).
transform_neon.rs manually implements a bunch of intrinsics, this
can be fixed when we can depend on Rust 1.48.
The fuzz target is changed to a cargo-fuzz target.
Some of the gtests are moved to Rust.
Differential Revision: https://phabricator.services.mozilla.com/D90782
Our performance gtests indicate anywhere from 10-20% reduction in
execution time based on the SSE2 version. Where it fell in the range
depended on the platform, but presumably that is related to the hardware
selected by treeherder. llvm-mca suggested it should be closer to 20%
on modern hardware (skylake).
Differential Revision: https://phabricator.services.mozilla.com/D55642
--HG--
extra : moz-landing-system : lando
Our performance gtests indicate anywhere from 10-20% reduction in
execution time based on the SSE2 version. Where it fell in the range
depended on the platform, but presumably that is related to the hardware
selected by treeherder. llvm-mca suggested it should be closer to 20%
on modern hardware (skylake).
Differential Revision: https://phabricator.services.mozilla.com/D55642
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
The deletions in xptcall are when we don't even have support for the CPU
in moz.configure, so I assume that people haven't been compiling on
those architectures for quite some time.
The current code is somewhat non-obvious to a first-time reader, and
OS_TEST is a bizarre thing anyway, since it's actually the name of the
CPU we're running on. We'd do well to minimize the use of OS_TEST.
Note that the complete nuking of the xptcall/md/unix/moz.build lines are
because we don't support OS X/x86 anymore.
Currently, the build scripts enable AltiVec unconditionally on all ppc*
targets. However, there some ppc* targets which do not support AltiVec
instruction set extensions, these are often embedded systems like the
PowerPC e500 or similar which have their own type of instruction set
extensions like SPE. Trying to enable Altivec support on these targets
results in a compiler error, hence we need to add an autoconf test for
AltiVec support before trying to enable it on ppc* targets.
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
--HG--
extra : rebase_source : 6c4df813d97d95046fd2269c876313ce7591c5cf
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
This patch fixes various warnings from MSVC.
- Several "truncation from 'double' to 'float'" warnings, easily fixed by
appending 'f' to literals.
- Some "signed/unsigned mismatch" warnings. In read_tag_lutType(), MSVC is
apparently promoting the multiplication of a uint8_t and a uint16_t to an
int32_t, oddly enough. A uint32_t cast fixes the warning.
- |offset| was unused in qcms_data_create_rbg_with_gamma().
- A couple of "overflow in floating-point constant arithmetic" warnings
involving INFINITY in transform_util.c. There is some type confusion here --
in C99 HUGE_VAL is a double and INFINITY is a float. So the HUGE_VAL here
should actualy be HUGE_VALF. But, strangely enough, that isn't enough to
avoid the warning, I don't know why. However, it turns out that any
non-positive value for |interval| will have the same effect, so I just
removed all the INFINITY/HUGE_VAL stuff and used -1 instead.
It also fixes an ARM-only GCC warning.
- "'__force_align_arg_pointer__' attribute directive ignored". This is an
x86-only attribute. Instead of disabling it on x86-64, instead enable it on
i386 (which avoids enabling it uselessly on ARM).
--HG--
extra : rebase_source : 61015b7e48aebd58035fc222abf076e79a99a972
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
What LIBXUL_LIBRARY does is:
- Imply FORCE_STATIC_LIB
- Build with -DIMPL_LIBXUL
- Build with -DMOZILLA_INTERNAL_API
Those intermediate libs that end up in gkmedias and have LIBXUL_LIBRARY defined
in their moz.build are all third party code (or handled like third party code).
Besides FORCE_STATIC_LIB, none of the side effects of LIBXUL_LIBRARY should be
needed.
Jeff Muizelaar
Andrew Osmond
Csoregi Natalia
Bogdan Tara
Narcis Beleuzu
Mike Hommey
Nathan Froyd
Thomas P.
Sylvestre Ledru
John Paul Adrian Glaubitz
Tom Tromey
Nicholas Nethercote
Benoit Girard
David Major
Ehsan Akhgari
Ms2ger
Brian O'Keefe
Mike Shal
Kyle Machulis
Gregory Szorc