<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 4/9/20 12:16 PM, Philip Reames via
      llvm-dev wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:0014f63f-58aa-de29-5e58-9326bef11ecc@philipreames.com">
      <br>
      On 4/9/20 9:59 AM, Chris Tetreault via llvm-dev wrote:
      <br>
      <blockquote type="cite">
        <br>
        David,
        <br>
        <br>
        †† In my opinion, NDEBUG is one of those gross old C things that
        everybody complains about. Itís called ďNot DebugĒ, but really
        it means ďAssert DisabledĒ. I think one could be forgiven for
        actually using it as a heuristic of whether or not a build is a
        debug build, especially since no other options are provided. I
        appreciate your desire, but I think itíd be unfortunate if the
        build system grew yet another flag to control debugness.
        <br>
        <br>
        †† As far as I can tell, as it currently works,
        LLVM_ENABLE_ASSERTIONS just makes sure that NDEBUG is not
        defined, even in release builds. So if I do
        -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=TRUE, Iíll
        get an optimized build with no debug symbols but with asserts
        enabled, which in my mind isnít a terribly useful thing to have.
        <br>
        <br>
      </blockquote>
      (Completely ignoring rest of thread context.† Replying to previous
      sentence in isolation.)
      <br>
      <br>
      A Release+Asserts build is an *incredibly* useful thing to have.
      It's generally the only configuration I build.† It's fast enough
      to not be obviously painfully slow, several times faster to build
      than a debug build, takes *much* less space on disk, and yet
      reports assertion failures.
      <br>
      <br>
    </blockquote>
    <br>
    <p>+1 <br>
    </p>
    <p>Same for me on my laptop for years.</p>
    <p><br>
    </p>
    <br>
    <blockquote type="cite"
      cite="mid:0014f63f-58aa-de29-5e58-9326bef11ecc@philipreames.com">
      <blockquote type="cite">Furthermore, none of this works on Visual
        Studio because it has a UI menu to control the build type. I
        personally would be very disappointed to see Visual Studioís
        build type dropdown break.
        <br>
        <br>
        †† Since we Cís assert, it is intrinsically tied to NDEBUG. What
        we need is proper custom asserts. In codebases Iíve seen in my
        travels that have this it usually looks like:
        <br>
        <br>
        // If asserts are enabled, evaluate and assert that expr is
        truthy. If it is not, complain with msg.
        <br>
        <br>
        LLVM_ASSERT(expr, msg)
        <br>
        <br>
        // If asserts are enabled, evaluate and assert that expr is
        truthy. If it is not, complain with msg.
        <br>
        <br>
        // If asserts are disabled, evaluate expr, do not assert.
        <br>
        <br>
        // either way, return expr
        <br>
        <br>
        LLVM_VERIFY(expr, msg)
        <br>
        <br>
        †† The first one is useful as a traditional assert. The second
        one is useful if you are calling a function, and want to assert
        that it succeeds, but still need it to be evaluated in release
        builds:
        <br>
        <br>
        auto *Foo =
        LLVM_VERIFY(ReturnsAPointerThatShouldNeverActuallyBeNull(),
        ďthis should never return nullĒ);
        <br>
        <br>
        †† If we have custom asserts, then we can have custom assert
        guard macros:
        <br>
        <br>
        // true if this is any sort of debug build
        <br>
        <br>
        LLVM_DEBUG_BUILD
        <br>
        <br>
        // true if asserts are turned on (Debug build on Windows,
        <br>
        <br>
        // Debug build or -DLLVM_ASSERTIONS_ENABLED=TRUE on other
        platforms)
        <br>
        <br>
        LLVM_ASSERTS_ENABLED
        <br>
        <br>
        †† These flags could be derived from just CMAKE_BUILD_TYPE, and
        LLVM_ENABLE_ASSERTIONS can go away (assuming we agree that an
        asserting build with optimizations and no debug info is worse
        than useless). Custom asserts also have the advantage of having
        a proper message parameter and not needing to rely on the
        truthiness of string literals. Obviously this is a much more
        invasive change than what you are proposing, but in my opinion
        itís the correct thing to do.
        <br>
        <br>
        Thanks,
        <br>
        <br>
        †† Christopher Tetreault
        <br>
        <br>
        *From:* llvm-dev <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev-bounces@lists.llvm.org"><llvm-dev-bounces@lists.llvm.org></a> *On
        Behalf Of *David Truby via llvm-dev
        <br>
        *Sent:* Thursday, April 9, 2020 7:26 AM
        <br>
        *To:* <a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
        <br>
        *Subject:* [EXT] [llvm-dev] [RFC] Usage of NDEBUG as a guard for
        non-assert debug code
        <br>
        <br>
        Hi all,
        <br>
        <br>
        During discussions about assertions in the Flang project, we
        noticed that there are a lot of cases in LLVM that #ifndef
        NDEBUG is used as a guard for non-assert code that we want
        enabled in debug builds.
        <br>
        <br>
        This works fine on its own, however it affects the behaviour of
        LLVM_ENABLE_ASSERTIONS;† since NDEBUG controls whether
        assertions are enabled or not, a lot of debug code gets enabled
        in addition to asserts if you specify this flag. This goes
        contrary to the name of the flag I believe also its intention.
        Specifically in Flang we have a case where someone wants to ship
        a build with assertions enabled, but doesn't want to drag in all
        the extra things that are controlled by NDEBUG in LLVM.
        <br>
        <br>
        In my opinion we ideally want LLVM_ENABLE_ASSERTIONS to _only_
        enable assertions and do nothing else. I don't think this is
        possible without changing the use of NDEBUG elsewhere as NDEBUG
        controls whether assert is enabled.
        <br>
        <br>
        I propose we should be using another macro (something like
        LLVM_DEBUG_CHECKS ?) that is enabled in Debug builds, and
        possibly controlled by another cmake flag
        (LLVM_ENABLE_DEBUG_CHECKS ?) for code that we want enabled for
        debugging but not in releases. This would allow
        LLVM_ENABLE_ASSERTIONS to do what it says on the tin and
        actually enable assertions only.
        <br>
        <br>
        Does anyone else have any thoughts on this?
        <br>
        <br>
        Thanks
        <br>
        <br>
        David Truby
        <br>
        <br>
        <br>
        _______________________________________________
        <br>
        LLVM Developers mailing list
        <br>
        <a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
        <br>
        <a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
        <br>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
  </body>
</html>