Mike Stump <mikest...@comcast.net> writes: >> If we're going to remove the assert, we need to define stuff like >> that. > > Orthogonal. The rest of the compiler defines what happens, it either > is inconsistent, in which case it is by fiat, undefined, or it is > consistent, in which case that consistency defines it. The compiler > is free to document this in a nice way, or do, what is usually done, > which is to assume everybody just knows what it does. Anyway, my > point is, this routine doesn't define the data structure, and is > _completely_ orthogonal to your concern. It doesn't matter if it zero > extends or sign extends or is inconsistent, has bugs, doesn't have > bugs, is documented, or isn't documented. In every single one of > these cases, the code in the routine I am fixing, doesn't change. > That is _why_ it is orthogonal. If it weren't, you'd be able to state > a value for which is mattered. You can't, which is why you are wrong. > If you think you are not wrong, please state a value for which it > matters how it is defined.
It isn't orthoganal. immed_double_const and CONST_DOUBLE are currently only defined for 2 HOST_WIDE_INTs. So, as good functions do, immed_double_const asserts that it is not being used out of spec. That's why the code I quoted said the filler bits for CONST_DOUBLE shouldn't matter; this assert is supposed to make sure that we never generate CONST_DOUBLEs like that. (Personally I'd have preferred it if simplify_immed_subreg asserted instead of filling with zeros.) You want to remove that restriction on immed_double_const and CONST_DOUBLE. That is, you want to change their spec. We should only do that if we define what the new semantics are. Richard
