What is your exact configure command line?

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?

(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

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

(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)

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.

(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.

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.

The master branch has been updated by Wilco Dijkstra <wilco@gcc.gnu.org>:

https://gcc.gnu.org/g:44e5ecfd261afe72aa04eba4bf1a9ec782579cab

commit r15-1865-g44e5ecfd261afe72aa04eba4bf1a9ec782579cab
Author: Wilco Dijkstra <wilco.dijkstra@arm.com>
Date:   Fri Jul 5 17:31:25 2024 +0100

    Arm: Fix ldrd offset range [PR115153]
    
    The valid offset range of LDRD in arm_legitimate_index_p is increased to
    -1024..1020 if NEON is enabled since VALID_NEON_DREG_MODE includes DImode.
    Fix this by moving the LDRD check earlier.
    
    gcc:
            PR target/115153
            * config/arm/arm.cc (arm_legitimate_index_p): Move LDRD case before
            NEON.
            (thumb2_legitimate_index_p): Update comments.
            (output_move_neon): Use DFmode for vldr/vstr and non-checking
            adjust_address.
    
    gcc/testsuite:
            PR target/115153
            * gcc.target/arm/pr115153.c: Add new test.
            * lib/target-supports.exp: Add arm_arch_v7ve_neon target support.

The releases/gcc-14 branch has been updated by Wilco Dijkstra <wilco@gcc.gnu.org>:

https://gcc.gnu.org/g:83332e3f808b146ca06dbc6a91d15bd3e5650658

commit r14-10398-g83332e3f808b146ca06dbc6a91d15bd3e5650658
Author: Wilco Dijkstra <wilco.dijkstra@arm.com>
Date:   Fri Jul 5 17:31:25 2024 +0100

    Arm: Fix ldrd offset range [PR115153]
    
    The valid offset range of LDRD in arm_legitimate_index_p is increased to
    -1024..1020 if NEON is enabled since VALID_NEON_DREG_MODE includes DImode.
    Fix this by moving the LDRD check earlier.
    
    gcc:
            PR target/115153
            * config/arm/arm.cc (arm_legitimate_index_p): Move LDRD case before
            NEON.
            (thumb2_legitimate_index_p): Update comments.
            (output_move_neon): Use DFmode for vldr/vstr and non-checking
            adjust_address.
    
    gcc/testsuite:
            PR target/115153
            * gcc.target/arm/pr115153.c: Add new test.
            * lib/target-supports.exp: Add arm_arch_v7ve_neon target support.
    
    (cherry picked from commit 44e5ecfd261afe72aa04eba4bf1a9ec782579cab)

Fixed on trunk and GCC14.