Re: {standard input}:5973: Error: operand out of range (512 is not between -512 and 511)

[Vineet Gupta]

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