Re: linux-next: Tree for Jul 14

Re: linux-next: Tree for Jul 14

[Nathan Chancellor]

Hi Sudip,

On Thu, Jul 14, 2022 at 12:07:06PM +0100, Sudip Mukherjee (Codethink) wrote:
> Hi Stephen,
> 
> On Thu, Jul 14, 2022 at 06:55:14PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since 20220713:
> 
> Build failures on next-20220714:

<snip>

> x86_64 allmodconfig with clang fails with:
> 
> drivers/clk/qcom/gpucc-sm8350.c:111:2: error: initializer element is not a compile-time constant
>         gpu_cc_parent,
>         ^~~~~~~~~~~~~
> drivers/clk/qcom/gpucc-sm8350.c:126:2: error: initializer element is not a compile-time constant
>         gpu_cc_parent,
>         ^~~~~~~~~~~~~

I sent https://lore.kernel.org/20220711174004.3047516-1-nathan@kernel.org/
for this a few days ago, it just needs to be picked up.

> arch/x86/kernel/cpu/bugs.c:58:21: error: section attribute is specified on redeclared variable [-Werror,-Wsection]
> DEFINE_PER_CPU(u64, x86_spec_ctrl_current);
>                     ^
> ./arch/x86/include/asm/nospec-branch.h:283:12: note: previous declaration is here
> extern u64 x86_spec_ctrl_current;

This is now fixed in -tip so it should be fixed in -next tomorrorow:

https://git.kernel.org/tip/db866d3352ec85e821e730e191481cba3a2bfa6e

In the future, consider CC'ing our mailing list (llvm@lists.linux.dev)
for any clang related issues so that we can get them taken care of ASAP,
we have a MAINTAINERS entry for a reason :) thank you for testing with
clang; the more people that use it, hopefully the easier it will be to
get things unbroken.

Cheers,
Nathan

Re: linux-next: Tree for Jul 14

[Sudip Mukherjee]

Hi Nathan,

On Thu, Jul 14, 2022 at 5:05 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> Hi Sudip,
>
> On Thu, Jul 14, 2022 at 12:07:06PM +0100, Sudip Mukherjee (Codethink) wrote:
> > Hi Stephen,
> >
> > On Thu, Jul 14, 2022 at 06:55:14PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Changes since 20220713:
> >
> > Build failures on next-20220714:
>
> <snip>
>
> > x86_64 allmodconfig with clang fails with:
> >
> > drivers/clk/qcom/gpucc-sm8350.c:111:2: error: initializer element is not a compile-time constant
> >         gpu_cc_parent,
> >         ^~~~~~~~~~~~~
> > drivers/clk/qcom/gpucc-sm8350.c:126:2: error: initializer element is not a compile-time constant
> >         gpu_cc_parent,
> >         ^~~~~~~~~~~~~
>
> I sent https://lore.kernel.org/20220711174004.3047516-1-nathan@kernel.org/
> for this a few days ago, it just needs to be picked up.
>
> > arch/x86/kernel/cpu/bugs.c:58:21: error: section attribute is specified on redeclared variable [-Werror,-Wsection]
> > DEFINE_PER_CPU(u64, x86_spec_ctrl_current);
> >                     ^
> > ./arch/x86/include/asm/nospec-branch.h:283:12: note: previous declaration is here
> > extern u64 x86_spec_ctrl_current;
>
> This is now fixed in -tip so it should be fixed in -next tomorrorow:
>
> https://git.kernel.org/tip/db866d3352ec85e821e730e191481cba3a2bfa6e

This should also go to Linus. This failure is in the mainline also.
https://lore.kernel.org/lkml/Ys6sZj6KYthnDppq@debian/

>
> In the future, consider CC'ing our mailing list (llvm@lists.linux.dev)
> for any clang related issues so that we can get them taken care of ASAP,
> we have a MAINTAINERS entry for a reason :) thank you for testing with
> clang; the more people that use it, hopefully the easier it will be to
> get things unbroken.

Sure. I run arm, arm64, powerpc and x86_64 allmodconfigs with clang
(along with gcc) every night for mainline, started with linux-next
from today. Trying to setup the mips build also, I will mail llvm list
asking for help with the mips build.
Currently I only monitor the clang output from x86_64 as thats the one
which builds. If you want I can send the other reports also.


