As much as it's tempting to use LLD for LTO, it still causes some
subtle problems with the build, and it's still better to keep using
BFD ld for the time being. Doing so requires the gold plugin, which
only requires to pass cmake the directory where the binutils headers
are, and they are part of the gcc toolchain headers.
Differential Revision: https://phabricator.services.mozilla.com/D4896
As much as it's tempting to use LLD for LTO, it still causes some
subtle problems with the build, and it's still better to keep using
BFD ld for the time being. Doing so requires the gold plugin, which
only requires to pass cmake the directory where the binutils headers
are, and they are part of the gcc toolchain headers.
Differential Revision: https://phabricator.services.mozilla.com/D4896
With patches from other bugs in place to use the right C compiler and cflags,
we can enable geckodriver on cross-compiles for macOS.
MozReview-Commit-ID: 5wqBiA6UCf
Back before expandlibs was removed in bug 1429875, not using list files
was supported, but nowadays, it just leads to errors like the following:
*** No rule to make target 'libfake_so.list', needed by 'libfake.so'. Stop.
We might as well error out during configure, rather than much later
during the build.
Differential Revision: https://phabricator.services.mozilla.com/D4738
All the Linux builds using GCC uses the binutils bundled with GCC. This
gives us some leeway to update the binutils used for clang builds (using
the binutils toolchain as of bug 1486998) separately.
Since we only ship builds using GCC, we're more free to upgrade
binutils for clang builds, without worrying about the next merge.
This upgrades to the last released version of binutils, and applies the
patch from https://sourceware.org/bugzilla/show_bug.cgi?id=23591 on top,
so that asan fuzzing builds don't fail.
The GPG key used to sign the upstream tarball is unfortunately not
connected to the web of trust. I verified the contents matched what's in
the Debian archive (which has a different tarball, because some files
are removed/modified in Debian for license reasons ; there were no
differences besides those).
Differential Revision: https://phabricator.services.mozilla.com/D4748
--HG--
extra : moz-landing-system : lando
Last time it was updated is bug 1436208, and the crashes we patched it
for back then has been fixed upstream a few months later.
For some reason, they renamed the executable from llvm-dsymutil to
dsymutil.
Differential Revision: https://phabricator.services.mozilla.com/D4741
--HG--
extra : moz-landing-system : lando
Those mozconfigs do things in common that are already in
mozconfig.linux. Let's just use that.
This will make the build have the binutils toolchain in PATH rather than
passing it to CC/CXX, which is better because it also makes the build
use tools such as ar, ranlib, objcopy from the binutils toolchain,
rather than the old system ones.
Differential Revision: https://phabricator.services.mozilla.com/D4649
Back before expandlibs was removed in bug 1429875, not using list files
was supported, but nowadays, it just leads to errors like the following:
*** No rule to make target 'libfake_so.list', needed by 'libfake.so'. Stop.
We might as well error out during configure, rather than much later
during the build.
Differential Revision: https://phabricator.services.mozilla.com/D4738
Those mozconfigs do things in common that are already in
mozconfig.linux. Let's just use that.
This will make the build have the binutils toolchain in PATH rather than
passing it to CC/CXX, which is better because it also makes the build
use tools such as ar, ranlib, objcopy from the binutils toolchain,
rather than the old system ones.
Differential Revision: https://phabricator.services.mozilla.com/D4649
The x86 linux builds originally were performed in x86 build environment.
That was a long time ago. Since then, they moved to x86-64 hosts with
x86 headers and libraries. But for reasons that might have to do with
the build system not really supporting cross-compilation nicely back
then, the build is still explicitly passing both --host and --target,
making those builds non-cross builds.
Since the toolchains used to build are for x86-64, the fact that --host
is for x86 actually prevents enabling the clang plugin, so we need to
turn these builds in actual cross builds if we want to enable the clang
plugin.
The x86 linux builds originally were performed in x86 build environment.
That was a long time ago. Since then, they moved to x86-64 hosts with
x86 headers and libraries. But for reasons that might have to do with
the build system not really supporting cross-compilation nicely back
then, the build is still explicitly passing both --host and --target,
making those builds non-cross builds.
Since the toolchains used to build are for x86-64, the fact that --host
is for x86 actually prevents enabling the clang plugin, so we need to
turn these builds in actual cross builds if we want to enable the clang
plugin.
This setup seems to work well enough to enable me to link
HOST_SIMPLE_PROGRAMS with an AArch64-cross setup. Necessary library
paths are passed to the linker via -LIBPATH and HOST_LDFLAGS rather than
letting MSVC fish them out of the environment. The change to
HOST_SIMPLE_PROGRAMS to pass HOST_LDFLAGS was necessary for this to
work, in addition to the HOST_LINKER changes.
-Wtautological-overlap-compare is an opt-in warning added in clang 3.5. It warns about overlapping comparisons that are always true or false, such as:
if (x > 4 || x < 10) {} // warning! always true
int b = x < 2 && x > 5; // warning! always false
return x > 4 || x < 10; // warning! always true
https://clang.llvm.org/docs/DiagnosticsReference.html#wtautological-overlap-compare
There are currently no -Wtautological-overlap-compare warnings in mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D3477
--HG--
extra : rebase_source : e6aa211a338633e5fb7507b3a8f341709d72d6c9
This opt-in warning catches bugs where a constructor modifies a constructor parameter that shadows member variable name. The code probably intended to change the member variable value, not the paramter. There are currently no -Wshadow-field-in-constructor warnings in mozilla-central.
https://clang.llvm.org/docs/DiagnosticsReference.html#wshadow-field-in-constructor-modified
Differential Revision: https://phabricator.services.mozilla.com/D3822
--HG--
extra : rebase_source : 604ff90e036d536955db41351ee9ee97e8424d92
extra : intermediate-source : 712f538afc160f4efae2383130727edbd1dd70f6
extra : source : 300fff9a58515c7cac0647afc9ccc0e69bc8c5cb
-Wfloat-overflow-conversion detects when a constant floating point value is converted to an integer type and will overflow the target type.
https://clang.llvm.org/docs/DiagnosticsReference.html#wfloat-overflow-conversion
-Wfloat-zero-conversion detects when a non-zero floating point value is converted to a zero integer value.
https://clang.llvm.org/docs/DiagnosticsReference.html#wfloat-zero-conversion
There are currently no -Wfloat-overlap-conversion warnings in mozilla-central. There is one -Wfloat-zero-conversion warning in a webrtc test. It doesn't block enabling this check because the webrtc tests are not compiled with warnings-as-errors.
media/webrtc/trunk/webrtc/modules/audio_coding/audio_network_adaptor/frame_length_controller_unittest.cc:255:54 [-Wfloat-zero-conversion] implicit conversion from 'const float' to 'int' changes non-zero value from 0.045000002 to 0
We can't enable all -Wfloat-conversion warnings (for any implicit conversion of a floating-point number into an integer) because there are currently over 1400 warnings. I spot checked a few of these -Wfloat-conversion warnings. I didn't find any obvious bugs, but there is some suspicious code, such as implicit conversions of floats to bools.
Differential Revision: https://phabricator.services.mozilla.com/D3476
--HG--
extra : rebase_source : 589be9e593749c7000b1f89ca155e4f95a487f8f
Mike Hommey
Ted Mielczarek
Hiroyuki Ikezoe
Cosmin Sabou
Ciure Andrei
Sebastian Hengst
ui.manish
Coroiu Cristina
Gurzau Raul
Myk Melez
Landry Breuil
Dorel Luca
arthur.iakab
Andi-Bogdan Postelnicu
Nathan Froyd
Chris Peterson