next-20250903 x86_64 clang-20 allyesconfig mmp_pdma.c:1188:14: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
The following build warnings / errors were noticed on x86_64 allyesconfig with clang-20 toolchain running on Linux next-20250903 tag.
But the gcc-13 builds passed.
Regression Analysis: - New regression? yes - Reproducibility? yes
First seen on next-20250903 Bad: next-20250903 Good: next-20250902
Build regression: next-20250903 x86_64 clang-20 allyesconfig mmp_pdma.c:1188:14: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
x86_64: build: * clang-20-allyesconfig
Build error: drivers/dma/mmp_pdma.c:1188:14: error: shift count >= width of type [-Werror,-Wshift-count-overflow] 1188 | .dma_mask = DMA_BIT_MASK(64), /* force 64-bit DMA addr capability */ | ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:73:54: note: expanded from macro 'DMA_BIT_MASK' 73 | #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) | ^ ~~~ 1 error generated. make[5]: *** [scripts/Makefile.build:287: drivers/dma/mmp_pdma.o] Error 1
## Source * Kernel version: 6.17.0-rc4 * Git tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git * Git describe: next-20250903 * Git commit: 5d50cf9f7cf20a17ac469c20a2e07c29c1f6aab7 * Architectures: x86_64 * Toolchains: clang-20 * Kconfigs: allyesconfig
## Build * Build log: https://qa-reports.linaro.org/api/testruns/29752023/log_file/ * Build details: https://regressions.linaro.org/lkft/linux-next-master/next-20250903/build/cl... * Build plan: https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/builds/32B39xPuIT... * Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/32B39xPuITjxcbak13h2M... * Kernel config: https://storage.tuxsuite.com/public/linaro/lkft/builds/32B39xPuITjxcbak13h2M...
-- Linaro LKFT https://lkft.linaro.org
This seems like a clang-20 bug. It's complaining about an impossible shift in code which it should know is dead.
regards, dan carpenter
On Wed, Sep 03, 2025 at 03:38:11PM +0530, Naresh Kamboju wrote:
The following build warnings / errors were noticed on x86_64 allyesconfig with clang-20 toolchain running on Linux next-20250903 tag.
But the gcc-13 builds passed.
Regression Analysis:
- New regression? yes
- Reproducibility? yes
First seen on next-20250903 Bad: next-20250903 Good: next-20250902
Build regression: next-20250903 x86_64 clang-20 allyesconfig mmp_pdma.c:1188:14: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
x86_64: build: * clang-20-allyesconfig
Build error: drivers/dma/mmp_pdma.c:1188:14: error: shift count >= width of type [-Werror,-Wshift-count-overflow] 1188 | .dma_mask = DMA_BIT_MASK(64), /* force 64-bit DMA addr capability */ | ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:73:54: note: expanded from macro 'DMA_BIT_MASK' 73 | #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) | ^ ~~~ 1 error generated. make[5]: *** [scripts/Makefile.build:287: drivers/dma/mmp_pdma.o] Error 1
## Source
- Kernel version: 6.17.0-rc4
- Git tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git
- Git describe: next-20250903
- Git commit: 5d50cf9f7cf20a17ac469c20a2e07c29c1f6aab7
- Architectures: x86_64
- Toolchains: clang-20
- Kconfigs: allyesconfig
## Build
- Build log: https://qa-reports.linaro.org/api/testruns/29752023/log_file/
- Build details:
https://regressions.linaro.org/lkft/linux-next-master/next-20250903/build/cl...
- Build plan: https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/builds/32B39xPuIT...
- Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/32B39xPuITjxcbak13h2M...
- Kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/32B39xPuITjxcbak13h2M...
-- Linaro LKFT https://lkft.linaro.org
On Wed, Sep 3, 2025, at 12:08, Naresh Kamboju wrote:
Build error: drivers/dma/mmp_pdma.c:1188:14: error: shift count >= width of type [-Werror,-Wshift-count-overflow] 1188 | .dma_mask = DMA_BIT_MASK(64), /* force 64-bit DMA addr capability */ | ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:73:54: note: expanded from macro 'DMA_BIT_MASK' 73 | #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) | ^ ~~~
I see two separate issues:
1. The current DMA_BIT_MASK() definition seems unfortunate, as the '(n) == 64' check is meant to avoid this problem, but I think this only works inside of a function, not in a static structure definition. This could perhaps be avoided by replacing the ?: operator with __builtin_choose_expr(), but that likely causes other build failures.
2. The dma_mask logic in this driver looks very strange and makes no sense to me.
Guodong Xu just added the line above, to set the dma mask for the spacemit variant, with the new logic being:
+ /* Set DMA mask based on ops->dma_mask, or OF/platform */ + if (pdev->ops->dma_mask) + dma_set_mask(pdev->dev, pdev->ops->dma_mask); + else if (pdev->dev->coherent_dma_mask) dma_set_mask(pdev->dev, pdev->dev->coherent_dma_mask); else dma_set_mask(pdev->dev, DMA_BIT_MASK(64));
This has multiple problems:
- the coherent_dma_mask is still left at the default 32-bit mask for spacemit, which I think is a mistake, even if the effect is the same - The existing dma_set_mask(pdev->dev, pdev->dev->coherent_dma_mask); is completely bogus, as the driver should just set a fixed 32-bit mask based on the capabilities of the device. No other driver bsides mmp_pdma.c and pxa_dma.c does this. - The pxa/mmp variant clearly supports 32-bit addressing, no more, no less, so just setting the 32-bit mask should be enough.
Guodong, how about a patch to drop all the custom dma_mask handling and instead just use dma_set_mask_and_coherent(DMA_BIT_MASK(64)) or dma_set_mask_and_coherent(DMA_BIT_MASK(32)) here? Instead of passing the mask in the mmp_pdma_ops, you can replace it e.g. with a 'bool addr64' flag, or an 'int dma_width' number that gets passed into the DMA_MASK_MASK().
Arnd
On Wed, Sep 03, 2025 at 02:04:10PM +0200, Arnd Bergmann wrote:
On Wed, Sep 3, 2025, at 12:08, Naresh Kamboju wrote:
Build error: drivers/dma/mmp_pdma.c:1188:14: error: shift count >= width of type [-Werror,-Wshift-count-overflow] 1188 | .dma_mask = DMA_BIT_MASK(64), /* force 64-bit DMA addr capability */ | ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:73:54: note: expanded from macro 'DMA_BIT_MASK' 73 | #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) | ^ ~~~
I see two separate issues:
- The current DMA_BIT_MASK() definition seems unfortunate, as the
'(n) == 64' check is meant to avoid this problem, but I think this only works inside of a function, not in a static structure definition.
Right, this is one of our longest outstanding issues :/
https://github.com/ClangBuiltLinux/linux/issues/92 https://github.com/llvm/llvm-project/issues/38137
This only happens at global scope.
This could perhaps be avoided by replacing the ?: operator with __builtin_choose_expr(), but that likely causes other build failures.
Yeah, that makes the problem worse somehow even though GCC says the non-taken option should not be evaluated...
drivers/dma/mmp_pdma.c:1188:14: error: shift count >= width of type [-Werror,-Wshift-count-overflow] 1188 | .dma_mask = DMA_BIT_MASK(64), /* force 64-bit DMA addr capability */ | ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:73:70: note: expanded from macro 'DMA_BIT_MASK' 73 | #define DMA_BIT_MASK(n) __builtin_choose_expr((n) == 64, ~0ULL, (1ULL<<(n))-1) | ^ ~~~ drivers/dma/mmp_pdma.c:1323:27: error: shift count >= width of type [-Werror,-Wshift-count-overflow] 1323 | dma_set_mask(pdev->dev, DMA_BIT_MASK(64)); | ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:73:70: note: expanded from macro 'DMA_BIT_MASK' 73 | #define DMA_BIT_MASK(n) __builtin_choose_expr((n) == 64, ~0ULL, (1ULL<<(n))-1) | ^ ~~~
Guodong, how about a patch to drop all the custom dma_mask handling and instead just use dma_set_mask_and_coherent(DMA_BIT_MASK(64)) or dma_set_mask_and_coherent(DMA_BIT_MASK(32)) here? Instead of passing the mask in the mmp_pdma_ops, you can replace it e.g. with a 'bool addr64' flag, or an 'int dma_width' number that gets passed into the DMA_MASK_MASK().
If this works, I think it is worth pursuing to avoid this bogus warning/error.
Cheers, Nathan
On Thu, Sep 4, 2025 at 12:59 AM Nathan Chancellor nathan@kernel.org wrote:
On Wed, Sep 03, 2025 at 02:04:10PM +0200, Arnd Bergmann wrote:
On Wed, Sep 3, 2025, at 12:08, Naresh Kamboju wrote:
Build error: drivers/dma/mmp_pdma.c:1188:14: error: shift count >= width of type [-Werror,-Wshift-count-overflow] 1188 | .dma_mask = DMA_BIT_MASK(64), /* force 64-bit DMA addr capability */ | ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:73:54: note: expanded from macro 'DMA_BIT_MASK' 73 | #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) | ^ ~~~
I see two separate issues:
- The current DMA_BIT_MASK() definition seems unfortunate, as the
'(n) == 64' check is meant to avoid this problem, but I think this only works inside of a function, not in a static structure definition.
Right, this is one of our longest outstanding issues :/
https://github.com/ClangBuiltLinux/linux/issues/92 https://github.com/llvm/llvm-project/issues/38137
This only happens at global scope.
This could perhaps be avoided by replacing the ?: operator with __builtin_choose_expr(), but that likely causes other build failures.
Yeah, that makes the problem worse somehow even though GCC says the non-taken option should not be evaluated...
drivers/dma/mmp_pdma.c:1188:14: error: shift count >= width of type [-Werror,-Wshift-count-overflow] 1188 | .dma_mask = DMA_BIT_MASK(64), /* force 64-bit DMA addr capability */ | ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:73:70: note: expanded from macro 'DMA_BIT_MASK' 73 | #define DMA_BIT_MASK(n) __builtin_choose_expr((n) == 64, ~0ULL, (1ULL<<(n))-1) | ^ ~~~ drivers/dma/mmp_pdma.c:1323:27: error: shift count >= width of type [-Werror,-Wshift-count-overflow] 1323 | dma_set_mask(pdev->dev, DMA_BIT_MASK(64)); | ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:73:70: note: expanded from macro 'DMA_BIT_MASK' 73 | #define DMA_BIT_MASK(n) __builtin_choose_expr((n) == 64, ~0ULL, (1ULL<<(n))-1) | ^ ~~~
Thanks Nathan for the information here and above.
Guodong, how about a patch to drop all the custom dma_mask handling and instead just use dma_set_mask_and_coherent(DMA_BIT_MASK(64)) or dma_set_mask_and_coherent(DMA_BIT_MASK(32)) here? Instead of passing the mask in the mmp_pdma_ops, you can replace it e.g. with a 'bool addr64' flag, or an 'int dma_width' number that gets passed into the DMA_MASK_MASK().
Thanks, Arnd. I'll send a patch to clean up and simplify the logic.
If this works, I think it is worth pursuing to avoid this bogus warning/error.
Cheers, Nathan
-
Arnd Bergmann -
Dan Carpenter -
Guodong Xu -
Naresh Kamboju -
Nathan Chancellor