-- 
Regards
Sudip

Re: linux-next: Tree for Jul 14

[Nathan Chancellor]

On Thu, Jul 14, 2022 at 05:21:32PM +0100, Sudip Mukherjee wrote:
> Hi Nathan,
> 
> On Thu, Jul 14, 2022 at 5:05 PM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > Hi Sudip,
> >
> > On Thu, Jul 14, 2022 at 12:07:06PM +0100, Sudip Mukherjee (Codethink) wrote:
> > > Hi Stephen,
> > >
> > > On Thu, Jul 14, 2022 at 06:55:14PM +1000, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > Changes since 20220713:
> > >
> > > Build failures on next-20220714:
> >
> > <snip>
> >
> > > x86_64 allmodconfig with clang fails with:
> > >
> > > drivers/clk/qcom/gpucc-sm8350.c:111:2: error: initializer element is not a compile-time constant
> > >         gpu_cc_parent,
> > >         ^~~~~~~~~~~~~
> > > drivers/clk/qcom/gpucc-sm8350.c:126:2: error: initializer element is not a compile-time constant
> > >         gpu_cc_parent,
> > >         ^~~~~~~~~~~~~
> >
> > I sent https://lore.kernel.org/20220711174004.3047516-1-nathan@kernel.org/
> > for this a few days ago, it just needs to be picked up.
> >
> > > arch/x86/kernel/cpu/bugs.c:58:21: error: section attribute is specified on redeclared variable [-Werror,-Wsection]
> > > DEFINE_PER_CPU(u64, x86_spec_ctrl_current);
> > >                     ^
> > > ./arch/x86/include/asm/nospec-branch.h:283:12: note: previous declaration is here
> > > extern u64 x86_spec_ctrl_current;
> >
> > This is now fixed in -tip so it should be fixed in -next tomorrorow:
> >
> > https://git.kernel.org/tip/db866d3352ec85e821e730e191481cba3a2bfa6e
> 
> This should also go to Linus. This failure is in the mainline also.
> https://lore.kernel.org/lkml/Ys6sZj6KYthnDppq@debian/

Yes, it is in the x86/urgent branch so it should get there by -rc7. Our
CI is red too :(

> > In the future, consider CC'ing our mailing list (llvm@lists.linux.dev)
> > for any clang related issues so that we can get them taken care of ASAP,
> > we have a MAINTAINERS entry for a reason :) thank you for testing with
> > clang; the more people that use it, hopefully the easier it will be to
> > get things unbroken.
> 
> Sure. I run arm, arm64, powerpc and x86_64 allmodconfigs with clang
> (along with gcc) every night for mainline, started with linux-next
> from today. Trying to setup the mips build also, I will mail llvm list
> asking for help with the mips build.
> Currently I only monitor the clang output from x86_64 as thats the one
> which builds. If you want I can send the other reports also.

Sure! I am not sure that we have tested mips or powerpc allmodconfig now
that I am thinking about it but we'll certainly take a look at any
issues that come from them and see what we can do.

