This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH for division by zero in template arguments
>>>>> Mark Mitchell <mark@markmitchell.com> writes:
> [expr]
> If during the evaluation of an expression, the result is not mathemat-
> ically defined or not in the range of representable values for its
> type, the behavior is undefined, unless such an expression is a con-
> stant expression (_expr.const_), in which case the program is ill-
> formed.
> Note that this also implies, for example, that integer overflow in a
> constant expression *must* be diagnosed. A strict reading of this
> might seem to imply, in the division by zero case, that both operands
> must be constant, but that doesn't really make any sense.
Perhaps what it means is that it's ill-formed in any situation that expects
a constant-expression. So
int i = 7 % 0;
is undefined, and
enum { i = 7 % 0 };
is ill-formed. FWIW, EDG also gives a warning for the first case and an
error for the second.
>>> I also think the result of the operation should not be marked
>>> TREE_CONSTANT, since it's not: it's a run-time division.
Jason> I'd rather handle this by checking that the expression
Jason> actually reduces to an INTEGER_CST, as in
Jason> check_cp_case_value or build_enumerator.
> I considered and rejected this solution.
Why? A integral constant-expression is one that evaluates to an integral
constant ([expr.const]). So checking that it does satisfies the
requirement, and is more appropriate for what the code actually expects in
any case. This seems safer to me than expecting TREE_CONSTANT to be set or
not set as expected.
> Why call something that must be evaluated at run-time a constant?
Precedent. The C frontend does.
> For example, I checked that code like this:
> extern const int i = 7 % 0;
> yields a run-time initialization.
Yep. The C frontend handles this by saying "initializer element is not
computable at load time", but it still qualifies as TREE_CONSTANT. The
same is true of various other expressions (involving relocs, I think). I
think the backend concept of TREE_CONSTANT is that the expression is
independent of the program's state; it can be evaluated anywhere and
produce the same results. In that sense, 7 % 0 is indeed constant.
Jason