[Bug target/111231] New: armhf: Miscompilation at O2 level

[Bug target/111231] New: armhf: Miscompilation at O2 level

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

            Bug ID: 111231
           Summary: armhf: Miscompilation at O2 level
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: malat at debian dot org
  Target Milestone: ---

highway test suite is currently failing on Debian/armhf with GCC 13.2.0.

350/502 Test #350:
HwyMulTestGroup/HwyMulTest.TestAllSatWidenMulPairwiseAdd/EMU128  # GetParam() =
2305843009213693952 ....................Subprocess aborted***Exception:   0.03
sec
Running main() from ./googletest/src/gtest_main.cc
Note: Google Test filter =
HwyMulTestGroup/HwyMulTest.TestAllSatWidenMulPairwiseAdd/EMU128
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from HwyMulTestGroup/HwyMulTest
[ RUN      ] HwyMulTestGroup/HwyMulTest.TestAllSatWidenMulPairwiseAdd/EMU128


i16x8 expect [0+ ->]:
  0x0000,0x0002,0x0000,0x0000,0x0000,0x0000,0x0000,
i16x8 actual [0+ ->]:
  0x0000,0x0004,0x0000,0x0000,0x0000,0x0000,0x0000,
Abort at ./hwy/tests/mul_test.cc:587: EMU128, i16x8 lane 1 mismatch: expected
'0x0002', got '0x0004'.

[Bug target/111231] armhf: Miscompilation at O2 level

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #1 from Mathieu Malaterre <malat at debian dot org> ---
Created attachment 55816
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55816&action=edit
Preprocessed source

% /usr/bin/c++ -save-temps -DHWY_STATIC_DEFINE -I/home/malat/highway -O2 -g
-DNDEBUG -fPIE -fvisibility=hidden -fvisibility-inlines-hidden
-Wno-builtin-macro-redefined -D__DATE__=\"redacted\"
-D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -fmerge-all-constants
-Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor
-fmath-errno -fno-exceptions -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard
-mfp16-format=ieee -DHWY_IS_TEST=1 -DGTEST_HAS_PTHREAD=1 -MD -MT
CMakeFiles/mul_test.dir/hwy/tests/mul_test.cc.o -MF
CMakeFiles/mul_test.dir/hwy/tests/mul_test.cc.o.d -o
CMakeFiles/mul_test.dir/hwy/tests/mul_test.cc.o -c
/home/malat/highway/hwy/tests/mul_test.cc

[Bug target/111231] armhf: Miscompilation at O2 level

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #2 from Mathieu Malaterre <malat at debian dot org> ---
reported upstream as:
* https://github.com/google/highway/issues/1683

[Bug target/111231] armhf: Miscompilation at O2 level (O1 is working)

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #3 from Mathieu Malaterre <malat at debian dot org> ---
creduce process started on amhdal.d.o machine:

% creduce check.sh mul_test.cc
===< 1797132 >===
running 3 interestingness tests in parallel
===< pass_unifdef :: 0 >===
(10.0 %, 31474 bytes)
[...]

will post result asap.

[Bug target/111231] armhf: Miscompilation at O2 level (O1 is working)

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #4 from Mathieu Malaterre <malat at debian dot org> ---
Intermediate result (creduce Debian/sid):

#include "hwy/tests/test_util-inl.h"
namespace hwy {
namespace HWY_NAMESPACE {
struct a {
  template <typename b, class c> void operator()(b, c d) {
    using e = MakeUnsigned<b>;
    using f = MakeWide<b>;
    RepartitionToWide<c> aa;
    using g = Vec<decltype(aa)>;
    using h = Vec<decltype(d)>;
    size_t z = Lanes(d);
    size_t j = Lanes(aa);
    RebindToUnsigned<decltype(d)> k;
    g l;
    h m;
    auto ab = AllocateAligned<f>(j), af = AllocateAligned<b>(z),
         u = AllocateAligned<b>(z);
    for (size_t n; 0;) {
      b ac = b(n);
      e o = e(ac);
      ab[0] = o;
    }
    auto ad = Set(d, LimitsMin<b>()), p = Set(d, LimitsMax<b>()),
         q = Set(k, LimitsMax<e>()), r = Set(aa, LimitsMin<f>()),
         s = Set(aa, LimitsMax<f>());
    b t, ae(0);
    for (size_t i = 0; i < z; i++) {
      auto ag(t), v(0 ? ag : ae), ah(v + 20);
      af[i] = u[i] = b(-ah);
    }
    auto w = Load(d, af.get());
    HWY_ASSERT_VEC_EQ(aa, s, SatWidenMulPairwiseAdd(aa, q, p));
    auto x = Load(d, u.get());
    HWY_ASSERT_VEC_EQ(
        aa, r,
        SatWidenMulPairwiseAdd(aa, BitCast(k, w), InterleaveLower(x, ad)));
  }
};
void y() { ForShrinkableVectors<a>()(int8_t()); }
} // namespace HWY_NAMESPACE
} // namespace hwy
int main() { hwy::N_EMU128::y(); }

[Bug target/111231] armhf: Miscompilation at O2 level (O1 is working)

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #5 from Mathieu Malaterre <malat at debian dot org> ---
Result from cvise (+manual editing):

c++ -Wfatal-errors -Wall -Wextra -Werror -o works -O1 -march=armv7-a
-mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee step7.cc
-> exit(0)

c++ -Wfatal-errors -Wall -Wextra -Werror -o fails -O2 -march=armv7-a
-mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee step7.cc
-> exit(42)

Where:

