Clarification needed regarding operator semantics for group operations

In the OpenCL C 2.0 specification § 6.13.15 Work-group Functions, it is stated that:

The <op> in work_group_reduce_<op>, work_group_scan_exclusive_<op> and work_group_scan_inclusive_<op> defines the operator and can be add, min or max.

I would like clarification of the exact semantics of the add, min and max operators, as these semantics are not stated explicitly.

Is it intended that the semantics of min and max should match those of the min() and max() built-in functions, respectively, as specified in § 6.13.4 Common Functions? :

max(): Returns y if x < y, otherwise it returns x. If x or y are infinite or NaN, the return values are undefined.
min(): Returns y if y < x, otherwise it returns x. If x or y are infinite or NaN, the return values are undefined.

Is it intended that the semantics of add should match those of the addition operator for signed integer types, as per C99 § 6.5.5? :

If an exceptional condition occurs during the evaluation of an expression (that is, if the result is not mathematically defined or not in the range of representable values for its type), the behavior is undefined.

... and for unsigned integer types, as per C99 § 6.2.5.9? :

A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type.

Also, are the intended semantics of add for floating point types as per those of the addition operator?

If the semantics of add for signed integer types give rise to undefined behavior if the result is not in the range of representable values for the type, then can this also apply to intermediate results of the reduction? For signed char and signed short types, should it be assumed that integer promotion is applied to each operand prior to reduction or scan operation, such that the result is only undefined if the final result is not representable by the signed char or signed short type, or should it be assumed that intermediate results are of the same type as each operand?

For floating point types, is it intended that intermediate results can be calculated to the same precision as each operand, or is it the intent that reduction/scan operations over single-precision operands can be calculated with double-precision intermediate results, and that operations over half-precision operands can be calculated with single or double-precision intermediate results?

Alternatively, is it intended that the semantics of add for signed types should match those of atomic_fetch_add() as specified in § 6.3.11 Atomic Functions, in the subsection entitled "The atomic_fetch and modify Functions": ?

For signed integer types, arithmetic is defined to use two's complement representation with silent wrap-around on overflow; there are no undefined results.

In view of the above, would an add_sat group operator be appropriate for future consideration?

No repository file or test is named. Start by reviewing OpenCL C 2.0 § 6.13.15 alongside the cited Common, C99, and Atomic Functions sections; the issue is done when the intended operator, overflow, promotion, and intermediate-precision semantics are clarified in the specification or a maintainer records the decision.