Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Cannot build powerpc vector instructions #239

Closed
shenki opened this issue Oct 25, 2018 · 5 comments
Closed

Cannot build powerpc vector instructions #239

shenki opened this issue Oct 25, 2018 · 5 comments
Labels
[ARCH] powerpc This bug impacts ARCH=powerpc [BUG] llvm A bug that should be fixed in upstream LLVM Reported upstream This bug was filed on LLVM’s issue tracker, Phabricator, or the kernel mailing list.

Comments

@shenki
Copy link
Member

shenki commented Oct 25, 2018 •
edited by nathanchance

From https://llvm.org/pr38887

When we enabled soft-float for ppc64, we chose to disable altivec!

http://llvm.org/viewvc/llvm-project?view=revision&revision=283060

This change enables soft-float for PowerPC64, and also makes soft-float disable
all vector instruction sets for both 32-bit and 64-bit modes. This latter part
is necessary because the PPC backend canonicalizes many Altivec vector types to
floating-point types, and so soft-float breaks scalarization support for many
operations. Both for embedded targets and for operating-system kernels desiring
soft-float support, it seems reasonable that disabling hardware floating-point
also disables vector instructions (embedded targets without hardware floating
point support are unlikely to have Altivec, etc. and operating system kernels
desiring not to use floating-point registers to lower syscall cost are unlikely
to want to use vector registers either). If someone needs this to work, we'll
need to change the fact that we promote many Altivec operations to act on
v4f32. To make it possible to disable Altivec when soft-float is enabled,
hardware floating-point support needs to be expressed as a positive feature,
like the others, and not a negative feature, because target features cannot
have dependencies on the disabling of some other feature. So +soft-float has
now become -hard-float.

We can work around this when building the powerpc64 defconfigs by disabling options that use vector instructions:

./scripts/config -d BTRFS_FS -d MD_RAID456

References:
@shenki shenki added [BUG] llvm A bug that should be fixed in upstream LLVM [PATCH] Does not exist (yet) [ARCH] powerpc This bug impacts ARCH=powerpc labels Oct 25, 2018
@shenki
Copy link
Member Author

shenki commented Oct 31, 2018

Workaround posted: https://patchwork.ozlabs.org/patch/991268/

fengguang pushed a commit to 0day-ci/linux that referenced this issue Oct 31, 2018
@shenki @intel-lab-lkp
raid6/ppc: Fix build for clang
1a15481 
We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
fengguang pushed a commit to 0day-ci/linux that referenced this issue Nov 2, 2018
@shenki @intel-lab-lkp
raid6/ppc: Fix build for clang
6d8359d 
We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
@nickdesaulniers
Copy link
Member

@shenki did your patch ever land?

@nickdesaulniers nickdesaulniers added [PATCH] Submitted A patch has been submitted for review and removed [PATCH] Does not exist (yet) labels Dec 8, 2018
ruscur pushed a commit to ruscur/linux that referenced this issue Dec 20, 2018
@shenki @mpe
raid6/ppc: Fix build for clang
e213574 
We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
@nathanchance
Copy link
Member

Workaround patch merged into mainline: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e213574a449f7a57d4202c1869bbc7680b6b5521

Do we want to close this?

@shenki
Copy link
Member Author

shenki commented Dec 28, 2018

Do we want to close this?

We could leave it open until the clang support has landed.

@nathanchance nathanchance removed the [PATCH] Submitted A patch has been submitted for review label Jan 7, 2019
Whissi pushed a commit to Whissi/linux-stable that referenced this issue Jan 13, 2019
@shenki @gregkh
raid6/ppc: Fix build for clang
439022e 
commit e213574 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux/linux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
woodsts pushed a commit to woodsts/linux-stable that referenced this issue Jan 13, 2019
@shenki @gregkh
raid6/ppc: Fix build for clang
1f33700 
commit e213574 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux/linux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[nc: Use 'ifeq ($(cc-name),clang)' instead of 'ifdef CONFIG_CC_IS_CLANG'
     because that config does not exist in 4.14; the Kconfig rewrite
     that added that config happened in 4.18]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
isjerryxiao pushed a commit to isjerryxiao/Amlogic_s905-kernel that referenced this issue Jan 14, 2019
@shenki @isjerryxiao
raid6/ppc: Fix build for clang
df38e8a 
commit e213574a449f7a57d4202c1869bbc7680b6b5521 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux/linux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
isjerryxiao pushed a commit to isjerryxiao/Amlogic_s905-kernel that referenced this issue Jan 20, 2019
@shenki @isjerryxiao
raid6/ppc: Fix build for clang
2120c66 
commit e213574a449f7a57d4202c1869bbc7680b6b5521 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux/linux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Emerald-Phoenix pushed a commit to Emerald-Phoenix/linux that referenced this issue Jan 21, 2019
@shenki @Emerald-Phoenix
raid6/ppc: Fix build for clang
11f8385 
commit e213574 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[nc: Use 'ifeq ($(cc-name),clang)' instead of 'ifdef CONFIG_CC_IS_CLANG'
     because that config does not exist in 4.14; the Kconfig rewrite
     that added that config happened in 4.18]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/linux-mvista-2.4 that referenced this issue Feb 4, 2019
