The main changes are to the warnings, which are as follows.
- Kept -Wall.
- Part of -Wall or on by default; remove all mentions:
* -Waddress
* -Wchar-subscripts
* -Wcomment
* -Wconversion-null
* -Wendif-labels
* -Wenum-compare
* -Wimplicit-function-declaration
* -Wint-to-pointer-cast
* -Wmissing-braces
* -Wmultichar
* -Wnonnull
* -Wparentheses
* -Wpointer-sign
* -Wpointer-to-int-cast (C only)
* -Wreorder
* -Wreturn-type
* -Wsequence-point
* -Wsign-compare (C++ only)
* -Wswitch
* -Wtrigraphs
* -Wuninitialized
* -Wunknown-pragmas
* -Wunused-label
* -Wunused-value
* -Wwrite-strings (C++ only)
- Part of -Wextra; kept where present, added where missing:
* -Wempty-body
* -Wignored-qualifiers (not added for C++ code; many fixes needed to enable)
* -Wtype-limits
- Part of -pedantic; kept where present, added where missing:
* -pointer-arith
- C++ only, kept:
* -Wno-invalid-offsetof
* -Woverloaded-virtual
- Clang-only, kept:
* -Wnon-literal-null-conversion (affected by a clang bug; see the big comment
in the code)
* -Wrange-loop-analysis (C++ only)
* -Wno-unused-local-typedef
- This no longer exists? I kept it to be safe:
* -Winline-new-delete
A consequence of this is that, when --enable-warnings-as-errors is on, in
directories which have ALLOW_COMPILER_WARNINGS specified we no longer have any
fatal warnings. (We previously did have all the explicitly-mentioned
-Werror=foo ones.) This is a sensible change; if we are going to allow warnings
in a directory we should allow all of them, not just some of them.
Other changes:
- Some C warnings incorrectly used the CXX macros. Fixes that.
- Moves comments about warnings closer to the lines where they are defined, to
make it easier to keep the comments consistent with the code.
- Reorders things a little, e.g. so that all enabled warnings are before all
disabled warnings.
The C and C++ warnings are now very similar, in both configure.in and
js/src/configure.in.
--HG--
extra : rebase_source : 6f8db0fecda1315504a29fbcafb6fdee3053d8a5
Limit ourselves to include paths for now, because there are tricky things
involved in making this globally.
While here, use shell_quote instead of manual quoting for those paths.
This might seem like going in the opposite direction of what we tend to do
to move to moz.build land, but those flags are irrelevant in many situations
and are better separated out.
js/src/jit/BacktrackingAllocator.cpp:1039:13 [-Wclass-varargs] passing object of class type 'js::jit::CodePosition' through variadic function
js/src/jit/Safepoints.cpp:168:56 [-Wclass-varargs] passing object of class type 'js::jit::SafepointSlotEntry' through variadic function
js/src/jit/Safepoints.cpp:198:57 [-Wclass-varargs] passing object of class type 'js::jit::SafepointSlotEntry' through variadic function
The functions addSaturate() and subSaturate() are defined on the 8x16 and 16x8
integer SIMD types only.
Theee are no 32x4 variants defined in SIMD.js because current hardware doesn't
support it directly.
--HG--
extra : rebase_source : 876bd6ab47ccd007dd15d5b34948ebf33aca4f16
This is the right shift function that the SIMD.js spec requires. The old
shiftRightArithmeticByScalar() and shiftRightLogicalByScalar() functions will go
away.
These functions perform an arithmetic shift for signed types and a logical
shift for unsigned types.
Add support to Odin and Ion too, at least for the Int32x4 variant.
--HG--
extra : rebase_source : 7852f266a1ad505436c4c1607c17d542d81b2673
Fix a bug in ShiftRightArithmetic when the underlying Elem type is unsigned.
Need to cast to a signed type to so it sign-extends to int when shifting.
Implement both logical and arithmetic right shift implementations for both
signed and unsigned integers. This is needed to test our current implementation
where both signed and unsigned SIMD types have the two
shiftRightArithmeticByScalar() and shiftRightLogicalByScalar() functions.
Soon, shiftRightArithmeticByScalar() and shiftRightLogicalByScalar() will be
replaced by a single shiftRightByScalar() function whose behavior is dependent
on the signedness of the underlying type.
--HG--
extra : rebase_source : 00fa414d32592d8d923d2413a9d0f2082fb899d0
- Add new types UInt8x16, UInt16x8, UInt32x4 with all the boilerplate.
- Add corresponding conversion and bitcast functions to existing types.
- Add tests/ecma_7/SIMD tests for all new functions. Mostly boilerplate.
- Add full type coverage in ToSource.js. Fix existing SIMD types that were
broken.
- Use shared test vectors for all the 32x4 integer binary-op test cases.
- Fix a bug in the 32-bit multiplication reference implementation for Int32x4
and Uint32x4. A simple 'a*b' double multiplication loses precision to rounding
for some inputs.
--HG--
extra : rebase_source : 7268170538aae82766d661f3936657f368c6363f
The lists TypeDescriptorMethods and TypedObjectMethods are identical for all
SIMD types, so save a bit of memory and source code by sharing a single list.
--HG--
extra : rebase_source : 01f65e7eac8c8c99fb6c869206d75d2e5875002b
In the current SIMD.js spec, value conversions are only defined between types
with the same number of lanes:
Float32x4.fromInt32x4()
Float32x4.fromUInt32x4()
Int32x4.fromFloat32x4()
UInt32x4.fromFloat32x4()
Remove existing conversion operators between vectors with different numbers of
lanes:
Int32x4.fromFloat64x2()
Float32x4.fromFloat64x2()
Float64x2.fromInt32x4()
Float64x2.fromFloat32x4()
Add a static assertion to FuncConvert.
--HG--
extra : rebase_source : c7be47268c913134aa9b718000080e1d54a79f9f
clang-cl attempts to emulate MSVC's handling of __VA_ARGS__, but doesn't
quite get it right:
https://llvm.org/bugs/show_bug.cgi?id=25875
As a result of this, compiling files that #include MacroAssembler.h with
clang-cl result in fallbacks to MSVC. Since falling back to MSVC is
non-ideal (and also causes problems around things like linking function
template instantiations), let's disable MacroAssembler.h's macro magic
for the time being. Ideally, the problem will get fixed upstream
soon (even though it looks somewhat complicated); in the meantime,
fixing this issue lets forward progress be made when compiling Gecko
with clang-cl.
