[llvm-dev] Question about LLVM Building Error with "-DLLVM_ENABLE_DUMP" and "RelWithDebInfo"
Mehdi Amini via llvm-dev
llvm-dev at lists.llvm.org
Mon Apr 10 12:34:49 PDT 2017
> On Apr 10, 2017, at 11:34 AM, Robinson, Paul <paul.robinson at sony.com> wrote:
>> -----Original Message-----
>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org <mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of Mehdi
>> Amini via llvm-dev
>> Sent: Sunday, April 09, 2017 2:26 PM
>> To: Matthias Braun
>> Cc: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>; jingu at codeplay.com <mailto:jingu at codeplay.com>
>> Subject: Re: [llvm-dev] Question about LLVM Building Error with "-
>> DLLVM_ENABLE_DUMP" and "RelWithDebInfo"
>>> On Apr 7, 2017, at 4:45 PM, Matthias Braun via llvm-dev <llvm-
>> dev at lists.llvm.org> wrote:
>>> I think the idea is to keep NDEBUG out of headers when possible. So I
>> think this should better be something like:
>>> -#ifndef NDEBUG
>>> void dumpUses(unsigned RegNo) const;
>>> to be inline with various other dumpers (like MachineInstr::dump(),
>> Pass::dump(), …)
>> I’m fine with leaving methods there, but we need to be able to compile-out
>> fields in structure.
> Hmmm seems to me this has come up in the past, and somebody pointed out
> that it prevents building a debug-mode front-end against a release-mode LLVM.
> (Why is that a valid use-case? If I have an out-of-tree front end, and
> especially one with a different license, I might well prefer to download
> only LLVM releases rather than keep up-to-date with a live tree that I
> build myself. IIRC we do not provide debug-mode downloads, therefore
> anything that affects struct size/layout will break this use-case.)
That’s why we’re not using NDEBUG but the ABI_BREAKING_… macro which is set by the llvm-config.h.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev