[llvm-dev] Reporting source errors from MCCodeEmitter::encodeInstruction() ?

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Tue Feb 4 15:36:34 PST 2020


I was going to say use MCContext::reportError, but that mainly calls
SourceManager::PrintMessage. Does that not prevent clang from emitting a .o
file? That seems like a bug if so.

On Tue, Feb 4, 2020 at 2:59 PM Thomas Goodfellow via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> [apologies for this duplicate post: originally sent to lldb-dev by not
> paying attention to the address auto-completion]
>
> We have a backend for a target that at present only detects some
> assembler errors when emitting instructions (basically because the
> platform has configurable properties with dependencies between
> instructions and it was easier to check for their interaction late
> than try to detect them earlier, e.g. through custom encoder methods
> and tablegen). Emitting diagnostics through
> SourceManager::PrintMessage() "works" in the limited sense of
> communicating the problem to a human, however it doesn't prevent
> generation of an incorrect output file or change the process exit
> code.
>
> We'd prefer not to resort to report_fatal_error() since that isn't a
> polite way to diagnose problems in the source.
>
> Is there a sensible way to properly signal a source error from the
> level of encodeInstruction()? Or is it expected that all such errors
> are reported earlier?
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200204/6db50f84/attachment.html>


More information about the llvm-dev mailing list