% cat step7.cc 
#include <inttypes.h>
#include <stddef.h>
#define HWY_MIN(a, b) a < b
template <size_t kBytes, typename From, typename To>
void CopyBytes(From from, To to) {
  __builtin_memcpy(to, from, kBytes);
}
template <typename From, typename To> void CopySameSize(From from, To to) {
  CopyBytes<sizeof(int)>(from, to);
}
struct Relations {
  using Wide = int16_t;
};
template <typename> using MakeWide = Relations::Wide;
#if 0
#else
#define HWY_LANES(T) (sizeof(T))
#endif
namespace detail {
constexpr size_t ScaleByPower(size_t N, int pow2) { return pow2 >= 0 ? N : 0; }
} // namespace detail
template <typename Lane, size_t N, int kPow2> struct Simd {
  using T = Lane;
  static constexpr size_t kWhole = N;
  static constexpr int kFrac = 0;
  static constexpr size_t kPrivateLanes = detail::ScaleByPower(kWhole, kFrac);
  constexpr size_t MaxBytes() { return kPrivateLanes; }
  template <typename> static constexpr size_t RepartitionLanes() {
    return sizeof(int);
  }
  template <int kNewPow2, size_t kNewMaxLanes>
  static constexpr size_t WholeN() {
    return detail::ScaleByPower(kNewMaxLanes, kNewPow2);
  }
  template <int kNewPow2, size_t kNewMaxLanes> static constexpr size_t NewN() {
    return WholeN<kNewPow2, kNewMaxLanes>();
  }
  template <typename> using Rebind = Simd;
  template <typename NewT>
  using Repartition =
      Simd<NewT, NewN<kPow2, RepartitionLanes<NewT>()>(), kPow2>;
};
namespace detail {
template <typename T, size_t N, int> struct ClampNAndPow2 {
  using type = Simd<T, HWY_MIN(N, 6), 3>;
};
template <typename T, size_t, int kPow2> struct CappedTagChecker {
  static constexpr size_t N = HWY_LANES(T);
  using type = typename ClampNAndPow2<T, N, kPow2>::type;
};
} // namespace detail
template <typename T, size_t kLimit, int kPow2 = 0>
using CappedTag = typename detail::CappedTagChecker<T, kLimit, kPow2>::type;
template <class D> using TFromD = typename D::T;
#define HWY_MAX_LANES_D(D) D::kPrivateLanes
template <class D> size_t MaxLanes(D) { return HWY_MAX_LANES_D(D); }
template <class D> size_t Lanes(D) { return HWY_MAX_LANES_D(D); }
template <class T, class D> using Rebind = typename D::Rebind<T>;
template <class D> using RebindToUnsigned = Rebind<D, D>;
template <class T, class D> using Repartition = typename D::Repartition<T>;
template <class D> using RepartitionToWide = Repartition<MakeWide<D>, D>;
#include <cmath>
#include <cstring>
#include <memory>
namespace hwy {
template <typename T, size_t> struct Vec128 {
  T raw[16 / sizeof(T)];
};
template <class D> Vec128<TFromD<D>, HWY_MAX_LANES_D(D)> Zero(D);
template <class D> using VFromD = decltype(Zero(D()));
template <class D, class VFrom> VFromD<D> BitCast(D, VFrom v) {
  VFromD<D> to;
  CopySameSize(&v, &to);
  return to;
}
template <class D, typename T2> VFromD<D> Set(D d, T2 t) {
  VFromD<D> v;
  for (size_t i = 0; i < MaxLanes(d); ++i)
    v.raw[i] = t;
  return v;
}
template <typename T, size_t N> Vec128<T, N> SaturatedAdd(Vec128<T, N> b) {
  Vec128<T, N> a;
  using TW = T;
  for (size_t i = 0; i < N; ++i)
    a.raw[i] = HWY_MIN(TW() + b.raw[i], T());
  return a;
}
template <class D> void Store(VFromD<D> v, D d, TFromD<D> *aligned) {
  CopyBytes<d.MaxBytes()>(v.raw, aligned);
}
template <class D> using Vec = decltype(Zero(D()));
template <class DI16, class VU8, class VI8>
Vec<DI16> SatWidenMulPairwiseAdd(DI16 di16, VU8 a, VI8 b) {
  RebindToUnsigned<decltype(di16)> du16;
  auto a1 = BitCast(du16, a), b1(BitCast(di16, b));
  return SaturatedAdd(a1);
}
using AllocPtr = void *(void *, size_t);
using FreePtr = void (*)(void *, void *);
void *AllocateAlignedBytes(size_t size, AllocPtr, void *) {
        return aligned_alloc(4096, size);

}
void FreeAlignedBytes(const void *ptr, FreePtr, void *) {
        free((void*)ptr);
}
AllocPtr *AllocateAlignedItems_alloc_ptr;
template <typename T> T *AllocateAlignedItems(size_t items) {
  size_t size = sizeof(T);
  bool is_pow2 = 0;
  size_t bits(size);
  size_t bytes = is_pow2 ? bits : items;
  return static_cast<T *>(
      AllocateAlignedBytes(bytes, AllocateAlignedItems_alloc_ptr, 0));
}
struct AlignedFreer {
  AlignedFreer(FreePtr free_ptr, void *opaque_ptr)
      : free_(free_ptr), opaque_ptr_(opaque_ptr) {}
  template <typename T> void operator()(T aligned_pointer) {
    FreeAlignedBytes(aligned_pointer, free_, opaque_ptr_);
  }
  FreePtr free_;
  void *opaque_ptr_;
};
template <typename T>
using AlignedFreeUniquePtr = std::unique_ptr<T, AlignedFreer>;
FreePtr AllocateAligned_free;
template <typename T>
AlignedFreeUniquePtr<T[]> AllocateAligned(size_t items, void *opaque) {
  T *__trans_tmp_1 = AllocateAlignedItems<T>(items);
  return AlignedFreeUniquePtr<T[]>(__trans_tmp_1,
                                   AlignedFreer(AllocateAligned_free, opaque));
}
template <typename T> AlignedFreeUniquePtr<T[]> AllocateAligned(size_t items) {
  return AllocateAligned<T>(items, nullptr);
}
void AssertArrayEqual2(void *a, void *b, size_t c, const char *, int) {
  if (memcmp(a, b, c))
    exit(42);
}
template <class n, typename o = TFromD<n>>
void p(n d, Vec<n> expected, Vec<n> actual, const char *ab, int ac) {
  size_t q = Lanes(d);
  auto r = AllocateAligned<o>(q), s = AllocateAligned<o>(q);
  Store(expected, d, r.get());
  Store(actual, d, s.get());
  AssertArrayEqual2(r.get(), s.get(), q, ab, ac);
}
#define t(d, expected, actual) p(d, expected, actual, __FILE__, __LINE__)
template <typename o, size_t u, class v> struct w {
  static void x(size_t ae, size_t af) {
    CappedTag<o, u> d;
    size_t ag = Lanes(d);
    if (ag < ae)
      return;
    if (af)
      v()(o(), d);
  }
};
struct y {
  template <typename b, class c> void operator()(b, c d) {
    RepartitionToWide<c> aa;
    size_t g = Lanes(d);
    RebindToUnsigned<decltype(d)> h;
    auto m = 0, j = Set(h, b()), k = Set(aa, 0);
    for (size_t i = 0; i < g; i++)
      t(aa, k, SatWidenMulPairwiseAdd(aa, j, m));
  }
};
template <int ah = 1> struct ai {
  template <typename o> void operator()(o) {
    size_t aj = ah;
    constexpr size_t ak HWY_LANES(o);
    size_t af = ak;
    w<o, ak, y>::x(aj, af);
  }
};
void l() { ai()(int8_t()); }
} // namespace hwy
int main() { hwy::l(); }

[Bug target/111231] [13/14 Regression] armhf: Miscompilation at O2 level (O1 is working)

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #6 from Mathieu Malaterre <malat at debian dot org> ---
Code in #c4 and #c5 are bogus. They also fails with g++-12. Let me start my
cvise machinery over again (may take some time).

[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-O2 is working)

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #7 from Mathieu Malaterre <malat at debian dot org> ---
new cvise setup started today:

% cvise check.sh widen_mul_test.cc
00:01:16 INFO ===< 1427429 >===
00:01:16 INFO running 4 interestingness tests in parallel
00:01:16 INFO INITIAL PASSES
00:01:16 INFO ===< IncludesPass >===

[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-O2 is working)

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #8 from Mathieu Malaterre <malat at debian dot org> ---
Created attachment 55990
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55990&action=edit
foo.cc

[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-O2 is working)

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #9 from Mathieu Malaterre <malat at debian dot org> ---
Created attachment 55991
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55991&action=edit
widen_mul_test.cc

[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-O2 is working)

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #10 from Mathieu Malaterre <malat at debian dot org> ---
I could not reduce to a single *.cc file. The function needs to be in an alt
file 'foo.cc'.

So could someone please compare:

g++ -std=c++11 -o works -O2 -g -Wfatal-errors -Werror -Wall -Wextra
-Wconversion -DNDEBUG -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard
-mfp16-format=ieee -Wno-psabi widen_mul_test.cc foo.cc


with:

g++ -std=c++11 -o fails -O2 -g -Wfatal-errors -DNDEBUG -fno-exceptions
-march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee -Wno-psabi
widen_mul_test.cc foo.cc

