Hi Sebastian, On 8/24/20 12:35 PM, Sebastian Andrzej Siewior wrote: > On 2020-08-24 18:21:21 [+0000], Vineet Gupta wrote: >>>>>> {standard input}:5973: Error: operand out of range (512 is not between >>>>>> -512 and 511) >>>> >> >> The error above was fixed back in April: >> 799587d5731db9dc ("ARC: [plat-eznps]: Restrict to CONFIG_ISA_ARCOMPACT") > > This commit is > |git describe --contains 799587d5731db9dc > |v5.7-rc7~32^2~2 > > and CI said: > |head: d012a7190fc1fd72ed48911e77ca97ba4521bccd > ^^ v5.9-rc2 > |commit: de8f5e4f2dc1f032b46afda0a78cab5456974f89 lockdep: Introduce > wait-type checks > ^^ v5.7-rc1 > > so my assumption was that it tested rc2 and bisected it down to that > commit. Otherwise I don't see the point in testing such an old commit on > a recent -rc2 and complaining about things not related to one another.
/me confused and a bit out of context here. I didn't see the original CI report but anyways, we know the code issue... read below > >>> I have here gcc 10 and the output is: >> >> I suppose this is mainline gcc 10 ? Although it doesn't seem like compiler >> version >> related. > > Sorry for that. It is > |$ ~/cross-gcc/gcc-10.1.0-nolibc/arc-linux/bin/arc-linux-gcc -v > |Using built-in specs. > |COLLECT_GCC=/home/bigeasy/cross-gcc/gcc-10.1.0-nolibc/arc-linux/bin/arc-linux-gcc > |COLLECT_LTO_WRAPPER=/home/bigeasy/cross-gcc/gcc-10.1.0-nolibc/arc-linux/bin/../libexec/gcc/arc-linux/10.1.0/lto-wrapper > |Target: arc-linux > |Configured with: /home/arnd/git/gcc/configure --target=arc-linux > --enable-targets=all > --prefix=/home/arnd/cross/x86_64/gcc-10.1.0-nolibc/arc-linux > --enable-languages=c --without-headers --disable-bootstrap --disable-nls > --disable-threads --disable-shared --disable-libmudflap --disable-libssp > --disable-libgomp --disable-decimal-float --disable-libquadmath > --disable-libatomic --disable-libcc1 --disable-libmpx > --enable-checking=release > |Thread model: single > |Supported LTO compression algorithms: zlib > |gcc version 10.1.0 (GCC) > > This is the one built by Arnd and hosted at > https://www.kernel.org/pub/tools/crosstool/ > > Is it suitable for testing? Yeah, as I said this is not specific to compiler version, just the combination of build options which trigger it. .... >>> so I removed CONFIG_EZNPS_GIC. And then I ended with: >>> | LD vmlinux.o >>> |arc-linux-ld: >>> gcc-10.1.0-nolibc/arc-linux/bin/../lib/gcc/arc-linux/10.1.0/arc700/libgcc.a(_muldi3.o): >>> compiled for a little endian system and target is big endian >>> |arc-linux-ld: failed to merge target specific data of file >>> gcc-10.1.0-nolibc/arc-linux/bin/../lib/gcc/arc-linux/10.1.0/arc700/libgcc.a(_muldi3.o) >> >> This is unrelated since original .config with CONFIG_ARC_PLAT_EZNPS would >> have >> selected Big endina build, but you need a BE toolchain to get that working >> (since >> libgcc emulation code still comes from toolchain). > > Is a switch missing while building the gcc, another gcc target needed or > is this something that is not part of upstream gcc? You need a ARC gcc toolchain configured for big endian builds (actually the compiler driver can handle both, but support libs such as libgcc need to be BE/LE built either through multilib or cleanest is to have a ARC gcc configured for big-endian. Everything is upstream. >>> Please update CI and ARC. >> >> Nothing to update in CI. I'll send the ARC patch as a follow up. > > but it shouldn't complain about a commit merged in v5.7-rc1 because it > caused an error which was then fixed in v5.7-rc7 while using HEAD > v5.9-rc2? Yeah this indeed is weird, the only explanation I can think of is the rand config triggered the issue now. -Vineet