On Fri, Oct 27, 2000 at 04:54:49PM +0200, martin@... wrote:
> currently compilation of SBCL will fail, if there are compiler-warnings
> when compiling a file, and :ignore-failure-p is not set for that file.
> Well, I'm working on integrating some compiler-optimizations, and so I
> got in trouble ...
> Consider the following piece of code:
> (defun f (x)
> (declare (optimize (debug 3)))
> (declare (type single-float x))
> (when (typep x 'double-float)
> (declare (type double-float x))
> (print x)))
> (print x)))
> This will yield the following output, when compiled:
> ;;;Compiling defun f
> ; in: DEFUN F
> ; (LOCALLY (DECLARE #) (PRINT X))
> ; caught WARNING:
> ; The type declarations SINGLE-FLOAT and DOUBLE-FLOAT for X conflict.
> ; (PRINT X)
> ; note: deleting unreachable code
> ; compilation unit finished
> ; caught 1 WARNING condition
> ; printed 1 note
> STYLE-WARNING: redefining F in DEFUN
> The code might look somewhat artificial, but I have a macro that expands
> into stuff like that.
> So, I'm stuck when I want to recompile SBCL, because when compiling a
> specific file, #'compile-file will set 'failure-p to T. This will be
> detected in #'compile-stem, and the build-process will halt.
> I think the above warning is not that serious, because the obviously
> unreachable code will be deleted.
> So, the options I see for now are as follows:
> a) change the code in compiler/ir1tran to issue a style warning, when
> there is a type conflict.
> b) change cold/shared.lisp, so that warnings will be ignored altogether
> in rebuilding.
> I like a) much better (that is what I'll do next to get a working
> version, ...maybe (!).
> What do you think about that?
> Is that legal?
Looking at the definition of TYPE declarations in the Hyperspec, it
appears that the code is conforming code: contradictory type
declarations cause undefined behavior only code within the scope of
the contradictory declaration is actually executed. So ideally, the
compiler would be smart enough to notice that the code is never
entered and issue a STYLE-WARNING, not a full WARNING, for that
reason. (I think the compiler *is* smart enough to notice that the
code is never entered; the problem is that it's issuing the warning
immediately, without bothering to consider that it might later notice
that the code is never entered.) However, fixing this is probably a
little tricky, and it's a rather low-priority problem compared to many
of the outright bugs remaining in the system.
I think in general the compiler's behavior of issuing WARNING for
contradictory type declarations is appropriate. According to ANSI,
STYLE-WARNING is for "subjective" judgements, and this doesn't seem to
be a subjective issue. The compiler is saying "as far as I can tell
(modulo my current ability to do timely detection of dead code), this
code is going to have undefined behavior". That deserves a full
Besides a) and b), you have two other alternatives, both of which I
think are better:
c) SBCL doesn't need this kind of declaration (since it can figure it
out automatically through type inference -- once the program passes
through the test TYPEP X 'DOUBLE-FLOAT, all the code downstream
automatically knows that X is a DOUBLE-FLOAT). So you could make
the declaration conditional on the presence of :SBCL in *FEATURES*:
(WHEN (TYPEP X 'DOUBLE-FLOAT)
#-SBCL (DECLARE (TYPE DOUBLE-FLOAT X))
Or, for that matter, you could probably just delete the offending
declaration completely. (I'm guessing that since you're building
the code into SBCL, it is useful only for SBCL and possibly CMU CL;
and CMU CL does the same kind of type inference, so it doesn't need
the declaration either.)
d) If for some reason c) is not a good solution, you could
add an :IGNORE-FAILURE-P flag in the offending file's entry
in stems-and-flags.lisp-expr (with an explanatory comment,
please!). See the existing :IGNORE-FAILURE-P flag on
the "compiler/target/array.lisp" for an example, another
problem where I haven't been able to get the compiler to stop
issuing WARNINGs even though the code seems to work.
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C