@shenki @jpuhlman
raid6/ppc: Fix build for clang
0c28cd2 
Source: linux-mvista-2.4
MR: 96580, 00000
Type: Integration
Disposition: Merged from linux-mvista-2.4
ChangeID: 1f33700bdf421490aef65bb794dbd9d9837f7ea0
Description:

commit e213574a449f7a57d4202c1869bbc7680b6b5521 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux/linux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[nc: Use 'ifeq ($(cc-name),clang)' instead of 'ifdef CONFIG_CC_IS_CLANG'
     because that config does not exist in 4.14; the Kconfig rewrite
     that added that config happened in 4.18]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster@mvista.com>
Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/linux-mvista-2.4 that referenced this issue Feb 7, 2019
@shenki @mvakuster
raid6/ppc: Fix build for clang
0a95457 
Source: Kernel.org
MR: 96580
Type: Security Fix
Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-4.14.y
ChangeID: 1f33700bdf421490aef65bb794dbd9d9837f7ea0
Description:

commit e213574a449f7a57d4202c1869bbc7680b6b5521 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux/linux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[nc: Use 'ifeq ($(cc-name),clang)' instead of 'ifdef CONFIG_CC_IS_CLANG'
     because that config does not exist in 4.14; the Kconfig rewrite
     that added that config happened in 4.18]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster@mvista.com>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/linux-mvista-2.4 that referenced this issue Mar 5, 2019
@shenki @mvakuster
raid6/ppc: Fix build for clang
c8c0043 
Source: Kernel.org
MR: 96580
Type: Security Fix
Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-4.14.y
ChangeID: 1f33700bdf421490aef65bb794dbd9d9837f7ea0
Description:

commit e213574a449f7a57d4202c1869bbc7680b6b5521 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux/linux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[nc: Use 'ifeq ($(cc-name),clang)' instead of 'ifdef CONFIG_CC_IS_CLANG'
     because that config does not exist in 4.14; the Kconfig rewrite
     that added that config happened in 4.18]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster@mvista.com>
randomblame pushed a commit to randomblame/android_kernel_xiaomi_sm8150 that referenced this issue Apr 20, 2019
@shenki @randomblame
raid6/ppc: Fix build for clang
2211984 
commit e213574a449f7a57d4202c1869bbc7680b6b5521 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux/linux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[nc: Use 'ifeq ($(cc-name),clang)' instead of 'ifdef CONFIG_CC_IS_CLANG'
     because that config does not exist in 4.14; the Kconfig rewrite
     that added that config happened in 4.18]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
randomblame pushed a commit to randomblame/android_kernel_xiaomi_sm8150 that referenced this issue Apr 27, 2019
@shenki @randomblame
raid6/ppc: Fix build for clang
95d1d45 
commit e213574a449f7a57d4202c1869bbc7680b6b5521 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux/linux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[nc: Use 'ifeq ($(cc-name),clang)' instead of 'ifdef CONFIG_CC_IS_CLANG'
     because that config does not exist in 4.14; the Kconfig rewrite
     that added that config happened in 4.18]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mdeejay pushed a commit to BeastRoms-Devices/kernel_xiaomi_raphael that referenced this issue Aug 15, 2019
@shenki @mdeejay
raid6/ppc: Fix build for clang
a008f5d 
commit e213574a449f7a57d4202c1869bbc7680b6b5521 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux/linux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[nc: Use 'ifeq ($(cc-name),clang)' instead of 'ifdef CONFIG_CC_IS_CLANG'
     because that config does not exist in 4.14; the Kconfig rewrite
     that added that config happened in 4.18]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mdeejay pushed a commit to BeastRoms-Devices/kernel_xiaomi_raphael that referenced this issue Aug 17, 2019
@shenki @mdeejay
raid6/ppc: Fix build for clang
f28bfda 
commit e213574a449f7a57d4202c1869bbc7680b6b5521 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux/linux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[nc: Use 'ifeq ($(cc-name),clang)' instead of 'ifdef CONFIG_CC_IS_CLANG'
     because that config does not exist in 4.14; the Kconfig rewrite
     that added that config happened in 4.18]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mdeejay pushed a commit to BeastRoms-Devices/kernel_xiaomi_cepheus that referenced this issue Aug 22, 2019