[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-O2 is working)

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #11 from Mathieu Malaterre <malat at debian dot org> ---
For reference:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-linux-gnueabihf/13/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 13.2.0-4'
--with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-sjlj-exceptions --with-arch=armv7-a+fp --with-float=hard
--with-mode=thumb --disable-werror --enable-checking=release
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (Debian 13.2.0-4) 
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-o' 'fails' '-O2' '-g' '-Wfatal-errors'
'-D' 'NDEBUG' '-fno-exceptions'  '-mfpu=neon-vfpv4' '-mfloat-abi=hard'
'-mfp16-format=ieee' '-Wno-psabi' '-shared-libgcc' '-mtls-dialect=gnu'
'-mthumb' '-mlibarch=armv7-a+neon-vfpv4' '-march=armv7-a+neon-vfpv4' '-dumpdir'
'fails-'
 /usr/libexec/gcc/arm-linux-gnueabihf/13/cc1plus -quiet -v -imultilib .
-imultiarch arm-linux-gnueabihf -D_GNU_SOURCE -D NDEBUG widen_mul_test.cc
-quiet -dumpdir fails- -dumpbase widen_mul_test.cc -dumpbase-ext .cc
-mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee -mtls-dialect=gnu -mthumb
-mlibarch=armv7-a+neon-vfpv4 -march=armv7-a+neon-vfpv4 -g -O2 -Wfatal-errors
-Wno-psabi -std=c++11 -version -fno-exceptions -o /tmp/ccGJymG4.s
GNU C++11 (Debian 13.2.0-4) version 13.2.0 (arm-linux-gnueabihf)
        compiled by GNU C version 13.2.0, GMP version 6.3.0, MPFR version
4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "/usr/include/arm-linux-gnueabihf/c++/13"
ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabihf"
ignoring nonexistent directory
"/usr/lib/gcc/arm-linux-gnueabihf/13/include-fixed/arm-linux-gnueabihf"
ignoring nonexistent directory
"/usr/lib/gcc/arm-linux-gnueabihf/13/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/arm-linux-gnueabihf/13/../../../../arm-linux-gnueabihf/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/13
 /usr/include/arm-linux-gnueabihf/c++/13
 /usr/include/c++/13/backward
 /usr/lib/gcc/arm-linux-gnueabihf/13/include
 /usr/local/include
 /usr/include/arm-linux-gnueabihf
 /usr/include
End of search list.
Compiler executable checksum: 613e27b019f0c34e86771fffeca58c78
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-o' 'fails' '-O2' '-g' '-Wfatal-errors'
'-D' 'NDEBUG' '-fno-exceptions'  '-mfpu=neon-vfpv4' '-mfloat-abi=hard'
'-mfp16-format=ieee' '-Wno-psabi' '-shared-libgcc' '-mtls-dialect=gnu'
'-mthumb' '-mlibarch=armv7-a+neon-vfpv4' '-march=armv7-a+neon-vfpv4' '-dumpdir'
'fails-'
 as -v -march=armv7-a+neon-vfpv4 -mfloat-abi=hard -mfpu=neon-vfpv4 -meabi=5 -o
/tmp/ccUMFDCj.o /tmp/ccGJymG4.s
GNU assembler version 2.41 (arm-linux-gnueabihf) using BFD version (GNU
Binutils for Debian) 2.41
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-o' 'fails' '-O2' '-g' '-Wfatal-errors'
'-D' 'NDEBUG' '-fno-exceptions'  '-mfpu=neon-vfpv4' '-mfloat-abi=hard'
'-mfp16-format=ieee' '-Wno-psabi' '-shared-libgcc' '-mtls-dialect=gnu'
'-mthumb' '-mlibarch=armv7-a+neon-vfpv4' '-march=armv7-a+neon-vfpv4' '-dumpdir'
'fails-'
 /usr/libexec/gcc/arm-linux-gnueabihf/13/cc1plus -quiet -v -imultilib .
-imultiarch arm-linux-gnueabihf -D_GNU_SOURCE -D NDEBUG foo.cc -quiet -dumpdir
fails- -dumpbase foo.cc -dumpbase-ext .cc -mfpu=neon-vfpv4 -mfloat-abi=hard
-mfp16-format=ieee -mtls-dialect=gnu -mthumb -mlibarch=armv7-a+neon-vfpv4
-march=armv7-a+neon-vfpv4 -g -O2 -Wfatal-errors -Wno-psabi -std=c++11 -version
-fno-exceptions -o /tmp/ccGJymG4.s
GNU C++11 (Debian 13.2.0-4) version 13.2.0 (arm-linux-gnueabihf)
        compiled by GNU C version 13.2.0, GMP version 6.3.0, MPFR version
4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "/usr/include/arm-linux-gnueabihf/c++/13"
ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabihf"
ignoring nonexistent directory
"/usr/lib/gcc/arm-linux-gnueabihf/13/include-fixed/arm-linux-gnueabihf"
ignoring nonexistent directory
"/usr/lib/gcc/arm-linux-gnueabihf/13/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/arm-linux-gnueabihf/13/../../../../arm-linux-gnueabihf/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/13
 /usr/include/arm-linux-gnueabihf/c++/13
 /usr/include/c++/13/backward
 /usr/lib/gcc/arm-linux-gnueabihf/13/include
 /usr/local/include
 /usr/include/arm-linux-gnueabihf
 /usr/include
End of search list.
Compiler executable checksum: 613e27b019f0c34e86771fffeca58c78
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-o' 'fails' '-O2' '-g' '-Wfatal-errors'
'-D' 'NDEBUG' '-fno-exceptions'  '-mfpu=neon-vfpv4' '-mfloat-abi=hard'
'-mfp16-format=ieee' '-Wno-psabi' '-shared-libgcc' '-mtls-dialect=gnu'
'-mthumb' '-mlibarch=armv7-a+neon-vfpv4' '-march=armv7-a+neon-vfpv4' '-dumpdir'
'fails-'
 as -v -march=armv7-a+neon-vfpv4 -mfloat-abi=hard -mfpu=neon-vfpv4 -meabi=5 -o
/tmp/cchSFWaw.o /tmp/ccGJymG4.s
GNU assembler version 2.41 (arm-linux-gnueabihf) using BFD version (GNU
Binutils for Debian) 2.41
COMPILER_PATH=/usr/libexec/gcc/arm-linux-gnueabihf/13/:/usr/libexec/gcc/arm-linux-gnueabihf/13/:/usr/libexec/gcc/arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/13/:/usr/lib/gcc/arm-linux-gnueabihf/
LIBRARY_PATH=/usr/lib/gcc/arm-linux-gnueabihf/13/:/usr/lib/gcc/arm-linux-gnueabihf/13/../../../arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/13/../../../:/lib/arm-linux-gnueabihf/:/lib/:/usr/lib/arm-linux-gnueabihf/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-o' 'fails' '-O2' '-g' '-Wfatal-errors'
'-D' 'NDEBUG' '-fno-exceptions'  '-mfpu=neon-vfpv4' '-mfloat-abi=hard'
'-mfp16-format=ieee' '-Wno-psabi' '-shared-libgcc' '-mtls-dialect=gnu'
'-mthumb' '-mlibarch=armv7-a+neon-vfpv4' '-march=armv7-a+neon-vfpv4' '-dumpdir'
'fails.'
 /usr/libexec/gcc/arm-linux-gnueabihf/13/collect2 -plugin
