https://llvm.org/bugs/show_bug.cgi?id=24285
Richard Smith <richard-l...@metafoo.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-l...@metafoo.co.uk Resolution|--- |WORKSFORME --- Comment #1 from Richard Smith <richard-l...@metafoo.co.uk> --- GCC inherited these options from Clang, so if there's a "drop-in replacement" issue, you're filing it with the wrong compiler ;) Also, Clang trunk *does* accept the GCC spelling, as you call it. FYI: "undefined" and "undefined-trap" used to refer to different groups of sanitizers (where "undefined-trap" is the subset of "undefined" that is compatible with -fsanitize-undefined-trap-on-error). We used to reject combinations of options that would request trapping and also request sanitizers incompatible with trapping. We've since changed our interface so that we'll just turn off the incompatible sanitizers when -fsanitize-undefined-trap-on-error is specified (if they're enabled via a sanitizer group), and they now mean the same thing. (We still error if an incompatible sanitizer is explicitly enabled, so -fsanitize=vptr -fsanitize-undefined-trap-on-error is still rejected.) [Also, -fsanitize-undefined-trap-on-error is deprecated; the new syntax is -fsanitize-trap=undefined (though GCC might not yet accept that).] -- You are receiving this mail because: You are on the CC list for the bug.
_______________________________________________ LLVMbugs mailing list LLVMbugs@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs