* [Bug target/115153] Error: bad immediate value for 8-bit offset - armv7ve
2024-05-19 0:12 [Bug sanitizer/115153] New: Error: bad immediate value for 8-bit offset - armv7ve rudi at heitbaum dot com
@ 2024-05-19 0:15 ` pinskia at gcc dot gnu.org
2024-05-19 0:16 ` pinskia at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-05-19 0:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
What is your exact configure command line?
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug target/115153] Error: bad immediate value for 8-bit offset - armv7ve
2024-05-19 0:12 [Bug sanitizer/115153] New: Error: bad immediate value for 8-bit offset - armv7ve rudi at heitbaum dot com
2024-05-19 0:15 ` [Bug target/115153] " pinskia at gcc dot gnu.org
@ 2024-05-19 0:16 ` pinskia at gcc dot gnu.org
2024-05-19 0:21 ` rudi at heitbaum dot com
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-05-19 0:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Ever confirmed|0 |1
Last reconfirmed| |2024-05-19
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Also can you attach the preprocessed source? and add -v to gcc command line to
provide the exact command line which is causing the error?
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug target/115153] Error: bad immediate value for 8-bit offset - armv7ve
2024-05-19 0:12 [Bug sanitizer/115153] New: Error: bad immediate value for 8-bit offset - armv7ve rudi at heitbaum dot com
2024-05-19 0:15 ` [Bug target/115153] " pinskia at gcc dot gnu.org
2024-05-19 0:16 ` pinskia at gcc dot gnu.org
@ 2024-05-19 0:21 ` rudi at heitbaum dot com
2024-05-19 0:36 ` rudi at heitbaum dot com
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rudi at heitbaum dot com @ 2024-05-19 0:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153
--- Comment #3 from rudi at heitbaum dot com ---
(In reply to Andrew Pinski from comment #1)
> What is your exact configure command line?
Executing (host):
/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/build/gcc-14.1.0/configure
--host=x86_64-linux-gnu --build=x86_64-linux-gnu
--prefix=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain
--bindir=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain/bin
--sbindir=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain/sbin
--sysconfdir=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain/etc
--libexecdir=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain/lib
--localstatedir=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain/var
--disable-static --enable-shared --target=armv7ve-libreelec-linux-gnueabihf
--with-sysroot=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain/armv7ve-libreelec-linux-gnueabihf/sysroot
--with-gmp=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain
--with-mpfr=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain
--with-mpc=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain
--with-zstd=/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-RPi2.arm-12.0-devel/toolchain
--with-gnu-as --with-gnu-ld --enable-plugin --enable-lto --enable-gold
--enable-ld=default --with-linker-hash-style=gnu --disable-multilib
--disable-nls --enable-checking=release --without-ppl --without-cloog
--disable-libada --disable-libmudflap --disable-libitm --disable-libquadmath
--disable-libgomp --disable-libmpx --disable-libssp --enable-__cxa_atexit
--enable-languages=c,c++ --enable-libatomic --enable-decimal-float --enable-tls
--enable-shared --disable-static --enable-long-long --enable-threads=posix
--disable-libstdcxx-pch --enable-libstdcxx-time --enable-clocale=gnu
--with-abi=aapcs-linux --with-arch=armv7ve --with-float=hard
--with-fpu=neon-vfpv4
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug target/115153] Error: bad immediate value for 8-bit offset - armv7ve
2024-05-19 0:12 [Bug sanitizer/115153] New: Error: bad immediate value for 8-bit offset - armv7ve rudi at heitbaum dot com
` (2 preceding siblings ...)
2024-05-19 0:21 ` rudi at heitbaum dot com
@ 2024-05-19 0:36 ` rudi at heitbaum dot com
2024-05-19 0:40 ` rudi at heitbaum dot com
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rudi at heitbaum dot com @ 2024-05-19 0:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153
--- Comment #4 from rudi at heitbaum dot com ---
We have also see the same failure building kodi (vpeter4 did the investigation)
The difference between gcc13 and 14 is
gcc-13, ok
add r0, r0, #384
ldrd r2, r3, [r0]
gcc-14, not ok
dmb ish
ldrd r2, r3, [r0, #384]
The kodi issue is at - https://github.com/xbmc/xbmc/issues/25221
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug target/115153] Error: bad immediate value for 8-bit offset - armv7ve
2024-05-19 0:12 [Bug sanitizer/115153] New: Error: bad immediate value for 8-bit offset - armv7ve rudi at heitbaum dot com
` (3 preceding siblings ...)
2024-05-19 0:36 ` rudi at heitbaum dot com
@ 2024-05-19 0:40 ` rudi at heitbaum dot com
2024-05-19 0:45 ` [Bug target/115153] [14/15 Regression] " pinskia at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rudi at heitbaum dot com @ 2024-05-19 0:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153
--- Comment #5 from rudi at heitbaum dot com ---
(In reply to rudi from comment #4)
> We have also see the same failure building kodi (vpeter4 did the
> investigation)
> The difference between gcc13 and 14 is
>
> gcc-13, ok
> add r0, r0, #384
> ldrd r2, r3, [r0]
>
> gcc-14, not ok
> dmb ish
> ldrd r2, r3, [r0, #384]
>
> The kodi issue is at - https://github.com/xbmc/xbmc/issues/25221
This was when we built a working gcc (we compiled it without libsanitizer)
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug target/115153] [14/15 Regression] Error: bad immediate value for 8-bit offset - armv7ve
2024-05-19 0:12 [Bug sanitizer/115153] New: Error: bad immediate value for 8-bit offset - armv7ve rudi at heitbaum dot com
` (4 preceding siblings ...)
2024-05-19 0:40 ` rudi at heitbaum dot com
@ 2024-05-19 0:45 ` pinskia at gcc dot gnu.org
2024-05-19 1:08 ` rudi at heitbaum dot com
2024-05-20 12:03 ` wilco at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-05-19 0:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Error: bad immediate value |[14/15 Regression] Error:
|for 8-bit offset - armv7ve |bad immediate value for
| |8-bit offset - armv7ve
Status|WAITING |NEW
Target Milestone|--- |14.2
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I suspect r14-4365-g0731889c026bfe is the cause.
```
(define_insn "arm_atomic_loaddi2_ldrd"
[(set (match_operand:DI 0 "register_operand" "=r")
(unspec_volatile:DI
- [(match_operand:DI 1 "arm_sync_memory_operand" "Q")]
+ [(match_operand:DI 1 "memory_operand" "m")]
VUNSPEC_LDRD_ATOMIC))]
"ARM_DOUBLEWORD_ALIGN && TARGET_HAVE_LPAE"
- "ldrd%?\t%0, %H0, %C1"
- [(set_attr "predicable" "yes")])
+ "ldrd\t%0, %H0, %1"
+)
```
Most likely that should have been `ldrd_strd_offset_operand/Do` . There might
be other places in that patch which made the same mistake too.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug target/115153] [14/15 Regression] Error: bad immediate value for 8-bit offset - armv7ve
2024-05-19 0:12 [Bug sanitizer/115153] New: Error: bad immediate value for 8-bit offset - armv7ve rudi at heitbaum dot com
` (5 preceding siblings ...)
2024-05-19 0:45 ` [Bug target/115153] [14/15 Regression] " pinskia at gcc dot gnu.org
@ 2024-05-19 1:08 ` rudi at heitbaum dot com
2024-05-20 12:03 ` wilco at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: rudi at heitbaum dot com @ 2024-05-19 1:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153
--- Comment #7 from rudi at heitbaum dot com ---
(In reply to Andrew Pinski from comment #6)
> I suspect r14-4365-g0731889c026bfe is the cause.
>
> ```
> (define_insn "arm_atomic_loaddi2_ldrd"
> [(set (match_operand:DI 0 "register_operand" "=r")
> (unspec_volatile:DI
> - [(match_operand:DI 1 "arm_sync_memory_operand" "Q")]
> + [(match_operand:DI 1 "memory_operand" "m")]
> VUNSPEC_LDRD_ATOMIC))]
> "ARM_DOUBLEWORD_ALIGN && TARGET_HAVE_LPAE"
> - "ldrd%?\t%0, %H0, %C1"
> - [(set_attr "predicable" "yes")])
> + "ldrd\t%0, %H0, %1"
> +)
> ```
>
> Most likely that should have been `ldrd_strd_offset_operand/Do` . There
> might be other places in that patch which made the same mistake too.
I can confirm that reverting
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0731889c026bfe;hp=bada3c27d855430af736de51439ce275cffda754
allows for the successful compile of both libsanitizer and kodi.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug target/115153] [14/15 Regression] Error: bad immediate value for 8-bit offset - armv7ve
2024-05-19 0:12 [Bug sanitizer/115153] New: Error: bad immediate value for 8-bit offset - armv7ve rudi at heitbaum dot com
` (6 preceding siblings ...)
2024-05-19 1:08 ` rudi at heitbaum dot com
@ 2024-05-20 12:03 ` wilco at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: wilco at gcc dot gnu.org @ 2024-05-20 12:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153
Wilco <wilco at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
CC| |wilco at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #8 from Wilco <wilco at gcc dot gnu.org> ---
Confirmed. Small example:
long long f(long long *p)
{
return __atomic_load_n (p+32, __ATOMIC_RELAXED);
}
It only fails on ARM and if the offset is between 256 and 1024. This is a
latent bug: arm_legitimate_index_p has an explicit check that disallows
anything over 256, but an earlier check for VALID_NEON_DREG_MODE oddly enough
allows DImode and a larger range. Moving the Neon check after LDRD check fixes
this.
Note using ldrd_strd_offset_operand/Do should also work, but the existing code
for 'm' is supposed to handle this correctly.
^ permalink raw reply [flat|nested] 9+ messages in thread