/usr/libexec/gcc/arm-linux-gnueabihf/13/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/arm-linux-gnueabihf/13/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccEZU560.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id
--eh-frame-hdr -dynamic-linker /lib/ld-linux-armhf.so.3 -X --hash-style=gnu
--as-needed -m armelf_linux_eabi -pie -o fails
/usr/lib/gcc/arm-linux-gnueabihf/13/../../../arm-linux-gnueabihf/Scrt1.o
/usr/lib/gcc/arm-linux-gnueabihf/13/../../../arm-linux-gnueabihf/crti.o
/usr/lib/gcc/arm-linux-gnueabihf/13/crtbeginS.o
-L/usr/lib/gcc/arm-linux-gnueabihf/13
-L/usr/lib/gcc/arm-linux-gnueabihf/13/../../../arm-linux-gnueabihf
-L/usr/lib/gcc/arm-linux-gnueabihf/13/../../.. -L/lib/arm-linux-gnueabihf
-L/usr/lib/arm-linux-gnueabihf /tmp/ccUMFDCj.o /tmp/cchSFWaw.o -lstdc++ -lm
-lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/arm-linux-gnueabihf/13/crtendS.o
/usr/lib/gcc/arm-linux-gnueabihf/13/../../../arm-linux-gnueabihf/crtn.o
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-o' 'fails' '-O2' '-g' '-Wfatal-errors'
'-D' 'NDEBUG' '-fno-exceptions'  '-mfpu=neon-vfpv4' '-mfloat-abi=hard'
'-mfp16-format=ieee' '-Wno-psabi' '-shared-libgcc' '-mtls-dialect=gnu'
'-mthumb' '-mlibarch=armv7-a+neon-vfpv4' '-march=armv7-a+neon-vfpv4' '-dumpdir'
'fails.'

[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-O2 is working)

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #12 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Mathieu Malaterre from comment #10)
> I could not reduce to a single *.cc file. The function needs to be in an alt
> file 'foo.cc'.

Can you try copying the functions provided in foo.cc into the test case but and
noipa attribute for them?

