Re: next: mips: cavium_octeon_defconfig: gcc-8 - dwc3-octeon.c:502:8: include/linux/compiler_types.h:397:38: error: call to '__compiletime_assert_335' declared with attribute error: FIELD_PREP: value too large for the field _compiletime_assert

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2023-08-08 at 09:45 +0200, Ladislav Michl wrote:
> Hi Naresh,
> 
> On Tue, 2023-08-08 at 12:41 +0530, Naresh Kamboju wrote:
> > [My two cents]

seems this is going to be far more expensive ;-)

> > While building Linux next-20230808 mips cavium_octeon_defconfig
> > with gcc-8 failed with below warnings and errors.
> > 
> > Build log:
> > ----------
> > 
> > In function 'dwc3_octeon_setup.isra.4',
> >     inlined from 'dwc3_octeon_probe' at drivers/usb/dwc3/dwc3-
> > octeon.c:502:8:
> > include/linux/compiler_types.h:397:38: error: call to
> > '__compiletime_assert_335' declared with attribute error:
> > FIELD_PREP:
> > value too large for the field
> >   _compiletime_assert(condition, msg, __compiletime_assert_,
> > __COUNTER__)
> >                                       ^
> > include/linux/compiler_types.h:378:4: note: in definition of macro
> > '__compiletime_assert'
> >     prefix ## suffix();    \
> >     ^~~~~~
> 
> Not sure what is really going on there. Code compiles even using
> 32bit toochains without warnings and such an assignments are used in
> other kernel drivers. See for example drivers/cxl/core/hdm.c:534
> which is using the same types. Also 
> drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_hash.c in
> rvu_exact_prepare_table_entry...

So using gcc-8.2.1 20181130 I see the same error. However
drivers/cxl/core/hdm.c still compiler cleanly.

Now USBDRD_UCTL_CTL_H_CLKDIV_SEL is defined as GENMASK_ULL(26, 24).
Making is GENMASK_ULL(27, 24) makes error go away. Also making clk_div
array in dwc3_octeon_get_divider one element shorter makes error go
away.

To me it seems gcc-8 figures out the result of dwc3_octeon_get_divider
can be greater than 7 and produces error. Cannot happen in the real
world. Should we make gcc-8 stand corrected?

> Anyway, let me setup gcc-8 toolchain :)
> 
> >   Reported-by: Linux Kernel Functional Testing <lkft@xxxxxxxxxx>
> > 
> > Links:
> > -----
> >  -
> > https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230808/testrun/18882876/suite/build/test/gcc-8-cavium_octeon_defconfig/log
> >  -
> > https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230808/testrun/18882876/suite/build/test/gcc-8-cavium_octeon_defconfig/history/
> > 
> > Steps to reproduce:
> > ------------
> >   tuxmake --runtime podman --target-arch mips --toolchain gcc-8
> > --kconfig cavium_octeon_defconfig
> >    -
> > https://storage.tuxsuite.com/public/linaro/lkft/builds/2TgoAZwerJ28UWHyqfQUiaYYhrl/tuxmake_reproducer.sh
> > 
> > --
> > Linaro LKFT
> > https://lkft.linaro.org
> 





[Index of Archives]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux