BMC/Intel-BMC/linux.git/arch/arc/Makefile, branch dev-4.6

ARC: build: Turn off -Wmaybe-uninitialized for ARC gcc 4.8

2016-03-18T10:52:36+00:00

linux-next has been reporting gazillion warnings for ARC build and I finally decided to take a bite: http://kisskb.ellerman.id.au/kisskb/buildresult/12638735/ Most of the them are due to -Wmaybe-uninitialized | ../kernel/sysctl.c: In function '__do_proc_doulongvec_minmax': | ../kernel/sysctl.c:1928:12: warning: 'p' may be used uninitialized in this function [-Wmaybe-uninitialized] | ret = tmp - *buf; | ^ | ../kernel/sysctl.c:2342:29: note: 'p' was declared here | char *kbuf = NULL, *p; | ^ | ... | ... Cursory look at code seemed fine and a definite gcc false positive in say kernel/sysctl.c Mystery was why only for ARC (and not with ARM linaro toolchain based off same gcc 4.8). Turns out that -O3 (default for ARC) triggers these and if I enable -O3 for ARM kernel build, I see the same splat. I initially wanted to disable this only for gcc 4.8, but Arnd reported it is seen even on gcc 6.0 for ARM with -O3. Thus better to disable this independent of gcc version. Cc: Claudiu Zissulescu Cc: Arnd Bergmann Cc: Michal Marek Cc: Geert Uytterhoeven Cc: linux-kbuild@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Vineet Gupta

ARC: build: Better way to detect ISA compatible toolchain

2016-03-12T06:28:30+00:00

ARC architecture has 2 instruction sets: ARCompact/ARCv2. While same gcc supports compiling for either (using appropriate toggles), we can't use the same toolchain to build kernel because libgcc needs to be unique and the toolchian (uClibc based) is not multilibed. uClibc toolchain is convenient since it allows all userspace and kernel to be built with a single install for an ISA. This however means 2 gnu installs (with same triplet prefix) are needed for building for 2 ISA and need to be in PATH. As developers we keep switching the builds, but would occassionally fail to update the PATH leading to usage of wrong tools. And this would only show up at the end of kernel build when linking incompatible libgcc. So the initial solution was to have gcc define a special preprocessor macro DEFAULT_CPU_xxx which is unique for default toolchain configuration. Claudiu proposed using grep for an existing preprocessor macro which is again uniquely defined per ISA. Cc: Michal Marek Suggested-by: Claudiu Zissulescu Signed-off-by: Vineet Gupta

ARC: [BE] Select correct CROSS_COMPILE prefix

2016-03-11T09:29:54+00:00

This allows CONFIG_CPU_BIG_ENDIAN=y to build correctly out of the box, w/o any other tweaks. Cc: Noam Camus Cc: Alexey Brodkin Cc: Anton Kolesov Signed-off-by: Vineet Gupta

ARC: Assume multiplier is always present

2016-02-18T12:00:03+00:00

It is unlikely that designs running Linux will not have multiplier. Further the current support is not complete as tool don't generate a multilib w/o multiplier. Signed-off-by: Vineet Gupta

ARC: Fix linking errors with CONFIG_MODULE + CONFIG_CC_OPTIMIZE_FOR_SIZE

2015-12-21T07:31:19+00:00

At -Os, ARC gcc generates millicode thunk for function prologue/epilogue, which are served by libgcc. Modules historically are NOT linked with libgcc to avoid code bloat, reducing runtime relocation fixups etc. I even once tried doing that but got lost in makefile intricacies. This means modules at -Os don't get the millicode thunks, causing build failures below: | MODPOST 5 modules | ERROR: "__ld_r13_to_r18" [crypto/sha256_generic.ko] undefined! | ERROR: "__ld_r13_to_r18_ret" [crypto/sha256_generic.ko] undefined! | ERROR: "__st_r13_to_r18" [crypto/sha256_generic.ko] undefined! | ERROR: "__ld_r13_to_r17_ret" [crypto/sha256_generic.ko] undefined! | ERROR: "__st_r13_to_r17" [crypto/sha256_generic.ko] undefined! | ERROR: "__ld_r13_to_r16_ret" [crypto/sha256_generic.ko] undefined! | ERROR: "__st_r13_to_r16" [crypto/sha256_generic.ko] undefined! |.... |.... Workaround that by inhibiting millicode thunks for loadable modules Fixes STAR 9000641864: ("Linux built with optimizations for size emits errors for modules") Reported-by: Anton Kolesov Cc: Michal Marek Cc: linux-kernel@vger.kernel.org Signed-off-by: Vineet Gupta

arc: use common make variables for dtb builds

2015-10-27T21:12:13+00:00

Use dtb-y and always make variables to build dtbs instead of explicit dtbs rule. This is in preparation to support building all dtbs. Signed-off-by: Rob Herring Acked-by: Vineet Gupta

ARCv2: add knob for DIV_REV in Kconfig

2015-07-20T10:33:30+00:00

Being highly configurable core ARC HS among other features might be configured with or without DIV_REM_OPTION (hardware divider). That option when enabled adds following instructions: div, divu, rem, remu. By default ARC HS38 has this option enabled. So we add here possibility to disable usage of hardware divider by compiler. Signed-off-by: Alexey Brodkin Signed-off-by: Vineet Gupta

ARC: Override toplevel default -O2 with -O3

2015-07-06T05:39:00+00:00

ARC kernels have historically been built with -O3, despite top level Makefile defaulting to -O2. This was facilitated by implicitly ordering of arch makefile include AFTER top level assigned -O2. An upstream fix to top level a1c48bb160f ("Makefile: Fix unrecognized cross-compiler command line options") changed the ordering, making ARC -O3 defunct. Fix that by NOT relying on any ordering whatsoever and use the proper arch override facility now present in kbuild (ARCH_*FLAGS) Depends-on: ("kbuild: Allow arch Makefiles to override {cpp,ld,c}flags") Suggested-by: Michal Marek Cc: Geert Uytterhoeven Cc: stable@vger.kernel.org # 3.16+ Signed-off-by: Vineet Gupta

ARC: Fix build failures for ARCompact in linux-next after ARCv2 support

2015-06-28T15:00:13+00:00

Reported-by: Guenter Roeck Signed-off-by: Vineet Gupta

ARCv2: Allow older gcc to cope with new regime of ARCv2/ARCompact support

2015-06-28T14:17:22+00:00

-no-ll64 is specific to ARCv2 ISA, and is obviously not supported by older ARC gcc - in this case the one hosted by linux-next sanity build service. Ensure that it doesn't get included for ISA_ARCOMPACT Reported-by: Guenter Roeck Signed-off-by: Vineet Gupta