arm and arm64 are not warning free so disabling CONFIG_WERROR will help
out there (arm64 is a recent failure that I have not been able to
entirely figure out: https://github.com/ClangBuiltLinux/linux/issues/1642)
but I do want to get those warning clean soon so they just build out of
the box.

Cheers,
Nathan

Re: linux-next: Tree for Jul 14

[Sudip Mukherjee]

On Thu, Jul 14, 2022 at 5:29 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Thu, Jul 14, 2022 at 05:21:32PM +0100, Sudip Mukherjee wrote:
> > Hi Nathan,
> >
> > On Thu, Jul 14, 2022 at 5:05 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > >
> > > Hi Sudip,
> > >
> > > On Thu, Jul 14, 2022 at 12:07:06PM +0100, Sudip Mukherjee (Codethink) wrote:
> > > > Hi Stephen,
> > > >
> > > > On Thu, Jul 14, 2022 at 06:55:14PM +1000, Stephen Rothwell wrote:
> > > > > Hi all,
> > > > >
> > > > > Changes since 20220713:
> > > >
> > > > Build failures on next-20220714:
> > >
> > > <snip>
> > >
> > > > x86_64 allmodconfig with clang fails with:
> > > >
> > > > drivers/clk/qcom/gpucc-sm8350.c:111:2: error: initializer element is not a compile-time constant
> > > >         gpu_cc_parent,
> > > >         ^~~~~~~~~~~~~
> > > > drivers/clk/qcom/gpucc-sm8350.c:126:2: error: initializer element is not a compile-time constant
> > > >         gpu_cc_parent,
> > > >         ^~~~~~~~~~~~~
> > >
> > > I sent https://lore.kernel.org/20220711174004.3047516-1-nathan@kernel.org/
> > > for this a few days ago, it just needs to be picked up.
> > >
> > > > arch/x86/kernel/cpu/bugs.c:58:21: error: section attribute is specified on redeclared variable [-Werror,-Wsection]
> > > > DEFINE_PER_CPU(u64, x86_spec_ctrl_current);
> > > >                     ^
> > > > ./arch/x86/include/asm/nospec-branch.h:283:12: note: previous declaration is here
> > > > extern u64 x86_spec_ctrl_current;
> > >
> > > This is now fixed in -tip so it should be fixed in -next tomorrorow:
> > >
> > > https://git.kernel.org/tip/db866d3352ec85e821e730e191481cba3a2bfa6e
> >
> > This should also go to Linus. This failure is in the mainline also.
> > https://lore.kernel.org/lkml/Ys6sZj6KYthnDppq@debian/
>
> Yes, it is in the x86/urgent branch so it should get there by -rc7. Our
> CI is red too :(
>
> > > In the future, consider CC'ing our mailing list (llvm@lists.linux.dev)
> > > for any clang related issues so that we can get them taken care of ASAP,
> > > we have a MAINTAINERS entry for a reason :) thank you for testing with
> > > clang; the more people that use it, hopefully the easier it will be to
> > > get things unbroken.
> >
> > Sure. I run arm, arm64, powerpc and x86_64 allmodconfigs with clang
> > (along with gcc) every night for mainline, started with linux-next
> > from today. Trying to setup the mips build also, I will mail llvm list
> > asking for help with the mips build.
> > Currently I only monitor the clang output from x86_64 as thats the one
> > which builds. If you want I can send the other reports also.
>
> Sure! I am not sure that we have tested mips or powerpc allmodconfig now
> that I am thinking about it but we'll certainly take a look at any
> issues that come from them and see what we can do.

Uhhh.. I just checked powerpc build log and have now raised:
https://github.com/llvm/llvm-project/issues/56530

I am also part of Elisa project and there we run clang-analyzer on
defconfig of linux-next every day and the results are stored in a web
interface to check and compare. I have added Lukas if you both think
it will be good to collaborate.


-- 
Regards
Sudip

Re: linux-next: Tree for Jul 14

[Sudip Mukherjee]

Hi Nathan,

On Thu, Jul 14, 2022 at 5:29 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Thu, Jul 14, 2022 at 05:21:32PM +0100, Sudip Mukherjee wrote:
> > Hi Nathan,
> >
> > On Thu, Jul 14, 2022 at 5:05 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > >
> > > Hi Sudip,
> > >
> > > On Thu, Jul 14, 2022 at 12:07:06PM +0100, Sudip Mukherjee (Codethink) wrote:
> > > > Hi Stephen,
> > > >
> > > > On Thu, Jul 14, 2022 at 06:55:14PM +1000, Stephen Rothwell wrote:
> > > > > Hi all,
> > > > >
> > > > > Changes since 20220713:
> > > >
> > > > Build failures on next-20220714:
> > >
> > > <snip>
> > >

<snip>

>
> Sure! I am not sure that we have tested mips or powerpc allmodconfig now
> that I am thinking about it but we'll certainly take a look at any
> issues that come from them and see what we can do.

The build errors from powerpc allmodconfig with clang:

1)
Error: External symbol 'memset' referenced from prom_init.c

2)
drivers/clk/qcom/gpucc-sm8350.c:111:2: error: initializer element is
not a compile-time constant
        gpu_cc_parent,
        ^~~~~~~~~~~~~
