[Ecls-list] Type propagator and "bogus" existing code

[Gabriel Dos Reis]

On Sat, Jun 19, 2010 at 9:36 AM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> On Sat, Jun 19, 2010 at 4:16 PM, Gabriel Dos Reis
> <gdr at integrable-solutions.net> wrote:
>>
>> It is valid Lisp, then error is obviously not acceptable.
>> Any other form of diagnostic that leads to build error is also
>> too severe.  Obviously, miscompilation is not an option.
>> My question is: can ECL still generate correct codes?
>
> There is no such thing as "correct" in this case, because the arguments were
> declared / inferred to have one type and the function expects a different
> one.

If there is a declaration whose scope covers that conflicting
inference (or uses),
then I think the code is non-reachable.
Does not SBCL issue a warning in that case?

> Typically ECL will detect the unused branches later at an expansion or
> at an optimization stage, but if not, the outcome will vary. For low safety
> high speed optimization settings, ECL may decide to expand the function. In
> other cases it may decide to just use an indirect call. Only the first case
> might be problematic: in case ECL unboxed the declared arguments and the
> optimized implementation uses low level C, the resulting expressions might
> actually be invalid. I am just wondering whether this can be prevented,
> perhaps by marking the C1FORM as problematic.

I am assuming that th inferred types are being cached by basic blocks, is that
correct?

-- Gaby