summaryrefslogtreecommitdiffstats
path: root/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* Linux 4.19.151v4.19.151Greg Kroah-Hartman2020-10-141-1/+1
| | | | | | | | | | Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Pavel Machek (CIP) <pavel@denx.de> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20201012132629.469542486@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.150v4.19.150Greg Kroah-Hartman2020-10-071-1/+1
| | | | | | | | | Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20201005142108.650363140@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.149v4.19.149Greg Kroah-Hartman2020-10-011-1/+1
| | | | | | | | Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Link: https://lore.kernel.org/r/20200929142826.951084251@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.148v4.19.148Greg Kroah-Hartman2020-09-261-1/+1
| | | | | | | | | | Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20200925124720.972208530@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: support LLVM=1 to switch the default tools to Clang/LLVMMasahiro Yamada2020-09-261-6/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit a0d1c951ef08ed24f35129267e3595d86f57f5d3 upstream. As Documentation/kbuild/llvm.rst implies, building the kernel with a full set of LLVM tools gets very verbose and unwieldy. Provide a single switch LLVM=1 to use Clang and LLVM tools instead of GCC and Binutils. You can pass it from the command line or as an environment variable. Please note LLVM=1 does not turn on the integrated assembler. You need to pass LLVM_IAS=1 to use it. When the upstream kernel is ready for the integrated assembler, I think we can make it default. We discussed what we need, and we agreed to go with a simple boolean flag that switches both target and host tools: https://lkml.org/lkml/2020/3/28/494 https://lkml.org/lkml/2020/4/3/43 Some items discussed, but not adopted: - LLVM_DIR When multiple versions of LLVM are installed, I just thought supporting LLVM_DIR=/path/to/my/llvm/bin/ might be useful. CC = $(LLVM_DIR)clang LD = $(LLVM_DIR)ld.lld ... However, we can handle this by modifying PATH. So, we decided to not do this. - LLVM_SUFFIX Some distributions (e.g. Debian) package specific versions of LLVM with naming conventions that use the version as a suffix. CC = clang$(LLVM_SUFFIX) LD = ld.lld(LLVM_SUFFIX) ... will allow a user to pass LLVM_SUFFIX=-11 to use clang-11 etc., but the suffixed versions in /usr/bin/ are symlinks to binaries in /usr/lib/llvm-#/bin/, so this can also be handled by PATH. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> # build Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] [nd: hunk against Documentation/kbuild/kbuild.rst dropped due to not backporting commit cd238effefa2 ("docs: kbuild: convert docs to ReST and rename to *.rst")] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: replace AS=clang with LLVM_IAS=1Masahiro Yamada2020-09-261-0/+2
| | | | | | | | | | | | | | | | | | commit 7e20e47c70f810d678d02941fa3c671209c4ca97 upstream. The 'AS' variable is unused for building the kernel. Only the remaining usage is to turn on the integrated assembler. A boolean flag is a better fit for this purpose. AS=clang was added for experts. So, I replaced it with LLVM_IAS=1, breaking the backward compatibility. Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: remove AS variableMasahiro Yamada2020-09-261-2/+1
| | | | | | | | | | | | | | | | | | | | | | commit aa824e0c962b532d5073cbb41b2efcd6f5e72bae upstream. As commit 5ef872636ca7 ("kbuild: get rid of misleading $(AS) from documents") noted, we rarely use $(AS) directly in the kernel build. Now that the only/last user of $(AS) in drivers/net/wan/Makefile was converted to $(CC), $(AS) is no longer used in the build process. You can still pass in AS=clang, which is just a switch to turn on the LLVM integrated assembler. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* x86/boot: kbuild: allow readelf executable to be specifiedDmitry Golovin2020-09-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | commit eefb8c124fd969e9a174ff2bedff86aa305a7438 upstream. Introduce a new READELF variable to top-level Makefile, so the name of readelf binary can be specified. Before this change the name of the binary was hardcoded to "$(CROSS_COMPILE)readelf" which might not be present for every toolchain. This allows to build with LLVM Object Reader by using make parameter READELF=llvm-readelf. Link: https://github.com/ClangBuiltLinux/linux/issues/771 Signed-off-by: Dmitry Golovin <dima@golovin.in> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: add OBJSIZE variable for the size toolVasily Gorbik2020-09-261-1/+2
| | | | | | | | | | | | | | | | | | commit 7bac98707f65b93bf994ef4e99b1eb9e7dbb9c32 upstream. Define and export OBJSIZE variable for "size" tool from binutils to be used in architecture specific Makefiles (naming the variable just "SIZE" would be too risky). In particular this tool is useful to perform checks that early boot code is not using bss section (which might have not been zeroed yet or intersects with initrd or other files boot loader might have put right after the linux kernel). Link: http://lkml.kernel.org/r/patch-1.thread-2257a1.git-188f5a3d81d5.your-ad-here.call-01565088755-ext-5120@work.hours Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.147v4.19.147Greg Kroah-Hartman2020-09-231-1/+1
| | | | | | | | Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/lkml/20200921162034.660953761@linuxfoundation.org/ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.146v4.19.146Greg Kroah-Hartman2020-09-171-1/+1
| | | | | | | | Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.145v4.19.145Greg Kroah-Hartman2020-09-121-1/+1
| | | | | | | | Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.144v4.19.144Greg Kroah-Hartman2020-09-091-1/+1
| | | | | | | | Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.143v4.19.143Greg Kroah-Hartman2020-09-031-1/+1
| | | | | | | Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.142v4.19.142Greg Kroah-Hartman2020-08-261-1/+1
| | | | | | Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.141v4.19.141Greg Kroah-Hartman2020-08-211-1/+1
| | | | | | Tested-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.140v4.19.140Greg Kroah-Hartman2020-08-191-1/+1
| | | | | Tested-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.139v4.19.139Greg Kroah-Hartman2020-08-111-1/+1
| | | | | Tested-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.138v4.19.138Greg Kroah-Hartman2020-08-071-1/+1
| | | | | Tested-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.137v4.19.137Greg Kroah-Hartman2020-08-051-1/+1
| | | | | Tested-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.136v4.19.136Greg Kroah-Hartman2020-07-311-1/+1
| | | | Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.135v4.19.135Greg Kroah-Hartman2020-07-291-1/+1
| | | | | Tested-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang cross compilationFangrui Song2020-07-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ca9b31f6bb9c6aa9b4e5f0792f39a97bbffb8c51 upstream. When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if $(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-elfedit, GCC_TOOLCHAIN_DIR will be set to /usr/bin/. --prefix= will be set to /usr/bin/ and Clang as of 11 will search for both $(prefix)aarch64-linux-gnu-$needle and $(prefix)$needle. GCC searchs for $(prefix)aarch64-linux-gnu/$version/$needle, $(prefix)aarch64-linux-gnu/$needle and $(prefix)$needle. In practice, $(prefix)aarch64-linux-gnu/$needle rarely contains executables. To better model how GCC's -B/--prefix takes in effect in practice, newer Clang (since https://github.com/llvm/llvm-project/commit/3452a0d8c17f7166f479706b293caf6ac76ffd90) only searches for $(prefix)$needle. Currently it will find /usr/bin/as instead of /usr/bin/aarch64-linux-gnu-as. Set --prefix= to $(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) (/usr/bin/aarch64-linux-gnu-) so that newer Clang can find the appropriate cross compiling GNU as (when -no-integrated-as is in effect). Cc: stable@vger.kernel.org Reported-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Fangrui Song <maskray@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://github.com/ClangBuiltLinux/linux/issues/1099 Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.134v4.19.134Greg Kroah-Hartman2020-07-221-1/+1
|
* Linux 4.19.133v4.19.133Greg Kroah-Hartman2020-07-161-1/+1
|
* Linux 4.19.132v4.19.132Greg Kroah-Hartman2020-07-091-1/+1
|
* Linux 4.19.131v4.19.131Sasha Levin2020-06-301-1/+1
| | | | Signed-off-by: Sasha Levin <sashal@kernel.org>
* Linux 4.19.130v4.19.130Greg Kroah-Hartman2020-06-251-1/+1
|
* Linux 4.19.129v4.19.129Greg Kroah-Hartman2020-06-221-1/+1
|
* kbuild: force to build vmlinux if CONFIG_MODVERSION=yMasahiro Yamada2020-06-221-5/+8
| | | | | | | | | | | | | | | | | | | commit 4b50c8c4eaf06a825d1c005c0b1b4a8307087b83 upstream. This code does not work as stated in the comment. $(CONFIG_MODVERSIONS) is always empty because it is expanded before include/config/auto.conf is included. Hence, 'make modules' with CONFIG_MODVERSION=y cannot record the version CRCs. This has been broken since 2003, commit ("kbuild: Enable modules to be build using the "make dir/" syntax"). [1] [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=15c6240cdc44bbeef3c4797ec860f9765ef4f1a7 Cc: linux-stable <stable@vger.kernel.org> # v2.5.71+ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.128v4.19.128Greg Kroah-Hartman2020-06-101-1/+1
|
* Linux 4.19.127v4.19.127Greg Kroah-Hartman2020-06-071-1/+1
|
* Linux 4.19.126v4.19.126Greg Kroah-Hartman2020-06-031-1/+1
|
* Linux 4.19.125v4.19.125Greg Kroah-Hartman2020-05-271-1/+1
|
* Linux 4.19.124v4.19.124Greg Kroah-Hartman2020-05-201-1/+1
|
* Makefile: disallow data races on gcc-10 as wellSergei Trofimovich2020-05-201-0/+1
| | | | | | | | | | | | | | | | commit b1112139a103b4b1101d0d2d72931f2d33d8c978 upstream. gcc-10 will rename --param=allow-store-data-races=0 to -fno-allow-store-data-races. The flag change happened at https://gcc.gnu.org/PR92046. Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> Acked-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Cc: Thomas Backlund <tmb@mageia.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* gcc-10: disable 'restrict' warning for nowLinus Torvalds2020-05-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit adc71920969870dfa54e8f40dac8616284832d02 upstream. gcc-10 now warns about passing aliasing pointers to functions that take restricted pointers. That's actually a great warning, and if we ever start using 'restrict' in the kernel, it might be quite useful. But right now we don't, and it turns out that the only thing this warns about is an idiom where we have declared a few functions to be "printf-like" (which seems to make gcc pick up the restricted pointer thing), and then we print to the same buffer that we also use as an input. And people do that as an odd concatenation pattern, with code like this: #define sysfs_show_gen_prop(buffer, fmt, ...) \ snprintf(buffer, PAGE_SIZE, "%s"fmt, buffer, __VA_ARGS__) where we have 'buffer' as both the destination of the final result, and as the initial argument. Yes, it's a bit questionable. And outside of the kernel, people do have standard declarations like int snprintf( char *restrict buffer, size_t bufsz, const char *restrict format, ... ); where that output buffer is marked as a restrict pointer that cannot alias with any other arguments. But in the context of the kernel, that 'use snprintf() to concatenate to the end result' does work, and the pattern shows up in multiple places. And we have not marked our own version of snprintf() as taking restrict pointers, so the warning is incorrect for now, and gcc picks it up on its own. If we do start using 'restrict' in the kernel (and it might be a good idea if people find places where it matters), we'll need to figure out how to avoid this issue for snprintf and friends. But in the meantime, this warning is not useful. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* gcc-10: disable 'stringop-overflow' warning for nowLinus Torvalds2020-05-201-0/+1
| | | | | | | | | | | | | | commit 5a76021c2eff7fcf2f0918a08fd8a37ce7922921 upstream. This is the final array bounds warning removal for gcc-10 for now. Again, the warning is good, and we should re-enable all these warnings when we have converted all the legacy array declaration cases to flexible arrays. But in the meantime, it's just noise. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* gcc-10: disable 'array-bounds' warning for nowLinus Torvalds2020-05-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 44720996e2d79e47d508b0abe99b931a726a3197 upstream. This is another fine warning, related to the 'zero-length-bounds' one, but hitting the same historical code in the kernel. Because C didn't historically support flexible array members, we have code that instead uses a one-sized array, the same way we have cases of zero-sized arrays. The one-sized arrays come from either not wanting to use the gcc zero-sized array extension, or from a slight convenience-feature, where particularly for strings, the size of the structure now includes the allocation for the final NUL character. So with a "char name[1];" at the end of a structure, you can do things like v = my_malloc(sizeof(struct vendor) + strlen(name)); and avoid the "+1" for the terminator. Yes, the modern way to do that is with a flexible array, and using 'offsetof()' instead of 'sizeof()', and adding the "+1" by hand. That also technically gets the size "more correct" in that it avoids any alignment (and thus padding) issues, but this is another long-term cleanup thing that will not happen for 5.7. So disable the warning for now, even though it's potentially quite useful. Having a slew of warnings that then hide more urgent new issues is not an improvement. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* gcc-10: disable 'zero-length-bounds' warning for nowLinus Torvalds2020-05-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | commit 5c45de21a2223fe46cf9488c99a7fbcf01527670 upstream. This is a fine warning, but we still have a number of zero-length arrays in the kernel that come from the traditional gcc extension. Yes, they are getting converted to flexible arrays, but in the meantime the gcc-10 warning about zero-length bounds is very verbose, and is hiding other issues. I missed one actual build failure because it was hidden among hundreds of lines of warning. Thankfully I caught it on the second go before pushing things out, but it convinced me that I really need to disable the new warnings for now. We'll hopefully be all done with our conversion to flexible arrays in the not too distant future, and we can then re-enable this warning. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Stop the ad-hoc games with -Wno-maybe-initializedLinus Torvalds2020-05-201-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 78a5255ffb6a1af189a83e493d916ba1c54d8c75 upstream. We have some rather random rules about when we accept the "maybe-initialized" warnings, and when we don't. For example, we consider it unreliable for gcc versions < 4.9, but also if -O3 is enabled, or if optimizing for size. And then various kernel config options disabled it, because they know that they trigger that warning by confusing gcc sufficiently (ie PROFILE_ALL_BRANCHES). And now gcc-10 seems to be introducing a lot of those warnings too, so it falls under the same heading as 4.9 did. At the same time, we have a very straightforward way to _enable_ that warning when wanted: use "W=2" to enable more warnings. So stop playing these ad-hoc games, and just disable that warning by default, with the known and straight-forward "if you want to work on the extra compiler warnings, use W=123". Would it be great to have code that is always so obvious that it never confuses the compiler whether a variable is used initialized or not? Yes, it would. In a perfect world, the compilers would be smarter, and our source code would be simpler. That's currently not the world we live in, though. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: compute false-positive -Wmaybe-uninitialized cases in KconfigMasahiro Yamada2020-05-201-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | commit b303c6df80c9f8f13785aa83a0471fca7e38b24d upstream. Since -Wmaybe-uninitialized was introduced by GCC 4.7, we have patched various false positives: - commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized when building with -Os") turned off this option for -Os. - commit 815eb71e7149 ("Kbuild: disable 'maybe-uninitialized' warning for CONFIG_PROFILE_ALL_BRANCHES") turned off this option for CONFIG_PROFILE_ALL_BRANCHES - commit a76bcf557ef4 ("Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"") turned off this option for GCC < 4.9 Arnd provided more explanation in https://lkml.org/lkml/2017/3/14/903 I think this looks better by shifting the logic from Makefile to Kconfig. Link: https://github.com/ClangBuiltLinux/linux/issues/350 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Linux 4.19.123v4.19.123Greg Kroah-Hartman2020-05-141-1/+1
|
* Linux 4.19.122v4.19.122Greg Kroah-Hartman2020-05-101-1/+1
|
* Linux 4.19.121v4.19.121Greg Kroah-Hartman2020-05-061-1/+1
|
* Linux 4.19.120v4.19.120Greg Kroah-Hartman2020-05-021-1/+1
|
* Linux 4.19.119v4.19.119Greg Kroah-Hartman2020-04-291-1/+1
|
* Linux 4.19.118v4.19.118Greg Kroah-Hartman2020-04-231-1/+1
|
* Linux 4.19.117v4.19.117Greg Kroah-Hartman2020-04-211-1/+1
|
* Linux 4.19.116v4.19.116Greg Kroah-Hartman2020-04-171-1/+1
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-23 13:43:53 +0000