Proposed resolution:

Change the Returns: clause in 3.2.2.4 to:

Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd32(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO is in effect.

Change the Returns: clause in 3.2.3.4 to:

Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd64(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO is in effect.

Change the Returns: clause in 3.2.4.4 to:

Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd64(*this) llroundd128(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO is in effect.

In a private email, Daniel writes:

I would like to ask, what where the reason for the decision to define the semantics of the integral conversion of the decimal types, namely

"operator long long() const;

     Returns: Returns the result of the 
conversion of *this to the type long long, as if 
performed by the expression llrounddXX(*this)."

where XX stands for either 32, 64, or 128, corresponding to the proper decimal type. The exact meaning of llrounddXX is not given in that paper, so I compared it to the corresponding definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2:

"The lround and llround functions round their argument to the nearest integer value, rounding halfway cases away from zero, regardless of the current rounding direction. [..]"

Now considering the fact that integral conversion of the usual floating-point types ("4.9 Floating-integral conversions") has truncation semantic I wonder why this conversion behaviour has not been transferred for the decimal types.

Robert comments:

Also, there is a further error in the Returns: clause for converting decimal::decimal128 to long long. It currently calls llroundd64, not llroundd128.