Tags

Make specialized vector treatment in cross-compilation more consistent.

There were a few ways of dealing with the issue that ARRAY-ELEMENT-TYPE
could accidentally reflect the host's array type:

(A) carefully writing a form to reconstruct a constant in the target
as exemplified by COMPUTE-TEMPORARIES-DESCRIPTION in meta-vmdef,
(B) taking :ELEMENT-TYPE as merely a suggestion,
like in EMIT-LONG-NOP in compiler/x86-64/insts,
(C) not caring, even though it could in fact generate broken fasls
if the host upgraded (UNSIGNED-BYTE 8) to anything else, such as
**CHARACTER-DATABASE** which directly assigned a compile-time
constant into a variable having a specific type proclamation.

This change makes the cross-compiler warn of a potential problem when
writing out a constant array. e.g. The Unicode database was technically
incorrect but not ostensibly broken, because every supported xc host
provides (UNSIGNED-BYTE 8) as a specialized array type.
Nonetheless, we tried to be rigorous most of the time, which led one
to question why/when care had to be exercised.

So now it is an error in the crosss-compiler to dump a numeric array
other than BIT unless it has been "registered" with its precise type;
but (UNSIGNED-BYTE 8) emits only a style-warning if unregistered.

Note that case (B) wasn't visibly broken, but different host Lisps could
produce different target code. A read-time constant array might be upgraded
to any type of which (UNSIGNED-BYTE 8) is a subtype, but compiled AREF
would be ok because CTYPE-OF as defined in 'cross-type' reflects whatever
the host thinks, and AREF would emit correct code to match that
as long as there were no local type declarations to the contrary.