Clang patches for 4.9

PATCH Nathan Chancellor 3 participants 8 messages Feb 25, 2019

Subsystems (2)

Stable branch Kbuild

lore

Share & tools

lore

Nathan Chancellor

author

2019-02-25 06:13 UTC #0 lore raw

Hi Greg and Sasha,

Attached are three mbox files containing patches that bring the Clang backports that Nick did in 4.9.139 up to date with what is currently in 4.14 and mainline, as well as fix warnings that are present in the arm64 and x86_64 defconfigs here and in AOSP (cuttlefish_defconfig). All of these warnings are fixed in 4.14 so there will be no regressions from upgrading.

They were tested with Arch Linux's GCC 8.2.1 and AOSP's clang-r349610 [1] and boot tested in QEMU 3.1.0 with our rootfs files [2].

Additionally, for Greg, I have provided a merge resolution for the Makefile conflict you will get when doing the android-4.9 merge. You will also get a conflict in arch/arm64/include/asm/arch_gicv3.h, just check out to MERGE_HEAD as the {read,write}_sysreg_s macros have the LTO workaround that causes the conflict in the first place. I tested this resolution by building and booting cuttlefish_defconfig for arm64 with CONFIG_LTO_CLANG and CONFIG_CFI_CLANG enabled.

[1]: https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/+/803bf398de492bb70560a2444d24491bc42b84ec/clang-r349610/
[2]: https://github.com/ClangBuiltLinux/continuous-integration/tree/8a288264aa71f59a1725d2946b0a40364aafcad7/images

Please let me know if there are any concerns or objections! Nathan

Makefile +28 ~~-32~~

index 1b3780acf7c6..e493143bfde1 100644
@@ -306,11 +306,6 @@ HOSTCXX      = g++
 HOSTCFLAGS   := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89
 HOSTCXXFLAGS = -O2
 
-ifeq ($(shell $(HOSTCC) -v 2>&1 | grep -c "clang version"), 1)
-HOSTCFLAGS  += -Wno-unused-value -Wno-unused-parameter \
-		-Wno-missing-field-initializers -fno-delete-null-pointer-checks
-endif
-
 # Decide whether to build built-in, modular, or both.
 # Normally, just do built-in.

@@ -513,40 +508,20 @@ endif
 ifeq ($(cc-name),clang)
 ifneq ($(CROSS_COMPILE),)
 CLANG_TRIPLE	?= $(CROSS_COMPILE)
-CLANG_TARGET	:= --target=$(notdir $(CLANG_TRIPLE:%-=%))
-ifeq ($(shell $(srctree)/scripts/clang-android.sh $(CC) $(CLANG_TARGET)), y)
+CLANG_FLAGS	:= --target=$(notdir $(CLANG_TRIPLE:%-=%))
+ifeq ($(shell $(srctree)/scripts/clang-android.sh $(CC) $(CLANG_FLAGS)), y)
 $(error "Clang with Android --target detected. Did you specify CLANG_TRIPLE?")
 endif
 GCC_TOOLCHAIN_DIR := $(dir $(shell which $(LD)))
-CLANG_PREFIX	:= --prefix=$(GCC_TOOLCHAIN_DIR)
+CLANG_FLAGS	+= --prefix=$(GCC_TOOLCHAIN_DIR)
 GCC_TOOLCHAIN	:= $(realpath $(GCC_TOOLCHAIN_DIR)/..)
 endif
 ifneq ($(GCC_TOOLCHAIN),)
-CLANG_GCC_TC	:= --gcc-toolchain=$(GCC_TOOLCHAIN)
+CLANG_FLAGS	+= --gcc-toolchain=$(GCC_TOOLCHAIN)
 endif
-KBUILD_CFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC) $(CLANG_PREFIX)
-KBUILD_AFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC) $(CLANG_PREFIX)
-KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
-KBUILD_CFLAGS += $(call cc-disable-warning, unused-variable)
-KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier)
-KBUILD_CFLAGS += $(call cc-disable-warning, gnu)
-KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
-KBUILD_CFLAGS += $(call cc-disable-warning, duplicate-decl-specifier)
-# Quiet clang warning: comparison of unsigned expression < 0 is always false
-KBUILD_CFLAGS += $(call cc-disable-warning, tautological-compare)
-# CLANG uses a _MergedGlobals as optimization, but this breaks modpost, as the
-# source of a reference will be _MergedGlobals and not on of the whitelisted names.
-# See modpost pattern 2
-KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,)
-KBUILD_CFLAGS += $(call cc-option, -fcatch-undefined-behavior)
-KBUILD_CFLAGS += $(call cc-option, -no-integrated-as)
-KBUILD_AFLAGS += $(call cc-option, -no-integrated-as)
-else
-
-# These warnings generated too much noise in a regular build.
-# Use make W=1 to enable them (see scripts/Makefile.build)
-KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
-KBUILD_CFLAGS += $(call cc-disable-warning, unused-const-variable)
+CLANG_FLAGS	+= -no-integrated-as
+KBUILD_CFLAGS	+= $(CLANG_FLAGS)
+KBUILD_AFLAGS	+= $(CLANG_FLAGS)
 endif