drivers/clk/qcom/gpucc-sm8350.c:126:2: error: initializer element is
not a compile-time constant
        gpu_cc_parent,
        ^~~~~~~~~~~~~
3)
sound/soc/intel/avs/path.c:815:18: error: stack frame size (2672)
exceeds limit (2048) in 'avs_path_create'
[-Werror,-Wframe-larger-than]
struct avs_path *avs_path_create(struct avs_dev *adev, u32 dma_id,
                 ^
4)
drivers/net/ethernet/mellanox/mlx4/main.c:3332:12: error: stack frame
size (2128) exceeds limit (2048) in 'mlx4_load_one'
[-Werror,-Wframe-larger-than]
static int mlx4_load_one(struct pci_dev *pdev, int pci_dev_data,
           ^
5)
In file included from drivers/scsi/BusLogic.c:51:
drivers/scsi/FlashPoint.c:1712:12: error: stack frame size (2896)
exceeds limit (2048) in 'FlashPoint_HandleInterrupt'
[-Werror,-Wframe-larger-than]
static int FlashPoint_HandleInterrupt(void *pcard)
           ^
6)
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c:1093:12: error: stack frame size
(2128) exceeds limit (2048) in 'vcn_v3_0_start'
[-Werror,-Wframe-larger-than]


The (1) is also seen with gcc-12 on mainline -
https://lore.kernel.org/lkml/Ys%2FaDKZNhhsENH9S@debian/


-- 
Regards
Sudip

Re: linux-next: Tree for Jul 14

[Nick Desaulniers]

(Moving Stephen, linux-next, and lkml to bcc)

On Thu, Jul 14, 2022 at 9:22 AM Sudip Mukherjee
<sudipm.mukherjee@gmail.com> wrote:
>
> Hi Nathan,
>
> On Thu, Jul 14, 2022 at 5:05 PM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > Hi Sudip,
> >
> >
> > In the future, consider CC'ing our mailing list (llvm@lists.linux.dev)
> > for any clang related issues so that we can get them taken care of ASAP,
> > we have a MAINTAINERS entry for a reason :) thank you for testing with
> > clang; the more people that use it, hopefully the easier it will be to
> > get things unbroken.
>
> Sure. I run arm, arm64, powerpc and x86_64 allmodconfigs with clang
> (along with gcc) every night for mainline, started with linux-next
> from today. Trying to setup the mips build also, I will mail llvm list
> asking for help with the mips build.
> Currently I only monitor the clang output from x86_64 as thats the one
> which builds. If you want I can send the other reports also.

Hi Sudip!
Right on, nice to hear from you.  Consider filing bugs in our issue tracker
https://github.com/ClangBuiltLinux/linux/issues (consider taking a
peak to see which are already known issues and commenting on those
rather than filing new ones, time permitting), and joining our meeting
(next one in two weeks) see https://clangbuiltlinux.github.io/ for
calendar invite and meeting link.

> I have added Lukas if you both think
> it will be good to collaborate.

Ah, yeah, Lukas is an old friend. Hi Lukas!
-- 
Thanks,
~Nick Desaulniers

Re: linux-next: Tree for Jul 14

[Nathan Chancellor]

Dropping the next list and Stephen as these issues are likely present on
mainline as well.

On Thu, Jul 14, 2022 at 07:26:27PM +0100, Sudip Mukherjee wrote:
> Hi Nathan,
> 
> On Thu, Jul 14, 2022 at 5:29 PM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > On Thu, Jul 14, 2022 at 05:21:32PM +0100, Sudip Mukherjee wrote:
> > > Hi Nathan,
> > >
> > > On Thu, Jul 14, 2022 at 5:05 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > > >
> > > > Hi Sudip,
> > > >
> > > > On Thu, Jul 14, 2022 at 12:07:06PM +0100, Sudip Mukherjee (Codethink) wrote:
> > > > > Hi Stephen,
> > > > >
> > > > > On Thu, Jul 14, 2022 at 06:55:14PM +1000, Stephen Rothwell wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > Changes since 20220713:
> > > > >
> > > > > Build failures on next-20220714:
> > > >
> > > > <snip>
> > > >
> 
> <snip>
> 
> >
> > Sure! I am not sure that we have tested mips or powerpc allmodconfig now
> > that I am thinking about it but we'll certainly take a look at any
> > issues that come from them and see what we can do.
> 
> The build errors from powerpc allmodconfig with clang:

