On Thu, Aug 7, 2025 at 7:18 AM Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote: > > * Thomas de Bock via Gcc: > > > Sorry for my wording, that is not the only thing memcmp gives us, but it > > does not give us information regarding which fields mismatched. So we cannot > > deal with (after !='s are converted to =='s) blocks where not all blocks in > > a chain have the same node as their (eventual, possibly through fallthru's) > > FALSE edge's destination, is what I was trying to say. > > We could add a __memmismatch function to glibc, which returns the
Glibc has __memcmpeq@@GLIBC_2.35. > address of the first non-matching byte (or something to that effect, > offset might be better if you want to align it down to the start of a > field). This is one of the primitives provided by Java APIs covering > this area. The question is how useful this is in general for tuple > comparison if you do not have a fixed field width. > > On the other hand, we already added __memcmpeq for use by GCC recently, > and it's still unused. 8-/ > > Thanks, > Florian > -- H.J.