@shenki @mdeejay
raid6/ppc: Fix build for clang
99344f3 
commit e213574a449f7a57d4202c1869bbc7680b6b5521 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux/linux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[nc: Use 'ifeq ($(cc-name),clang)' instead of 'ifdef CONFIG_CC_IS_CLANG'
     because that config does not exist in 4.14; the Kconfig rewrite
     that added that config happened in 4.18]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Flatty11 pushed a commit to Flatty11/SM-G9750 that referenced this issue Oct 10, 2019
@shenki @Flatty11
raid6/ppc: Fix build for clang
f44ebcb 
commit e213574a449f7a57d4202c1869bbc7680b6b5521 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux/linux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[nc: Use 'ifeq ($(cc-name),clang)' instead of 'ifdef CONFIG_CC_IS_CLANG'
     because that config does not exist in 4.14; the Kconfig rewrite
     that added that config happened in 4.18]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@nickdesaulniers nickdesaulniers added the low priority This bug is not critical and not a priority label Nov 19, 2019
freeza-inc pushed a commit to freeza-inc/bm-galaxy-note10-sd855-pie that referenced this issue Dec 24, 2019
@shenki @freeza-inc
raid6/ppc: Fix build for clang
db1b923 
commit e213574a449f7a57d4202c1869bbc7680b6b5521 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux/linux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[nc: Use 'ifeq ($(cc-name),clang)' instead of 'ifdef CONFIG_CC_IS_CLANG'
     because that config does not exist in 4.14; the Kconfig rewrite
     that added that config happened in 4.18]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Inkypen79 pushed a commit to Inkypen79/kernel_xiaomi_andromeda_old that referenced this issue Jan 15, 2020
@shenki @Inkypen79
raid6/ppc: Fix build for clang
eb90d6d 
commit e213574 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux/linux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[nc: Use 'ifeq ($(cc-name),clang)' instead of 'ifdef CONFIG_CC_IS_CLANG'
     because that config does not exist in 4.14; the Kconfig rewrite
     that added that config happened in 4.18]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Inkypen79 pushed a commit to Inkypen79/kernel_xiaomi_andromeda_old that referenced this issue Jan 15, 2020
@shenki @Inkypen79
raid6/ppc: Fix build for clang
854d37f 
commit e213574 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux/linux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[nc: Use 'ifeq ($(cc-name),clang)' instead of 'ifdef CONFIG_CC_IS_CLANG'
     because that config does not exist in 4.14; the Kconfig rewrite
     that added that config happened in 4.18]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@nickdesaulniers
Copy link
Member

Hopefully the llvm bug gets resolved, but this is no longer technically a blocker.

@nickdesaulniers nickdesaulniers added the Reported upstream This bug was filed on LLVM’s issue tracker, Phabricator, or the kernel mailing list. label Feb 8, 2020
@tpimh tpimh removed the low priority This bug is not critical and not a priority label Feb 15, 2020
nathanchance pushed a commit that referenced this issue Dec 15, 2020
@JuantAldea @gregkh
staging: trivial: hikey9xx: fix be32<->u32 casting warnings
1b9419d 
This patch fixes the following warnings reported by sparse, by adding
missing __force annotations.

drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to restricted __be32
drivers/staging/hikey9xx/hisi-spmi-controller.c:164:24: warning: cast to restricted __be32

drivers/staging/hikey9xx/hisi-spmi-controller.c:239:25: warning: cast from restricted __be32

Rationale for #164:
data is declared as u32, and it is read and then converted by means of
be32_to_cpu(). Said function expects a __be32 but data is u32, therefore
there's a type missmatch here.

Rationale for #239:
Is the dual of #164. This time data going to be  written so it
needs to be converted from cpu to __be32, but writel() expects u32 and the
output of cpu_to_be32 returns a __be32.

Signed-off-by: Juan Antonio Aldea-Armenteros <juant.aldea@gmail.com>
Link: https://lore.kernel.org/r/20201119122737.189675-1-juant.aldea@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
krazey pushed a commit to krazey/android_kernel_motorola_exynos9610 that referenced this issue Apr 23, 2022
@shenki @krazey
raid6/ppc: Fix build for clang
871a6fa 
commit e213574a449f7a57d4202c1869bbc7680b6b5521 upstream.

We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.

Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float.  So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).

This is a workaround until the issue is resolved in clang.

Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: ClangBuiltLinux/linux#239
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[nc: Use 'ifeq ($(cc-name),clang)' instead of 'ifdef CONFIG_CC_IS_CLANG'
     because that config does not exist in 4.14; the Kconfig rewrite
     that added that config happened in 4.18]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
[ARCH] powerpc This bug impacts ARCH=powerpc [BUG] llvm A bug that should be fixed in upstream LLVM Reported upstream This bug was filed on LLVM’s issue tracker, Phabricator, or the kernel mailing list.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@shenki @tpimh @nickdesaulniers @nathanchance