Thanks for testing!

> 1)
> Error: External symbol 'memset' referenced from prom_init.c

Good to know this is not clang specific.

> 2)
> drivers/clk/qcom/gpucc-sm8350.c:111:2: error: initializer element is
> not a compile-time constant
>         gpu_cc_parent,
>         ^~~~~~~~~~~~~
> drivers/clk/qcom/gpucc-sm8350.c:126:2: error: initializer element is
> not a compile-time constant
>         gpu_cc_parent,
>         ^~~~~~~~~~~~~
> 3)
> sound/soc/intel/avs/path.c:815:18: error: stack frame size (2672)
> exceeds limit (2048) in 'avs_path_create'
> [-Werror,-Wframe-larger-than]
> struct avs_path *avs_path_create(struct avs_dev *adev, u32 dma_id,
>                  ^

Right so this one is the one I linked early that impacts arm64 (also
arm and riscv). It appears to be related to KASAN + FORTIFY_SOURCE and I
have a diff that works but I am not sure if it is acceptable. I guess I
should just submit it and see.

> 4)
> drivers/net/ethernet/mellanox/mlx4/main.c:3332:12: error: stack frame
> size (2128) exceeds limit (2048) in 'mlx4_load_one'
> [-Werror,-Wframe-larger-than]
> static int mlx4_load_one(struct pci_dev *pdev, int pci_dev_data,
>            ^
> 5)
> In file included from drivers/scsi/BusLogic.c:51:
> drivers/scsi/FlashPoint.c:1712:12: error: stack frame size (2896)
> exceeds limit (2048) in 'FlashPoint_HandleInterrupt'
> [-Werror,-Wframe-larger-than]
> static int FlashPoint_HandleInterrupt(void *pcard)
>            ^
> 6)
> drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c:1093:12: error: stack frame size
> (2128) exceeds limit (2048) in 'vcn_v3_0_start'
> [-Werror,-Wframe-larger-than]

I don't see any large variables on the stack in these functions so I am
guessing we are just getting murdered by inlining in combination with
KASAN instrumentation, as KASAN gets turned on by allmodconfig.
Unfortunately, this has been an issue for a long time:

https://github.com/ClangBuiltLinux/linux/issues/39

It has not been as bad with CONFIG_KASAN_STACK force disabled for clang
but it is still there for certain architectures, namely ARCH=arm. I
would be curious to see if all those -Wframe-larger-than instances
disappear with CONFIG_KASAN disabled.

Cheers,
Nathan

Re: linux-next: Tree for Jul 14

[Sudip Mukherjee]

Hi Nick,

On Thu, Jul 14, 2022 at 7:52 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> (Moving Stephen, linux-next, and lkml to bcc)
>
> On Thu, Jul 14, 2022 at 9:22 AM Sudip Mukherjee
> <sudipm.mukherjee@gmail.com> wrote:
> >
> > Hi Nathan,
> >
> > On Thu, Jul 14, 2022 at 5:05 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > >
> > > Hi Sudip,
> > >
> > >
> > > In the future, consider CC'ing our mailing list (llvm@lists.linux.dev)
> > > for any clang related issues so that we can get them taken care of ASAP,
> > > we have a MAINTAINERS entry for a reason :) thank you for testing with
> > > clang; the more people that use it, hopefully the easier it will be to
> > > get things unbroken.
> >
> > Sure. I run arm, arm64, powerpc and x86_64 allmodconfigs with clang
> > (along with gcc) every night for mainline, started with linux-next
> > from today. Trying to setup the mips build also, I will mail llvm list
> > asking for help with the mips build.
> > Currently I only monitor the clang output from x86_64 as thats the one
> > which builds. If you want I can send the other reports also.
>
> Hi Sudip!
> Right on, nice to hear from you.  Consider filing bugs in our issue tracker
> https://github.com/ClangBuiltLinux/linux/issues (consider taking a
> peak to see which are already known issues and commenting on those
> rather than filing new ones, time permitting), and joining our meeting
> (next one in two weeks) see https://clangbuiltlinux.github.io/ for
> calendar invite and meeting link.

