[llvm-dev] Let ctor of DiagnosticInfoWithLocationBase take Function* instead of Function& ? (original) (raw)
Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Tue Apr 11 06:28:39 PDT 2017
- Previous message: [llvm-dev] How to code backend with irregular memory address increment
- Next message: [llvm-dev] GSoC project on finding and fixing bugs with debug info
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 03/24/2017 05:37 PM, Zhao, Weiming via llvm-dev wrote:
Hi,
Currently the constructor of class DiagnosticInfoWithLocationBase takes a Function reference: /// \p Fn is the function where the diagnostic is being emitted. \p Loc is /// the location information to use in the diagnostic. DiagnosticInfoWithLocationBase(enum DiagnosticKind Kind, enum DiagnosticSeverity Severity, const Function &Fn, const DiagnosticLocation &Loc) However, if we want to emit diagnostics via calls like emitUndefinedBehaviorOptimizedWarning, the Function object may be unavailable. For example, in the interim of inlining, under the context of Analysis/InstructionSimplify, the Instruction in the context has no parent BB. So how about let the constructor takes a Function ptr? All the use of Function object is to print out function name. Using pointer, we can let if print somthing like "" if it is null.
We might just not want to emit a warning at all in this case. Unfortunately, just printing a warning which says, "There's UB somewhere in your program", is not very helpful. If we'd like to do this, then we need to think about how to feed enough information through the interfaces to make the reporting useful (functions and debug locations).
-Hal
-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory
- Previous message: [llvm-dev] How to code backend with irregular memory address increment
- Next message: [llvm-dev] GSoC project on finding and fixing bugs with debug info
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]