[LLVMbugs] [Bug 14247] New: -fcatch-undefined-behavior should allow severity levels and recoverability
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Fri Nov 2 15:42:41 PDT 2012
http://llvm.org/bugs/show_bug.cgi?id=14247
Bug #: 14247
Summary: -fcatch-undefined-behavior should allow severity
levels and recoverability
Product: clang
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: htam at apple.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Clang should support one or both of the following:
1. An option to turn -fcatch-undefined-behavior traps into run-time warnings
or at least recoverable traps
(-fbreak-undefined-behavior/-fwarn-undefined-behavior?). The former would
allow a programmer to quickly get a sense of issues in the entire program by
just by piping through uniq. The second would allow someone to get through a
few warnings at a time in a debugger.
2. Fine-grained control on which types of UB are caught; similar to
-Werror=/-Wno-error= (-f[no-]catch-udefined-behavior=X?).
Motivation:
I'm using clang built with compiler-rt on x86_64 Linux. All are from trunk at
r167261. The -fcatch-undefined-behavior option emits an irrecoverable trap,
even when debugging a program under gdb. In the program I am trying to debug
with -fcatch-undefined-behavior, there are a large number of "1 << 31"
operations that cause the program to terminate very early in the run. This is
preventing me from investigating more important UB later on in the program.
I know that this is, strictly speaking, undefined behavior, but it is
exceedingly unlikely to be the cause of the bug I'm looking for. Instead of
fixing one issue at a time, being able to get a list of all the undefined
behavior points would make it much easier to triage bugs in large, legacy
programs.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the llvm-bugs
mailing list