Thanks for the calendar link. I will definitely try to join the next one,

>
> > I have added Lukas if you both think
> > it will be good to collaborate.
>
> Ah, yeah, Lukas is an old friend. Hi Lukas!

Small world.


-- 
Regards
Sudip

Re: linux-next: Tree for Jul 14

[Sudip Mukherjee]

On Thu, Jul 14, 2022 at 10:24 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> Dropping the next list and Stephen as these issues are likely present on
> mainline as well.
>
> On Thu, Jul 14, 2022 at 07:26:27PM +0100, Sudip Mukherjee wrote:
> > Hi Nathan,
> >

<snip>

>
> It has not been as bad with CONFIG_KASAN_STACK force disabled for clang
> but it is still there for certain architectures, namely ARCH=arm. I
> would be curious to see if all those -Wframe-larger-than instances
> disappear with CONFIG_KASAN disabled.

Almost. This is from powerpc allmodconfig of next-20220715 with
CONFIG_KASAN disabled.

drivers/block/ublk_drv.c:890:6: error: variable 'io' is used
uninitialized whenever 'if' condition is true
[-Werror,-Wsometimes-uninitialized]
        if (tag >= ubq->q_depth)
            ^~~~~~~~~~~~~~~~~~~
drivers/block/ublk_drv.c:940:2: note: uninitialized use occurs here
        io->flags &= ~UBLK_IO_FLAG_ACTIVE;
        ^~
drivers/block/ublk_drv.c:890:2: note: remove the 'if' if its condition
is always false
        if (tag >= ubq->q_depth)
        ^~~~~~~~~~~~~~~~~~~~~~~~
drivers/block/ublk_drv.c:887:6: error: variable 'io' is used
uninitialized whenever 'if' condition is true
[-Werror,-Wsometimes-uninitialized]
        if (ubq->ubq_daemon && ubq->ubq_daemon != current)
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/block/ublk_drv.c:940:2: note: uninitialized use occurs here
        io->flags &= ~UBLK_IO_FLAG_ACTIVE;
        ^~
drivers/block/ublk_drv.c:887:2: note: remove the 'if' if its condition
is always false
        if (ubq->ubq_daemon && ubq->ubq_daemon != current)
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/block/ublk_drv.c:884:6: error: variable 'io' is used
uninitialized whenever 'if' condition is true
[-Werror,-Wsometimes-uninitialized]
        if (!ubq || ub_cmd->q_id != ubq->q_id)
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/block/ublk_drv.c:940:2: note: uninitialized use occurs here
        io->flags &= ~UBLK_IO_FLAG_ACTIVE;
        ^~
drivers/block/ublk_drv.c:884:2: note: remove the 'if' if its condition
is always false
        if (!ubq || ub_cmd->q_id != ubq->q_id)
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/block/ublk_drv.c:884:6: error: variable 'io' is used
uninitialized whenever '||' condition is true
[-Werror,-Wsometimes-uninitialized]
        if (!ubq || ub_cmd->q_id != ubq->q_id)
            ^~~~
drivers/block/ublk_drv.c:940:2: note: uninitialized use occurs here
        io->flags &= ~UBLK_IO_FLAG_ACTIVE;
        ^~
drivers/block/ublk_drv.c:884:6: note: remove the '||' if its condition
is always false
        if (!ubq || ub_cmd->q_id != ubq->q_id)
            ^~~~~~~
drivers/block/ublk_drv.c:880:6: error: variable 'io' is used
uninitialized whenever 'if' condition is true
[-Werror,-Wsometimes-uninitialized]
        if (ub_cmd->q_id >= ub->dev_info.nr_hw_queues)
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/block/ublk_drv.c:940:2: note: uninitialized use occurs here
        io->flags &= ~UBLK_IO_FLAG_ACTIVE;
        ^~
drivers/block/ublk_drv.c:880:2: note: remove the 'if' if its condition
is always false
        if (ub_cmd->q_id >= ub->dev_info.nr_hw_queues)
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/block/ublk_drv.c:877:6: error: variable 'io' is used
uninitialized whenever 'if' condition is true
[-Werror,-Wsometimes-uninitialized]
        if (!(issue_flags & IO_URING_F_SQE128))
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/block/ublk_drv.c:940:2: note: uninitialized use occurs here
        io->flags &= ~UBLK_IO_FLAG_ACTIVE;
        ^~
