[Dwarf-discuss] Clarification: DW_OP_mod doesn't specify which definition of modulo

[Ben Woodard]

On 11/10/25 8:47 AM, Mark Wielaard wrote:
> Hi,
>
> OK. Let me try to summarize the proposal(s) and choices so we have
> something concrete to discuss in the DWARF Committee meeting this
> afternoon.
>
> - Clarify what DW_OP_mod means on generic types.
>    This doesn't seem to need extra/explicit clarification because
>    2.5.1.4 "Arithmetic and Logical Operations" says:
>
>    If the type of the operands is the generic type, except as otherwise
>    specified, the arithmetic operations perform addressing arithmetic,
>    that is, unsigned arithmetic that is performed modulo one plus the
>    largest representable address.
>
>    [This formulation might need some tweaking if there are multiple
>     address spaces with different representable addresses. But IMHO
>     that can wait for another time.]
>
> - Define DW_OP_mod for integral (possibly signed) typed DWARF values.
>    There are a couple of choices of how to define this for (signed)
>    typed values. But the most "natural" way would be using either
>    floored or truncated division. Lets pick floored division?
I would argue for truncated division for DW_OP_mod
>
> - Mention backward compatibility of the choice. If we assume producers
>    work like Jakub showed for GCC (where DW_OP_mod is only used for
>    unsigned/generic types) then there is no issue if we define it for
>    integral (signed) types.
agreed.
> For GDB there might be some assumption it
>    would be modulo using floored division.
Yes it breaks GDB's current implementation but other consumers have 
interpreted it as truncated division. If you add DW_OP_modulo, GDB's 
current implementation could be used for that and DW_OP_mod could be 
implemented with % like it is in other consumers.
> But in general it seems
>    our choice would just mean that consumers should explicitly implement
>    DW_OP_mod for typed DWARF vales as specified.
>
> - Rename DW_OP_mod to DW_OP_rem? And/Or introduce a new DW_OP_modulo.
>    If the implementation choice is not "true" modulo should we give
>    the DW_OP_mod a new name? IMHO No. It really is too confusing.
>    mod(ulo) and rem(ainder) are already not consistently used in
>    different languages.
I like what Cary pointed out about Fortran MOD for truncated division 
and then MODULO for floored. I think that is the best choice. As long as 
the algorithm is specified in the description, and given Fortran's prior 
usage, I no longer think we need to change the name.
>
> - Add a new DW_OP_rem that uses truncated (if we pick floored for mod)
>    division? If yes then we should explicitly mention this shouldn't
>    be used for 6.4.2 Call Frame Instructions (it would be redundant
>    with DW_OP_mod anyway for the generic type).
>
> - Should this new DW_OP_rem be an extended DW_OP?
I would say DW_OP_modulo (floored) should be the one considered for 
being an extended op. I don't have very strong opinion on this. Slightly 
more than "whatever".
>
> - Extend DW_OP_mod (and DW_OP_rem) to float types?
>    That is the original proposal, changing 2.5.1.4 ("Operations other
>    than DW_OP_abs, DW_OP_div, DW_OP_minus, DW_OP_mul, DW_OP_neg and
>    DW_OP_plus require integral types of the operand").
>    I admit to not really know how to define this or if the mod/rem
>    operation is "simply" dictated by the the DW_ATE_*float* definitions.
>    Also, is it really needed?
I believe that it is needed to be able to create implicit storage for 
floating point values optimized out real storage. ref: 
https://dwarfstd.org/issues/140425.1.html
>
> Hope that is a good summary of the proposals/choices we have to make.
>
> Cheers,
>
> Mark
>