[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

Mathieu Malaterre <malat at debian dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #55816|0                           |1
        is obsolete|                            |
  Attachment #55990|0                           |1
        is obsolete|                            |
  Attachment #55991|0                           |1
        is obsolete|                            |

--- Comment #13 from Mathieu Malaterre <malat at debian dot org> ---
Created attachment 56065
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56065&action=edit
widen_mul_test.cc

[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #14 from Mathieu Malaterre <malat at debian dot org> ---
(In reply to Xi Ruoyao from comment #12)
> (In reply to Mathieu Malaterre from comment #10)
> > I could not reduce to a single *.cc file. The function needs to be in an alt
> > file 'foo.cc'.
> 
> Can you try copying the functions provided in foo.cc into the test case but
> and noipa attribute for them?

Updated, thanks for the pointer. See comment #13.

Here is what I see on my side (Debian/sid/armhf):

$ g++-13 -std=c++11 -o works -O2 -fno-tree-vectorize -g -Wfatal-errors -Werror
-Wall -Wextra -Wconversion -Wpedantic -DNDEBUG -fno-exceptions -march=armv7-a
-mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee widen_mul_test.cc
-> success

$ valgrind --leak-check=yes --error-exitcode=1 ./works
-> success (no leak)

$ clang++-16 -std=c++11 -Wfatal-errors -Werror -Wall -Wextra -Wconversion
-Wno-unknown-attributes -O2 -DNDEBUG -fno-exceptions -march=armv7-a
-mfpu=neon-vfpv4 -mfloat-abi=hard -o works0 widen_mul_test.cc
-> success

Now simply remove `-fno-tree-vectorize`:

$ g++ -std=c++11 -o fails -O2 -g -Wfatal-errors -DNDEBUG -fno-exceptions
-march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee
widen_mul_test.cc
-> failure (abort)

[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

Mathieu Malaterre <malat at debian dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #56065|0                           |1
        is obsolete|                            |

--- Comment #15 from Mathieu Malaterre <malat at debian dot org> ---
Created attachment 56066
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56066&action=edit
widen_mul_test.cc

[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #16 from Mathieu Malaterre <malat at debian dot org> ---
Could someone from the GCC/armhf team please at least 'confirm' this bug report
? Thanks

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |14.0
      Known to work|                            |11.4.1
            Summary|armhf: Miscompilation with  |[12/13/14 regression]
                   |-O2/-fno-exceptions level   |armhf: Miscompilation with
                   |(-fno-tree-vectorize is     |-O2/-fno-exceptions level
                   |working)                    |(-fno-tree-vectorize is
                   |                            |working)

--- Comment #17 from Sam James <sjames at gcc dot gnu.org> ---
Adding missing regression markers. 11 is fine for me.

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.4
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-03-17

--- Comment #18 from Sam James <sjames at gcc dot gnu.org> ---
Confirmed.

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu.org
           Priority|P3                          |P1

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #19 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
This is another problem with (I suspect) incorrect aliasing information.  If I
compile with -fno-strict-aliasing, I get

  88:   f4432a1f        vst1.8  {d18-d19}, [r3 :64]     // {>E}   SP+96/16
  8c:   f4420a1f        vst1.8  {d16-d17}, [r2 :64]     // {>A}   SP+32/16
  90:   e893000f        ldm     r3, {r0, r1, r2, r3}    // {<E}   SP+96/16
  94:   e884000f        stm     r4, {r0, r1, r2, r3}    // {>G}   SP+128/16
  98:   eddd0b20        vldr    d16, [sp, #128] ; 0x80  // {<G.l} SP+128/8
  9c:   eddd1b22        vldr    d17, [sp, #136] ; 0x88  // {<G.h} SP+136/8
  a0:   e88c000f        stm     ip, {r0, r1, r2, r3}    // {>B}   SP+48/16
  a4:   e28dc040        add     ip, sp, #64     ; 0x40
  a8:   e885000f        stm     r5, {r0, r1, r2, r3}    // {>F}   SP+112/16
  ac:   f2d80570        vshl.s16        q8, q8, #8
  b0:   f3f503e0        vneg.s16        q8, q8
  b4:   edcd0b20        vstr    d16, [sp, #128] ; 0x80  // {>G.l} SP+128/8
  b8:   edcd1b22        vstr    d17, [sp, #136] ; 0x88  // {>G.h} SP+136/8
  bc:   e894000f        ldm     r4, {r0, r1, r2, r3}    // {<G}   SP+128/16
  c0:   e88c000f        stm     ip, {r0, r1, r2, r3}    // {>C}   SP+64/16
  c4:   e28dc050        add     ip, sp, #80     ; 0x50
  c8:   e88c000f        stm     ip, {r0, r1, r2, r3}    // {>D}   SP+80/16
  cc:   e885000f        stm     r5, {r0, r1, r2, r3}    // {>F}   SP+112/16

I've annotated each memory access with its stack address and labeled each
16-byte slot from A to G.

With -fstrict-aliasing this becomes:

  88:   f4420a1f        vst1.8  {d16-d17}, [r2 :64]     // {>A}   SP+32/16
  8c:   eddd0b20        vldr    d16, [sp, #128] ; 0x80  // {<G.l} SP+128/8     
!
  90:   eddd1b22        vldr    d17, [sp, #136] ; 0x88  // {<G.h} SP+136/8     
!
  94:   f4432a1f        vst1.8  {d18-d19}, [r3 :64]     // {>E}   SP+96/16
  98:   e893000f        ldm     r3, {r0, r1, r2, r3}    // {<E}   SP+96/16
  9c:   e88c000f        stm     ip, {r0, r1, r2, r3}    // {>B}   SP+48/16
  a0:   e28dc040        add     ip, sp, #64     ; 0x40
  a4:   f2d80570        vshl.s16        q8, q8, #8
  a8:   e884000f        stm     r4, {r0, r1, r2, r3}    // {>G}   SP+128/16    
!
  ac:   e885000f        stm     r5, {r0, r1, r2, r3}    // {>F}   SP+112/16
  b0:   f3f503e0        vneg.s16        q8, q8
  b4:   edcd0b20        vstr    d16, [sp, #128] ; 0x80  // {>G.l} SP+128/8
  b8:   edcd1b22        vstr    d17, [sp, #136] ; 0x88  // {>G.h} SP+136/8
  bc:   e894000f        ldm     r4, {r0, r1, r2, r3}    // {<G}   SP+128/16
  c0:   e88c000f        stm     ip, {r0, r1, r2, r3}    // {>C}   SP+64/16
  c4:   e28dc050        add     ip, sp, #80     ; 0x50
  c8:   e88c000f        stm     ip, {r0, r1, r2, r3}    // {>D}   SP+80/16
  cc:   e885000f        stm     r5, {r0, r1, r2, r3}    // {>F}   SP+112/16

And we see that the initial store to G has been moved after the reads from it. 
I'm still digging, but it may be pertinent that the reads have been split into
two separate instructions; perhaps when the split was done the alias sets
weren't copied correctly.

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #20 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Created attachment 57928
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57928&action=edit
fully preprocessed testcase

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #21 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
With my new testcase, compiled on an arm-none-eabi cross with 

cc1plus ../hwy-pr111231-cpp.cc -mfpu=neon-vfpv4 -mfloat-abi=hard
-mfp16-format=ieee -marm -mlibarch=armv7-a+neon-vfpv4 -march=armv7-a+neon-vfpv4
-O2 -fPIE -fvisibility=hidden -fvisibility-inlines-hidden -fmerge-all-constants
-fmath-errno -fno-exceptions

The critical sequence, at the end of gimple optimization is:

  v = b;
  MEM <unsigned char[16]> [(char * {ref-all})&D.33805] = MEM <unsigned
char[16]> [(char * {ref-all})&v];
  v ={v} {CLOBBER(eol)};
  v = D.33805;
  vect__239.652_700 = MEM <vector(8) short int> [(short int *)&v];
  vect__240.653_702 = vect__239.652_700 << 8;

This generates the following (pseudo) rtl:

; D.33805 = _179
  113: r215:SI=r109:SI-0x10
  114: {r0:SI..r3:SI} = [r215:SI (0 MEM <unsigned char[16]> [(char *
{ref-all})_179]+0 S4 A64)]
  112: r214:SI=r109:SI-0x60
  115: [r214:SI (0 MEM <unsigned char[16]> [(char * {ref-all})&D.33805]+0 S4
A64)] = {r0:SI..r3:SI}
; _179 = D.33805
  117: r217:SI=r109:SI-0x60
  118: {r0:SI..r3:SI} = [r217:SI (2 D.33805+0 S4 A64)]
  116: r216:SI=r109:SI-0x10
* 119: [r216:SI (2 MEM[(struct Vec128<short int, 8> *)_179]+0 S4 A64)] =
{r0:SI..r3:SI}
; r218 = _179
* 120: r218:V8HI=[r109:SI-0x10 (3 MEM <vector(8) short int> [(short int
*)_179]+0 S16 A64)]
  121: r178:V8HI=unspec[r218:V8HI,const_vector] 451

The two key instructions have been starred. 

Things proceed OK until sched2, at which point, when building the dependencies,
we fail to create a link between i119 and i120.  I've tracked this as far as
ptr_deref_may_alias_decl_p (), where the call to may_be_aliased () decides that
D.33805 cannot be aliased and thus there's no dependency.  But it's not clear
to me why we've tracked back to the copy before the load of interest, nor why,
at this point, we're looking at tree addressability to decide whether or not
there are memory dependencies here.

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #22 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(Previous analysis is based on gcc-13 branch)

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #23 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
#0  ptr_deref_may_alias_decl_p (ptr=0x7ffff5e0c678, decl=0x7ffff5dff000)
    at /home/rearnsha/gnusrc/gcc-cross/gcc-13/gcc/tree-ssa-alias.cc:295
#1  0x0000000001768173 in indirect_ref_may_alias_decl_p (ref1=0x7ffff5e9ad98, 
    base1=0x7ffff5e9ad98, offset1=..., max_size1=..., size1=..., 
    ref1_alias_set=3, base1_alias_set=3, ref2=0x7ffff5deae60, 
    base2=0x7ffff5dff000, offset2=..., max_size2=..., size2=..., 
    ref2_alias_set=0, base2_alias_set=0, tbaa_p=false)
    at /home/rearnsha/gnusrc/gcc-cross/gcc-13/gcc/tree-ssa-alias.cc:2102
#2  0x0000000001769541 in refs_may_alias_p_2 (ref1=0x7fffffffceb0, 
    ref2=0x7fffffffce70, tbaa_p=false)
    at /home/rearnsha/gnusrc/gcc-cross/gcc-13/gcc/tree-ssa-alias.cc:2505
#3  0x000000000176968a in refs_may_alias_p_1 (ref1=0x7fffffffce70, 
    ref2=0x7fffffffceb0, tbaa_p=false)
    at /home/rearnsha/gnusrc/gcc-cross/gcc-13/gcc/tree-ssa-alias.cc:2534
#4  0x0000000000f7bf7d in rtx_refs_may_alias_p (x=0x7ffff5ed3b40, 
    mem=0x7ffff5e9c9d8, tbaa_p=true)
    at /home/rearnsha/gnusrc/gcc-cross/gcc-13/gcc/alias.cc:366
#5  0x0000000000f8243b in true_dependence_1 (mem=0x7ffff5e9c9d8, 
    mem_mode=E_SImode, mem_addr=0x7ffff5e9c9c0, x=0x7ffff5ed3b40, 
    x_addr=0x7ffff5ed3b28, mem_canonicalized=false)

Where (in true_dependence_1):
p mem
$96 = (const_rtx) 0x7ffff5e9c9d8
(gdb) pr
(mem/c:SI (plus:SI (reg/f:SI 14 lr [214])
        (const_int 4 [0x4])) [0 MEM <unsigned char[16]> [(char *
{ref-all})&D.33805]+4 S4 A32])

p x
$97 = (const_rtx) 0x7ffff5ed3b40
(gdb) pr
(mem/c:V8HI (plus:SI (reg/f:SI 13 sp)
        (const_int 256 [0x100])) [3 MEM <vector(8) short int> [(short int
*)_179]+0 S16 A64])

in refs_may_alias_p_1:
p *ref1
$99 = {ref = 0x7ffff5e9ad98, base = 0x7ffff5e9ad98, 
  offset = {<poly_int_pod<1, long>> = {coeffs = {0}}, <No data fields>}, 
  size = {<poly_int_pod<1, long>> = {coeffs = {128}}, <No data fields>}, 
  max_size = {<poly_int_pod<1, long>> = {coeffs = {128}}, <No data fields>}, 
  ref_alias_set = 3, base_alias_set = 3, volatile_p = false}
p *ref2
$100 = {ref = 0x7ffff5deae60, base = 0x7ffff5dff000, 
  offset = {<poly_int_pod<1, long>> = {coeffs = {32}}, <No data fields>}, 
  size = {<poly_int_pod<1, long>> = {coeffs = {32}}, <No data fields>}, 
  max_size = {<poly_int_pod<1, long>> = {coeffs = {128}}, <No data fields>}, 
  ref_alias_set = 0, base_alias_set = 0, volatile_p = false}

p ref1->ref
$101 = (tree) 0x7ffff5e9ad98
(gdb) pt
 <mem_ref 0x7ffff5e9ad98
    type <vector_type 0x7ffff752d7e0
        type <integer_type 0x7ffff7405498 short int sizes-gimplified public
type_6 HI
            size <integer_cst 0x7ffff73fb4b0 constant 16>
            unit-size <integer_cst 0x7ffff73fb4c8 constant 2>
            align:16 warn_if_not_align:0 symtab:0 alias-set 3 canonical-type
0x7ffff7405498 precision:16 min <integer_cst 0x7ffff73fb468 -32768> max
<integer_cst 0x7ffff73fb480 32767>
            pointer_to_this <pointer_type 0x7ffff75b4f18> reference_to_this
<reference_type 0x7ffff66010a8>>
        V8HI
        size <integer_cst 0x7ffff73fb618 constant 128>
        unit-size <integer_cst 0x7ffff73fb630 constant 16>
        align:64 warn_if_not_align:0 symtab:0 alias-set 3 canonical-type
0x7ffff752d7e0 nunits:8
        pointer_to_this <pointer_type 0x7ffff62ff1f8>>

    arg:0 <ssa_name 0x7ffff5e0c678
        type <pointer_type 0x7ffff740c150 type <void_type 0x7ffff740c0a8 void>
            sizes-gimplified public unsigned type_6 SI
            size <integer_cst 0x7ffff73fb2b8 constant 32>
            unit-size <integer_cst 0x7ffff73fb2d0 constant 4>
            align:32 warn_if_not_align:0 symtab:0 alias-set 12 canonical-type
0x7ffff740c150
            pointer_to_this <pointer_type 0x7ffff74175e8> reference_to_this
<reference_type 0x7ffff67fba80>>
        var <var_decl 0x7ffff5e875a0 D.34164>
        def_stmt 
        version:179
        ptr-info 0x7ffff5e71468>
    arg:1 <integer_cst 0x7ffff69b7bb8 type <pointer_type 0x7ffff75b4f18>
constant 0>>

p ref1->base
$102 = (tree) 0x7ffff5e9ad98
(gdb) pt
 <mem_ref 0x7ffff5e9ad98
    type <vector_type 0x7ffff752d7e0
        type <integer_type 0x7ffff7405498 short int sizes-gimplified public
type_6 HI
            size <integer_cst 0x7ffff73fb4b0 constant 16>
            unit-size <integer_cst 0x7ffff73fb4c8 constant 2>
            align:16 warn_if_not_align:0 symtab:0 alias-set 3 canonical-type
0x7ffff7405498 precision:16 min <integer_cst 0x7ffff73fb468 -32768> max
<integer_cst 0x7ffff73fb480 32767>
            pointer_to_this <pointer_type 0x7ffff75b4f18> reference_to_this
<reference_type 0x7ffff66010a8>>
        V8HI
        size <integer_cst 0x7ffff73fb618 constant 128>
        unit-size <integer_cst 0x7ffff73fb630 constant 16>
        align:64 warn_if_not_align:0 symtab:0 alias-set 3 canonical-type
0x7ffff752d7e0 nunits:8
        pointer_to_this <pointer_type 0x7ffff62ff1f8>>

    arg:0 <ssa_name 0x7ffff5e0c678
        type <pointer_type 0x7ffff740c150 type <void_type 0x7ffff740c0a8 void>
            sizes-gimplified public unsigned type_6 SI
            size <integer_cst 0x7ffff73fb2b8 constant 32>
            unit-size <integer_cst 0x7ffff73fb2d0 constant 4>
            align:32 warn_if_not_align:0 symtab:0 alias-set 12 canonical-type
0x7ffff740c150
            pointer_to_this <pointer_type 0x7ffff74175e8> reference_to_this
<reference_type 0x7ffff67fba80>>
        var <var_decl 0x7ffff5e875a0 D.34164>
        def_stmt 
        version:179
        ptr-info 0x7ffff5e71468>
    arg:1 <integer_cst 0x7ffff69b7bb8 type <pointer_type 0x7ffff75b4f18>
constant 0>>

p ref2->ref
$103 = (tree) 0x7ffff5deae60
(gdb) pt
 <mem_ref 0x7ffff5deae60
    type <array_type 0x7ffff6322dc8
        type <integer_type 0x7ffff7405348 unsigned char sizes-gimplified public
unsigned type_6 QI
            size <integer_cst 0x7ffff73fb3f0 constant 8>
            unit-size <integer_cst 0x7ffff73fb408 constant 1>
            align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff7405348 precision:8 min <integer_cst 0x7ffff73fb420 0> max <integer_cst
0x7ffff73fb3c0 255>>
        BLK
        size <integer_cst 0x7ffff73fb618 constant 128>
        unit-size <integer_cst 0x7ffff73fb630 constant 16>
        user align:16 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff6322d20
        domain <integer_type 0x7ffff6b33d20 type <integer_type 0x7ffff7405000
sizetype>
            sizes-gimplified public type_6 SI
            size <integer_cst 0x7ffff73fb2b8 constant 32>
            unit-size <integer_cst 0x7ffff73fb2d0 constant 4>
            align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff6b33d20 precision:32 min <integer_cst 0x7ffff73fb2e8 0> max <integer_cst
0x7ffff72eeaf8 15>>
        pointer_to_this <pointer_type 0x7ffff62fff18>>

    arg:0 <addr_expr 0x7ffff5de0780
        type <pointer_type 0x7ffff6716930 type <record_type 0x7ffff66d77e0
VFromD>
            public unsigned SI size <integer_cst 0x7ffff73fb2b8 32> unit-size
<integer_cst 0x7ffff73fb2d0 4>
            align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff66db5e8>

        arg:0 <var_decl 0x7ffff5dff000 D.33805 type <record_type 0x7ffff66d7e70
Vec128>
            used ignored BLK ../hwy-pr111231-cpp.cc:4461:27 size <integer_cst
0x7ffff73fb618 128> unit-size <integer_cst 0x7ffff73fb630 16>
            align:64 warn_if_not_align:0 context <function_decl 0x7ffff5da8c00
operator().constprop> abstract_origin <var_decl 0x7ffff6238e10 D.30944>
            (mem/c:BLK (plus:SI (reg/f:SI 109 virtual-stack-vars)
        (const_int -96 [0xffffffffffffffa0])) [2 D.33805+0 S16 A64])>
        ../hwy-pr111231-cpp.cc:4346:16 start: ../hwy-pr111231-cpp.cc:4346:3
finish: ../hwy-pr111231-cpp.cc:4346:24>
    arg:1 <integer_cst 0x7ffff6227660 type <pointer_type 0x7ffff6231888>
constant 0>>
p ref2->base
$104 = (tree) 0x7ffff5dff000
(gdb) pt
 <var_decl 0x7ffff5dff000 D.33805
    type <record_type 0x7ffff66d7e70 Vec128 sizes-gimplified needs-constructing
cxx-odr-p type_5 type_6 BLK
        size <integer_cst 0x7ffff73fb618 constant 128>
        unit-size <integer_cst 0x7ffff73fb630 constant 16>
        align:16 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x7ffff66d7e70
        fields <function_decl 0x7ffff66e7300 __ct  type <method_type
0x7ffff66e6bd0>
            abstract external autoinline decl_3 decl_5 decl_8 SI
../hwy-pr111231-cpp.cc:4332:40 align:32 warn_if_not_align:0 context
<record_type 0x7ffff66d7e70 Vec128>
            full-name "constexpr hwy::{anonymous}::Vec128<short int,
8>::Vec128(hwy::{anonymous}::Vec128<short int, 8>&&) noexcept
(<uninstantiated>)"
            not-really-extern chain <function_decl 0x7ffff66e7500 __ct_base >>
context <namespace_decl 0x7ffff6cda000 D.12551>
        full-name "struct hwy::{anonymous}::Vec128<short int, 8>"
        needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=1
interface-unknown
        pointer_to_this <pointer_type 0x7ffff66db5e8> reference_to_this
<reference_type 0x7ffff66e69d8> chain <type_decl 0x7ffff66c7ed8 Vec128>>
    used ignored BLK ../hwy-pr111231-cpp.cc:4461:27 size <integer_cst
0x7ffff73fb618 128> unit-size <integer_cst 0x7ffff73fb630 16>
    align:64 warn_if_not_align:0 context <function_decl 0x7ffff5da8c00
operator().constprop> abstract_origin <var_decl 0x7ffff6238e10 D.30944>
    (mem/c:BLK (plus:SI (reg/f:SI 109 virtual-stack-vars)
        (const_int -96 [0xffffffffffffffa0])) [2 D.33805+0 S16 A64])>

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #24 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #21)
> With my new testcase, compiled on an arm-none-eabi cross with 
> 
> cc1plus ../hwy-pr111231-cpp.cc -mfpu=neon-vfpv4 -mfloat-abi=hard
> -mfp16-format=ieee -marm -mlibarch=armv7-a+neon-vfpv4
> -march=armv7-a+neon-vfpv4 -O2 -fPIE -fvisibility=hidden
> -fvisibility-inlines-hidden -fmerge-all-constants -fmath-errno
> -fno-exceptions
> 
> The critical sequence, at the end of gimple optimization is:
> 
>   v = b;
>   MEM <unsigned char[16]> [(char * {ref-all})&D.33805] = MEM <unsigned
> char[16]> [(char * {ref-all})&v];
>   v ={v} {CLOBBER(eol)};
>   v = D.33805;
>   vect__239.652_700 = MEM <vector(8) short int> [(short int *)&v];
>   vect__240.653_702 = vect__239.652_700 << 8;
> 
> This generates the following (pseudo) rtl:
> 
> ; D.33805 = _179
>   113: r215:SI=r109:SI-0x10
>   114: {r0:SI..r3:SI} = [r215:SI (0 MEM <unsigned char[16]> [(char *
> {ref-all})_179]+0 S4 A64)]
>   112: r214:SI=r109:SI-0x60
>   115: [r214:SI (0 MEM <unsigned char[16]> [(char * {ref-all})&D.33805]+0 S4
> A64)] = {r0:SI..r3:SI}
> ; _179 = D.33805
>   117: r217:SI=r109:SI-0x60
>   118: {r0:SI..r3:SI} = [r217:SI (2 D.33805+0 S4 A64)]
>   116: r216:SI=r109:SI-0x10
> * 119: [r216:SI (2 MEM[(struct Vec128<short int, 8> *)_179]+0 S4 A64)] =
> {r0:SI..r3:SI}
> ; r218 = _179
> * 120: r218:V8HI=[r109:SI-0x10 (3 MEM <vector(8) short int> [(short int
> *)_179]+0 S16 A64)]
>   121: r178:V8HI=unspec[r218:V8HI,const_vector] 451
> 
> The two key instructions have been starred. 
> 
> Things proceed OK until sched2, at which point, when building the
> dependencies, we fail to create a link between i119 and i120.  I've tracked
> this as far as ptr_deref_may_alias_decl_p (), where the call to
> may_be_aliased () decides that D.33805 cannot be aliased and thus there's no
> dependency.  But it's not clear to me why we've tracked back to the copy
> before the load of interest, nor why, at this point, we're looking at tree
> addressability to decide whether or not there are memory dependencies here.

This making it sound like one of the -fstack-reuse= issues (see the linked bug
reports from PR 111843). Does -fstack-reuse=none help?

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think it's more interesting why

* 119: [r216:SI (2 MEM[(struct Vec128<short int, 8> *)_179]+0 S4 A64)] =
{r0:SI..r3:SI}

isn't considered as dependence?  Why does the earlier insn even come into
play?  What's the breaking transform?  I guess insn 119 and 120 are
exchanged?

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #26 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #25)
> I think it's more interesting why
> 
> * 119: [r216:SI (2 MEM[(struct Vec128<short int, 8> *)_179]+0 S4 A64)] =
> {r0:SI..r3:SI}
> 
> isn't considered as dependence?  Why does the earlier insn even come into
> play?  What's the breaking transform?  I guess insn 119 and 120 are
> exchanged?

Because 119 was deleted by postreload.  Doh! I should have spotted that.

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #27 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #26)
> (In reply to Richard Biener from comment #25)
> > I think it's more interesting why
> > 
> > * 119: [r216:SI (2 MEM[(struct Vec128<short int, 8> *)_179]+0 S4 A64)] =
> > {r0:SI..r3:SI}
> > 
> > isn't considered as dependence?  Why does the earlier insn even come into
> > play?  What's the breaking transform?  I guess insn 119 and 120 are
> > exchanged?
> 
> Because 119 was deleted by postreload.  Doh! I should have spotted that.

But that ought to be ok, insn 115 is a store in alias set 0, so is picked up by
later alias analysis.  It's just that the compiler then digs deeper and decides
that that isn't an addressable object (at the gimple level) so there can't
really be a dependency.

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #27)
> (In reply to Richard Earnshaw from comment #26)
> > (In reply to Richard Biener from comment #25)
> > > I think it's more interesting why
> > > 
> > > * 119: [r216:SI (2 MEM[(struct Vec128<short int, 8> *)_179]+0 S4 A64)] =
> > > {r0:SI..r3:SI}
> > > 
> > > isn't considered as dependence?  Why does the earlier insn even come into
> > > play?  What's the breaking transform?  I guess insn 119 and 120 are
> > > exchanged?
> > 
> > Because 119 was deleted by postreload.  Doh! I should have spotted that.
> 
> But that ought to be ok, insn 115 is a store in alias set 0, so is picked up
> by later alias analysis.  It's just that the compiler then digs deeper and
> decides that that isn't an addressable object (at the gimple level) so there
> can't really be a dependency.

>   112: r214:SI=r109:SI-0x60
>   115: [r214:SI (0 MEM <unsigned char[16]> [(char * {ref-all})&D.33805]+0 S4
> A64)] = {r0:SI..r3:SI}
> ; _179 = D.33805
>   117: r217:SI=r109:SI-0x60
>   118: {r0:SI..r3:SI} = [r217:SI (2 D.33805+0 S4 A64)]
>   116: r216:SI=r109:SI-0x10
> * 119: [r216:SI (2 MEM[(struct Vec128<short int, 8> *)_179]+0 S4 A64)] =
> {r0:SI..r3:SI}
> ; r218 = _179
> * 120: r218:V8HI=[r109:SI-0x10 (3 MEM <vector(8) short int> [(short int
> *)_179]+0 S16 A64)]

but 115 doesn't store at the same address as 119?  Yes, it has the same
value.

So it doesn't seem to be stack-slot sharing.  When we'd share D.33805
with *_179 then we'd have made D.33805 TREE_ADDRESSABLE and adjusted
points-to sets accordingly in update_alias_info_with_stack_vars.

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #29 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Sorry, I was looking at the wrong pair of insns.  The earlier store to that
location was insn 111.

111: [r212:SI (1 MEM[(struct Vec128 *)_179]+0 S4 A64)] = {r0:SI..r3:SI}

It appears that the problem is a disagreement between alias_set_subset_of ()
and alias_sets_conflict_p().  The former thinks sets 1 and 2 have a permissible
subset relationship (2 is a subset of 1), so removes the later store during
postreload.  The latter is then used by alias_sets_conflict_p which thinks
there is no conflict between the two sets and fails to add a scheduling
dependency before sched2.

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #30 from Richard Biener <rguenth at gcc dot gnu.org> ---
I have tested the following since that might confuse the redundant store
removal sanity checks.  It bootstraps fine on x86-64-unknown-linux-gnu but
causes

FAIL: gcc.dg/tree-ssa/ssa-dse-36.c scan-tree-dump-times dse1 "Deleted redundant
call" 3
FAIL: gcc.dg/tree-ssa/ssa-dse-36.c scan-tree-dump-times dse1 "Deleted redundant
store" 3

in particular foo1 and foo2 are no longer optimized.  Specifically foo1:

-  x = {};
+  MEM <char[10]> [(struct X *)&x] = {};
+  memset (&x.mem1, 0, 10);

the lack of the 'memset' removal looks fishy since memset uses alias set
zero while the earlier store uses the alias set of struct X (but contains
alias set zero because of the char[] members).  For foo2:

   x = {};
+  x.mem1[5] = 0;

the issue is less clear since 'x' is also involved in the store to
x.mem1[5] (but that store also uses alias-set zero).  This shows the
situation is a bit odd wrt the behavior of a whole-aggregate store vs.
a component-wise store.  But again in both cases a later conflict check
with say *(int *)p, while conflicting with the memset and x.mem1[5] stores,
would not conflict with the x = {} store.

So this fallout is to be expected and desired.

diff --git a/gcc/alias.cc b/gcc/alias.cc
index 808e2095d9b..bacae30db18 100644
--- a/gcc/alias.cc
+++ b/gcc/alias.cc
@@ -427,9 +427,7 @@ alias_set_subset_of (alias_set_type set1, alias_set_type
set2) 

   /* Check if set1 is a subset of set2.  */
   ase2 = get_alias_set_entry (set2);
-  if (ase2 != 0
-      && (ase2->has_zero_child
-         || (ase2->children && ase2->children->get (set1))))
+  if (ase2 != 0 && ase2->children && ase2->children->get (set1))
     return true;

   /* As a special case we consider alias set of "void *" to be both subset

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #31 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
While that does seem to fix the bug, it's at the cost of 6 additional stores in
the problematic test that are redundant other than changing the alias set view.

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #32 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #31)
> While that does seem to fix the bug, it's at the cost of 6 additional stores
> in the problematic test that are redundant other than changing the alias set
> view.

The alternative is to alter the earlier store MEM_ATTRs to use an
alias-set covering both which usually means using alias-set zero.
This will pessimize followup optimizations around the store though
but it might be a good trade-off if done only late - I'd say
after sched2 but it doesn't look like theres CSE/DSE after it.
So maybe after sched1 which effectively means after reload, but there's
no regular CSE after reload either.  The latest CSE is pass_cse2.
IIRC a minor complication is that the earlier insn isn't readily
available - IIRC 'dest' is copied/mangled and not necessarily the
single origial RTX of the earlier SET_DEST (IIRC - it's been some time).

OTOH I think that correctness trumps optimization and if this is the
problematical transform then I don't see much options here.

In the place CSE applies the transform we'd have to set MEM_ALIAS_SET
to zero if the alias set condition doesn't hold and clear MEM_EXPR
if the MEM_EXPR condition doesn't hold.

Note I can't get the cse.cc code to trigger with the full preprocessed
source and a cross to arm and using -O2 -fno-exceptions -march=armv7-a
-mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee -fmath-errno

You mention at one point an insn removed by postreload, but that doesn't
use alias_set_subset_of.  I also don't remember postreload doing redundant
store removal.

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=93946

--- Comment #33 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ah, there's now the commoned mems_same_for_tbaa_p.  And indeed postreload
triggers on the cselib.cc instance.  But there we only have

(gdb) p debug_rtx (src_equiv)
(mem/c:SI (value:SI 90:4664 @0x421eba8/0x42e10c0) [1 MEM[(struct Vec128
*)_179]+12 S4 A32])

and in the loc list elt the setting_insn

(insn 89 88 93 14 (parallel [
            (set (mem/c:SI (reg/f:SI 12 ip [201]) [1 MEM[(struct Vec128
*)_179]+0 S4 A64])
                (reg:SI 0 r0))
            (set (mem/c:SI (plus:SI (reg/f:SI 12 ip [201])
                        (const_int 4 [0x4])) [1 MEM[(struct Vec128 *)_179]+4 S4
A32])
                (reg:SI 1 r1))
            (set (mem/c:SI (plus:SI (reg/f:SI 12 ip [201])
                        (const_int 8 [0x8])) [1 MEM[(struct Vec128 *)_179]+8 S4
A64])
                (reg:SI 2 r2))
            (set (mem/c:SI (plus:SI (reg/f:SI 12 ip [201])
                        (const_int 12 [0xc])) [1 MEM[(struct Vec128 *)_179]+12
S4 A32])
                (reg:SI 3 r3))
        ]) 435 {*stm4_}
     (nil))

cselib_redundant_set_p isn't a good API to alter an earlier SET but it might
be adjusted to return it so postreload could pass in an optional output
parameter which when present would relax the alias check and return the
earlier SET for further consideration / altering.  Hoping CSELIB tables
will be unaffected by altering that insn.

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #34 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
To be honest, I'm more concerned that we aren't eliminating a lot of these
copies during the gimple optimization phase.  The memcpy is really a type
punning step (that's strictly ISO C compliant, rather than using the GCC union
extension), so ideally we'd recognize that and eliminate as many of the copies
as possible (perhaps using some form of view_convert or whatever gimple is
appropriate for changing the view without changing the contents).

But that's for another day...

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231

--- Comment #35 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 16 Apr 2024, rearnsha at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
> 
> --- Comment #34 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
> To be honest, I'm more concerned that we aren't eliminating a lot of these
> copies during the gimple optimization phase.  The memcpy is really a type
> punning step (that's strictly ISO C compliant, rather than using the GCC union
> extension), so ideally we'd recognize that and eliminate as many of the copies
> as possible (perhaps using some form of view_convert or whatever gimple is
> appropriate for changing the view without changing the contents).

Yeah, there's currently no way to represent a change just in the
effective type that wouldn't generate code in the end but still
serves as barrier for these type related optimizations.

When modifying the earlier store is an option then another possibility
would be to attach multiple effective types to it in some way.  Of course
that's pessimizing as well.

That said, the choice has been made to prune those "invalid" redundant
store removals but as we see here the implemented checks are not working
as intended.