<div dir="ltr"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><pre>I think renaming is really confusing. And I think extending to
supporting floating point types should be a separate issue that would
also look at the other operators.

Maybe a compromise would be to keep DW_OP_mod (and make DW_OP_rem an
alias?)
</pre>
        </blockquote>
        <pre>I would do it the other way around make DW_OP_mod be a legacy alias and 
call the same operation DW_OP_rem.
</pre>
      </blockquote>
      <pre>I think that is fine, as long as they have the same constant value
(0x1d).
</pre>
    </blockquote>
    <p>Agreed. Same encoding. Just in the header files there are two
      defines which point to the same constant value. Old consumers can
      continue to print DW_OP_mod (just like
      DW_OP_push_object_{address,location} but consumer's human readable
      strings should be updated to DW_OP_rem.</p></div></blockquote><div>Since DW_OP_mod is currently defined only for unsigned integers, where floor and truncate have the same effect, defining the existing operator to use truncated division (i.e., modulo) and adding a new operator for floored division (DW_OP_rem) is completely backward compatible. In the example Jakub gave, GCC could replace the long divide/multiply/subtract sequence with DW_OP_rem.</div><div><br></div><div>I see no point in renaming mod so that we can give it rem behavior, which would then force us to use a different name for a true mod operation.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <p>My understanding is that the DWARF committee already decided to
      allow floating point numbers on the stack. I was not around for
      this and I do not know the exact reasoning. My guess as to why
      that was done is so that if a FP number was optimized out, it
      could still be reconstructed with DWARF expressions and then
      represented in implicit storage. This would suggest encoding of FP
      numbers would have to follow the consumer's target architecture
      and interpretation of operators would need to be specific enough
      to allow the unambiguous reconstruction of the optimized out
      variable on that target architecture.</p></div></blockquote><div>Yes, we've allowed floats on the stack since DWARF 5 (see Issue <a href="https://dwarfstd.org/issues/140425.1.html">140425.1</a>). But DW_OP_mod was left out of the list of operators that can operate on floats, and the original purpose of your (Ben's) proposal was to change that — right?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <p>My ambivalence to a true modulo is because unlike truncated
      division aka remainder which is used for address arithmetic within
      both the signed and unsigned domains, true modulo on FP numbers
      and even truncated division on FP numbers is a function call in
      C/C++.</p></div></blockquote><div>Fortran has both MOD (truncated = remainder) and MODULO (floored) intrinsic functions. Many other languages also have both operations. That suggests we could adopt Fortran nomenclature and define the existing DW_OP_mod as remainder, and add DW_OP_modulo for modulo, but I don't really like that. I prefer "mod" and "rem", and I think most other languages with both go with names along those lines.</div><div><br></div><div>-cary</div><div><br></div></div></div>