'Unused variable' warnings from ivory_asserts.h about ivory HOT 5 CLOSED

Yes, this is a known problem that is at the intersection of common subexpression elimination (CSE) and ifdefs. The CSE helps with readability and code size dramatically.

I would suggest using -Wno-unused-variable; for Ivory generated code, those warnings shouldn't be needed to find bugs.

I would prefer not to decide at Ivory compile-time whether to to use assertions or not, so that the same generated code can be used with or without assertions.

Do you have another proposed solution?

from ivory.

Well, I thought about re-definition of macros using popular cast-to-void trick[1] in the following manner:

#define COMPILER_ASSERTS(arg) ((void) (arg))

AFAIK, with this declaration compiler has a chance to keep the arg expression in final code, but in practice it optimizes it out. Further research is needed.

[1] http://stackoverflow.com/questions/4178695/c-what-is-the-purpose-of-casting-to-void

from ivory.

I believe that would work. Would you mind testing and doing a pull request?

from ivory.

I don't believe (void)(something) will always work as expected, i. e. as nop. A better solution would be something like

#ifdef IVORY_TEST
    COMPILER_ASSERTS_BLOCK(init_block, cond) do { init_block; assert(cond) } while(0);
#else /* IVORY_TEST */
    COMPILER_ASSERTS_BLOCK(init_block, cond)
#endif /* IVORY_TEST */

COMPILER_ASSERTS_BLOCK(
    (
        int32_t n_cse1 = (int32_t) -(int32_t) 1;
    ),
    ((bool) ((bool) ((int32_t) 0 < (int32_t) 1024) && (bool) (n_cse1 <= (int32_t) 0)))
);

from ivory.

@cblp, but then the Ivory common subexpression elimination pass, creating n_cse1, needs to know if the variable is only used within the assertion, I think. While this is possible, it starts complicating the (Ivory) compiler. If we want to go down that path, we might as well make the use of assertions be something that has to be given at Ivory compile-time. As mentioned, I think it's preferable to defer that decision to C compile-time.

from ivory.