@@ -806,6 +781,27 @@ ifdef CONFIG_CC_STACKPROTECTOR
 endif
 KBUILD_CFLAGS += $(stackp-flag)
 
+ifeq ($(cc-name),clang)
+KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
+KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier)
+KBUILD_CFLAGS += $(call cc-disable-warning, gnu)
+KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
+KBUILD_CFLAGS += $(call cc-disable-warning, duplicate-decl-specifier)
+# Quiet clang warning: comparison of unsigned expression < 0 is always false
+KBUILD_CFLAGS += $(call cc-disable-warning, tautological-compare)
+# CLANG uses a _MergedGlobals as optimization, but this breaks modpost, as the
+# source of a reference will be _MergedGlobals and not on of the whitelisted names.
+# See modpost pattern 2
+KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,)
+KBUILD_CFLAGS += $(call cc-option, -fcatch-undefined-behavior)
+else
+
+# These warnings generated too much noise in a regular build.
+# Use make W=1 to enable them (see scripts/Makefile.extrawarn)
+KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
+endif
+
+KBUILD_CFLAGS += $(call cc-disable-warning, unused-const-variable)
 ifdef CONFIG_FRAME_POINTER
 KBUILD_CFLAGS	+= -fno-omit-frame-pointer -fno-optimize-sibling-calls
 else

Greg Kroah-Hartman

maintainer

2019-02-25 14:45 UTC #1 lore raw

Quoted 8 lines · Nathan Chancellor

Hi Greg and Sasha,
Attached are three mbox files containing patches that bring the Clang backports that Nick did in 4.9.139 up to date with what is currently in 4.14 and mainline, as well as fix warnings that are present in the arm64 and x86_64 defconfigs here and in AOSP (cuttlefish_defconfig). All of these warnings are fixed in 4.14 so there will be no regressions from upgrading.

Really? I see a number of these only showing up in much newer kernels. Specifically these patches:
1f60652dd586 ("pinctrl: max77620: Use define directive for max77620_pinconf_param values") a0dd6773038f ("phy: tegra: remove redundant self assignment of 'map'") a9903f04e0a4 ("sched/sysctl: Fix attributes of some extern declarations")

from the "arm" mbox you provided. Why shouldn't the above patches go into 4.14.y and in some cases, also 4.19.y and 4.20.y?

thanks,

greg k-h

Greg Kroah-Hartman

maintainer

2019-02-25 14:47 UTC #2 lore raw

Quoted 10 lines · Greg Kroah-Hartman

Quoted 8 lines · Nathan Chancellor
Hi Greg and Sasha,
Attached are three mbox files containing patches that bring the Clang backports that Nick did in 4.9.139 up to date with what is currently in 4.14 and mainline, as well as fix warnings that are present in the arm64 and x86_64 defconfigs here and in AOSP (cuttlefish_defconfig). All of these warnings are fixed in 4.14 so there will be no regressions from upgrading.

Quoted 8 lines

Really? I see a number of these only showing up in much newer kernels. Specifically these patches:
1f60652dd586 ("pinctrl: max77620: Use define directive for max77620_pinconf_param values") a0dd6773038f ("phy: tegra: remove redundant self assignment of 'map'") a9903f04e0a4 ("sched/sysctl: Fix attributes of some extern declarations")
from the "arm" mbox you provided. Why shouldn't the above patches go into 4.14.y and in some cases, also 4.19.y and 4.20.y?

Also, why are you wanting 238bcbc4e07f ("kbuild: consolidate Clang compiler flags") to be in 4.9? You put it as the last patch in the series, nothing depends on it, which seems odd...

greg k-h

Nathan Chancellor

author

2019-02-25 17:35 UTC #3 lore raw

Quoted 4 lines · Greg Kroah-Hartman

Quoted 3 lines · Greg Kroah-Hartman
Quoted 2 lines · Nathan Chancellor
Hi Greg and Sasha,

Quoted 8 lines

Quoted 8 lines
Quoted 6 lines
Attached are three mbox files containing patches that bring the Clang backports that Nick did in 4.9.139 up to date with what is currently in 4.14 and mainline, as well as fix warnings that are present in the arm64 and x86_64 defconfigs here and in AOSP (cuttlefish_defconfig). All of these warnings are fixed in 4.14 so there will be no regressions from upgrading.
Really? I see a number of these only showing up in much newer kernels.

