UBSan adds code to check things, it necessarily changes optimizations by having those checks in. It shouldn't affect the behavior of programs that don't exhibit UB (but I imagine it could affect the behavior of programs relying on specific IB (Implementation Defined Behavior)).
Reducing a test case to better understand your code & be able to portably demonstrate the issue would help to get traction on understanding the behavior, seeing if it's a clang bug, etc. On Fri, Oct 25, 2019 at 1:49 PM Hans Åberg <haber...@telia.com> wrote: > It is just an abort trap. The ‘make check' also passes if turning off > optimization. I would have expected UBSan to not change anything in > optimization, but merely report the issues it finds. Apparently it finds > nothing, so it may suggest a compiler bug. > > > > On 25 Oct 2019, at 22:34, David Blaikie <dblai...@gmail.com> wrote: > > > > Hard to know what might be happening - what sort of failure you're > seeing, etc. Perhaps UBSan is stabilizing/changing unspecified rather than > undefined behavior - or the test is failing due to some undefined behavior > that UBSan doesn't catch, etc. > > > >
_______________________________________________ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
