http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60275
--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #3) > I guess we shouldn't copy the design mistakes clang makes. What action to > take on detected undefined behavior should be orthogonal to how to report it > (runtime error message with recovery, fatal runtime error message or abort > without error message). The question is how to implement this properly. One way is using environment variables such as ASAN and TSAN do, which have environment variables, e.g. ASAN has https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags , which permits: ASAN_OPTIONS= abort_on_error (default 0) exitcode (default 1) etc. It would be also nice to have a back trace. (I had an always inlined add function, which overflows and there pointing to the header file does not help much.) Still, it is also nice to be able to tell at compile time that failures should be fatal as one can easily forget to set the environment variable. If one does not want to go the route of Clang, I wonder how to handle it instead as one does not have one initializing call to the library.