Sigh that's what I get for not double checking my email after adding patches :(

Quoted 7 lines

Quoted 7 lines
Specifically these patches:
1f60652dd586 ("pinctrl: max77620: Use define directive for max77620_pinconf_param values") a0dd6773038f ("phy: tegra: remove redundant self assignment of 'map'") a9903f04e0a4 ("sched/sysctl: Fix attributes of some extern declarations")
from the "arm" mbox you provided. Why shouldn't the above patches go into 4.14.y and in some cases, also 4.19.y and 4.20.y?

They should. All three pick cleanly to 4.14.y. Only the first one needs to be taken into 4.19.y and 4.20.y.

Quoted 6 lines

Also, why are you wanting 238bcbc4e07f ("kbuild: consolidate Clang compiler flags") to be in 4.9? You put it as the last patch in the series, nothing depends on it, which seems odd...
greg k-h

This was more of a "to make future backports easier" commit, plus makes that block way easier to read. I should have included 3bd9805090af ("Makefile: Export clang toolchain variables") as well though. I don't feel strongly about it either way but I also don't think the commit hurts anything.

I'll leave it up to you and provide you with an updated merge resolution accordingly.

Thanks!
Nathan

Nick Desaulniers

2019-02-25 17:47 UTC #4 lore raw

Quoted 23 lines · Nathan Chancellor

Quoted 4 lines · Greg Kroah-Hartman
Quoted 3 lines · Greg Kroah-Hartman
Quoted 2 lines · Nathan Chancellor
Hi Greg and Sasha,
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Attached are three mbox files containing patches that bring the Clang backports that Nick did in 4.9.139 up to date with what is currently in 4.14 and mainline, as well as fix warnings that are present in the arm64 and x86_64 defconfigs here and in AOSP (cuttlefish_defconfig). All of these warnings are fixed in 4.14 so there will be no regressions from upgrading.
Really? I see a number of these only showing up in much newer kernels.
Sigh that's what I get for not double checking my email after adding patches :(
Quoted 5 lines
Quoted 5 lines
Specifically these patches:
1f60652dd586 ("pinctrl: max77620: Use define directive for max77620_pinconf_param values") a0dd6773038f ("phy: tegra: remove redundant self assignment of 'map'") a9903f04e0a4 ("sched/sysctl: Fix attributes of some extern declarations")

Quoted 5 lines

Quoted 2 lines
Quoted 2 lines
from the "arm" mbox you provided. Why shouldn't the above patches go into 4.14.y and in some cases, also 4.19.y and 4.20.y?
They should. All three pick cleanly to 4.14.y. Only the first one needs to be taken into 4.19.y and 4.20.y.

I feel like I need a script that given a sha, tells me what LTS branches the patch is in or not. I have this to tell me "when (what's the first tag that contains this commit)" a patch first landed:

function first_tag () {
tag=$1
git describe --contains "$tag" | sed 's/~.*//'
}

So say a patch landed in 4.15-rc1; and I want to backport to 4.9 and 4.14 (but it's already been backported to 4.14). Does anyone have a script to check this quickly? The process for seeing which LTS contains a commit or not still is very manual. I guess backports that require modification probably complicate the search further. Just asking, in case this is already a solved problem.

Signature · 2 lines

Thanks,
~Nick Desaulniers

Nathan Chancellor

author

2019-02-25 17:55 UTC #5 lore raw

Quoted 40 lines · Nick Desaulniers

Quoted 23 lines · Nathan Chancellor
Quoted 4 lines · Greg Kroah-Hartman
Quoted 3 lines · Greg Kroah-Hartman
Quoted 2 lines · Nathan Chancellor
Hi Greg and Sasha,
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Attached are three mbox files containing patches that bring the Clang backports that Nick did in 4.9.139 up to date with what is currently in 4.14 and mainline, as well as fix warnings that are present in the arm64 and x86_64 defconfigs here and in AOSP (cuttlefish_defconfig). All of these warnings are fixed in 4.14 so there will be no regressions from upgrading.
Really? I see a number of these only showing up in much newer kernels.
Sigh that's what I get for not double checking my email after adding patches :(
Quoted 5 lines
Quoted 5 lines
Specifically these patches:
1f60652dd586 ("pinctrl: max77620: Use define directive for max77620_pinconf_param values") a0dd6773038f ("phy: tegra: remove redundant self assignment of 'map'") a9903f04e0a4 ("sched/sysctl: Fix attributes of some extern declarations")
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
from the "arm" mbox you provided. Why shouldn't the above patches go into 4.14.y and in some cases, also 4.19.y and 4.20.y?
They should. All three pick cleanly to 4.14.y. Only the first one needs to be taken into 4.19.y and 4.20.y.
I feel like I need a script that given a sha, tells me what LTS branches the patch is in or not. I have this to tell me "when (what's the first tag that contains this commit)" a patch first landed:
function first_tag () {
tag=$1
git describe --contains "$tag" | sed 's/~.*//'
}

Quoted 7 lines

So say a patch landed in 4.15-rc1; and I want to backport to 4.9 and 4.14 (but it's already been backported to 4.14). Does anyone have a script to check this quickly? The process for seeing which LTS contains a commit or not still is very manual. I guess backports that require modification probably complicate the search further. Just asking, in case this is already a solved problem.

I usually use this one liner in a stable tree:

$ git log --oneline --grep="$(git show -s --format="%s" <mainline_sha>)" origin/linux-<ver>.y

You could also grep for the mainline hash.

Quoted 3 lines

Signature · 2 lines
Thanks,
~Nick Desaulniers

Greg Kroah-Hartman

maintainer

2019-02-25 17:56 UTC #6 lore raw

In reply to Nick Desaulniers

Quoted 40 lines · Nick Desaulniers

Quoted 23 lines · Nathan Chancellor
Quoted 4 lines · Greg Kroah-Hartman
Quoted 3 lines · Greg Kroah-Hartman
Quoted 2 lines · Nathan Chancellor
Hi Greg and Sasha,
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Attached are three mbox files containing patches that bring the Clang backports that Nick did in 4.9.139 up to date with what is currently in 4.14 and mainline, as well as fix warnings that are present in the arm64 and x86_64 defconfigs here and in AOSP (cuttlefish_defconfig). All of these warnings are fixed in 4.14 so there will be no regressions from upgrading.
Really? I see a number of these only showing up in much newer kernels.
Sigh that's what I get for not double checking my email after adding patches :(
Quoted 5 lines
Quoted 5 lines
Specifically these patches:
1f60652dd586 ("pinctrl: max77620: Use define directive for max77620_pinconf_param values") a0dd6773038f ("phy: tegra: remove redundant self assignment of 'map'") a9903f04e0a4 ("sched/sysctl: Fix attributes of some extern declarations")
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
from the "arm" mbox you provided. Why shouldn't the above patches go into 4.14.y and in some cases, also 4.19.y and 4.20.y?
They should. All three pick cleanly to 4.14.y. Only the first one needs to be taken into 4.19.y and 4.20.y.
I feel like I need a script that given a sha, tells me what LTS branches the patch is in or not. I have this to tell me "when (what's the first tag that contains this commit)" a patch first landed:
function first_tag () {
tag=$1
git describe --contains "$tag" | sed 's/~.*//'
}

Quoted 6 lines

So say a patch landed in 4.15-rc1; and I want to backport to 4.9 and 4.14 (but it's already been backported to 4.14). Does anyone have a script to check this quickly? The process for seeing which LTS contains a commit or not still is very manual. I guess backports that require modification probably complicate the search further. Just asking, in case this is already a solved problem.

Here's the script that I use that does just that:
https://github.com/gregkh/gregkh-linux/blob/master/scripts/fix_in_what_release

It requires 3 things:
- a directory of all kernel logs to search quickly to avoid 'git
log'. I use the ones I keep at: https://github.com/gregkh/kernel-history/tree/master/logs
- the stable queue git repo, to be able to search the stable
kernel trees quickly.
- the latest git tree from Linus, to fall back to if the commit
isn't in any of the above places.

Hope that helps.

greg k-h

Greg Kroah-Hartman

maintainer

2019-02-25 14:55 UTC #7 lore raw

In reply to Nathan Chancellor

Quoted 11 lines · Nathan Chancellor

Hi Greg and Sasha,
Attached are three mbox files containing patches that bring the Clang backports that Nick did in 4.9.139 up to date with what is currently in 4.14 and mainline, as well as fix warnings that are present in the arm64 and x86_64 defconfigs here and in AOSP (cuttlefish_defconfig). All of these warnings are fixed in 4.14 so there will be no regressions from upgrading.
They were tested with Arch Linux's GCC 8.2.1 and AOSP's clang-r349610 [1] and boot tested in QEMU 3.1.0 with our rootfs files [2].

I've included most of these now, except for the ones already pointed out.

Quoted 7 lines

Additionally, for Greg, I have provided a merge resolution for the Makefile conflict you will get when doing the android-4.9 merge. You will also get a conflict in arch/arm64/include/asm/arch_gicv3.h, just check out to MERGE_HEAD as the {read,write}_sysreg_s macros have the LTO workaround that causes the conflict in the first place. I tested this resolution by building and booting cuttlefish_defconfig for arm64 with CONFIG_LTO_CLANG and CONFIG_CFI_CLANG enabled.

Thanks for the merge resolution, I am guessing it is not going to be the same now that I did not take all of your Makefile patches :)

greg k-h