Hello arc members:

It is arc compiler's bug, but can not report to gnu tool chain (it is
not integrated into gnu tool chain), so have to report it here (I find
this bug here, and I guess, some arc folks are here, too).


In "drivers/power/wm831x_power.c", all wm831x_bat_get_prop() calling
functions are inline, so wm831x_bat_get_prop() size is more than 256,
but it uses 1 byte to express related offset (".byte .L61-.L65 + 6").

If let some of wm831x_bat_get_prop() calling functions noinline, it can
pass compiling.

The related .s file is in attachment, and the related command and error
(for next-20130920 tree) is below:

    /usr/local/bin/arc-elf32-gcc -Wp,-MD,drivers/power/.wm831x_power.o.d  -nostdinc -isystem /usr/local/lib/gcc/arc-elf32/4.4.7/include -I/root/linux-next/arch/arc/include -Iarch/arc/include/generated  -Iinclude -I/root/linux-next/arch/arc/include/uapi -Iarch/arc/include/generated/uapi -I/root/linux-next/include/uapi -Iinclude/generated/uapi -include /root/linux-next/include/linux/kconfig.h -include /root/linux-next/arch/arc/include/asm/current.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -mA7 -fno-common -pipe -fno-builtin -D__linux__ -fsection-anchors -mlock -mswape -mrtsc -fasynchronous-unwind-tables -mno-sdata -fcall-used-gp -mbig-endian -multcost=16 -fno-reorder-blocks -fno-ipa-cp-clone -Wframe-larger-than=1024 -fno-stack-protector -fomit-frame-pointer -g -femit-struct-debug-baseonly -fno-var-tracking -fno-inline-functions-cal
 led-once 
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -DDEBUG   -DMODULE -mlong-calls  -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(wm831x_power)"  -D"KBUILD_MODNAME=KBUILD_STR(wm831x_power)" -c -o drivers/power/.tmp_wm831x_power.o drivers/power/wm831x_power.c
  {standard input}: Assembler messages:
  {standard input}:934: Error: value of 256 too large for field of 1 bytes at 1987


Welcome any suggestions or completions (e.g. which location and members
this bug should be reported to).

Thanks.
-- 
Chen Gang