drivers/block/ublk_drv.c:877:2: note: remove the 'if' if its condition
is always false
        if (!(issue_flags & IO_URING_F_SQE128))
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/block/ublk_drv.c:868:20: note: initialize the variable 'io' to
silence this warning
        struct ublk_io *io;
                          ^
                           = NULL
drivers/block/ublk_drv.c:1304:6: error: variable 'ret' is used
uninitialized whenever 'if' condition is true
[-Werror,-Wsometimes-uninitialized]
        if (!ub)
            ^~~
drivers/block/ublk_drv.c:1330:9: note: uninitialized use occurs here
        return ret;
               ^~~
drivers/block/ublk_drv.c:1304:2: note: remove the 'if' if its
condition is always false
        if (!ub)
        ^~~~~~~~
drivers/block/ublk_drv.c:1301:9: note: initialize the variable 'ret'
to silence this warning
        int ret;
               ^
                = 0
7 errors generated.
_________________________________________________________________________________________________________________


drivers/clk/qcom/gpucc-sm8350.c:111:2: error: initializer element is
not a compile-time constant
        gpu_cc_parent,
        ^~~~~~~~~~~~~
drivers/clk/qcom/gpucc-sm8350.c:126:2: error: initializer element is
not a compile-time constant
        gpu_cc_parent,
        ^~~~~~~~~~~~~
2 errors generated.
_________________________________________________________________________________________________________________

drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c:1093:12: error: stack frame size
(2112) exceeds limit (2048) in 'vcn_v3_0_start'
[-Werror,-Wframe-larger-than]
static int vcn_v3_0_start(struct amdgpu_device *adev)
           ^
1 error generated.
_________________________________________________________________________________________________________________


-- 
Regards
Sudip

Re: linux-next: Tree for Jul 14

[Sudip Mukherjee]

Hi Nathan,

On Thu, Jul 14, 2022 at 10:24 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> Dropping the next list and Stephen as these issues are likely present on
> mainline as well.
>
> On Thu, Jul 14, 2022 at 07:26:27PM +0100, Sudip Mukherjee wrote:
> > Hi Nathan,
> >
> > On Thu, Jul 14, 2022 at 5:29 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > >
> > > On Thu, Jul 14, 2022 at 05:21:32PM +0100, Sudip Mukherjee wrote:
> > > > Hi Nathan,
> > > >
> > > > On Thu, Jul 14, 2022 at 5:05 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > > > >
> > > > > Hi Sudip,
> > > > >
> > > > > On Thu, Jul 14, 2022 at 12:07:06PM +0100, Sudip Mukherjee (Codethink) wrote:
> > > > > > Hi Stephen,
> > > > > >
> > > > > > On Thu, Jul 14, 2022 at 06:55:14PM +1000, Stephen Rothwell wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > Changes since 20220713:
> > > > > >
> > > > > > Build failures on next-20220714:
> > > > >
> > > > > <snip>
> > > > >
> >
> > <snip>
> >
> > >
> > > Sure! I am not sure that we have tested mips or powerpc allmodconfig now
> > > that I am thinking about it but we'll certainly take a look at any
> > > issues that come from them and see what we can do.
> >
> > The build errors from powerpc allmodconfig with clang:
>
> Thanks for testing!
>
> > 1)
> > Error: External symbol 'memset' referenced from prom_init.c
>
> Good to know this is not clang specific.

Ok, so clang is also trying to use memset for any array.
Linus suggested adding volatile. ref:
https://lore.kernel.org/lkml/CAHk-=whc3Uvhrmrr27xp5=oOhSDjXc5s1ZxC3B7xMYV6oj4WRQ@mail.gmail.com/
for the gcc-12 problem, and with that I can see that clang has worked
as expected and removed memset from struct prom_args. But now memset
is still there for other arrays in prom_init_mem() and others. I think
we will still need a patch for clang, and that will also work when the
gcc-12 bug is fixed.


-- 
Regards
Sudip