https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116948
--- Comment #2 from Sam James <sjames at gcc dot gnu.org> --- > I think it is much more useful to be able to find out as many issues as > possible, not just the first one. This assumes that people even realise there were any issues at all, which they might not without aborting. There's a few reasons I feel like this is the right direction: * ASAN does abort on failure, doesn't try to soldier on (so people may well expect UBSAN to); * Not failing on errors is kind of allergic to doing anything in an automated way in CI; * One might well think "I bootstrapped with ubsan, it succeeded, hence it's fine"; it's really not obvious you need to then grep the build log you may not have even saved. Making sure the default DTRT helps with it being clean (which is why we default to --enable-werror), otherwise you do indeed end up with irrelevant issues blocking you. So it's a bit circular. If we really don't want to do this, I can think of two compromises so far: 1) Documenting that it doesn't default to erroring (actually, we don't seem to document `bootstrap-ubsan` at all right now, just asan) 2) Maybe trying it to --disable-werror (not sure I like this idea, feels a bit janky)
