ToC | DocOverview | CGDoc | RelNotes | FAQ | Index | PermutedIndex
| Allegro CL version 11.0

# align-branch-targets-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`. This switch additionally may return certain integers which are true values (meaning the switch will affect compilation on platforms where it has effect) but provide finer control on that effect.

This switch affects compilation on x86 64-bit systems and Panasonic IPP3 systems only (the IPP3 implementation is not a publically released port). On all other platforms, this switch is ignored.

The issue addressed by this switch is the following. The final stage of the Lisp compiler is the in-core assembler, which works very similarly to any other assembler for the architecture it serves. Code is usually in-line, and when possible, optimization phases before the assembler phase will remove as many branches as possible. But branches are inevitable, and architectures are generally optimized for branches that land on evenly aligned byte boundaries, due to instruction fetch and optimization implementations.

For AMD64 architecture, it is recommended that assembler labels which are the target of branches be placed on 32-byte boundaries, and that no more than 3 branches be placed in any one 16-byte segment of code. There are many intricacies, but we have decided to halve the alignment performed by default, so labels are aligned to 16 bytes and are forced there by a series of nop instructions. This is actually as large as can be done in a 64-bit lisp, since code vectors, along with all other Lisp objects, are aligned to 16-byte boundaries themeselves. The IPP3, which is a 32-bit lisp, aligns to 8 byte boundaries for the same reason.

There are currently three kinds of branches which might be affected by alignment: backward branches, Forward bracnches of more than 16 bytes, and forward branches of less than 16 bytes.

If this switch returns `nil`, then none of these targets are aligned. If it returns a value of true which is not a fixnum, then all backward and longer-than-16-byte forward branches are aligned.

If this switch is set to a fixnum value, or if it is set to a function of the 5 optimization qualities and returns a fixnum value, then it is interpreted as a bitwise value whose least significant bit (the 1 bit) signifies whether backward-branches should be aligned, the 2 bit signifies whether long forward branches should be aligned, and the 4 bit signifies whether short branches should be aligned. In each of these cases, if the bit is 1, then the alignment is performed, and if it is 0, then the alignment is not performed.

Initially true if speed is 3 and compilation-speed is 0 or 1.

# *cltl1-compile-file-toplevel-compatibility-p*

variable, compiler package

If the value of this variable is true, CLtL-1 compile-time-too behavior will be used when compiling a file. That means that top-level forms calling the functions listed below need not be wrapped in an appropriate eval-when form in order for them to have effect while a file is being compiled. If the value is the symbol `warn` (which is the initial value), a warning will be printed whenever a form is encountered where CLtL-1 compile-time-too behavior is used. (Note: it is likely that complex files will generate many warnings.) If the value is `nil`, ANSI compile-time-too behavior is used. We recommend that you modify all files to conform to ANSI behavior as soon as possible.

By compile-time-too behavior, we refer to the effect of certain top-level forms in a file being compiled. In CLtL-1, top-level forms which were calling the functions listed below were treated as if they were wrapped in an

    (eval-when (compile))

form. That behavior has been changed in the new standard and you must wrap such forms in appropriate eval-when forms if they are to have effect while a file is being compiled. The affected functions are:

- proclaim
- make-package
- shadow
- shadowing-import
- import
- export
- unexport
- use-package
- unuse-package
- require

See compiling.html for information on the compiler.

# compile-format-strings-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

When true, a format string (the second required argument to format) is converted to a tree structure at compile time. If `nil`, the conversion is done at run time, resulting in slower printing but smaller code. Initially true when speed is greater than space.

See compiling.html for information on the compiler.

# compile-macroexpansions-for-safety-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

Initially true only when safety is 3.

The effect of this switch is not as drastic as actually declaring a function to be `notinline`, but it covers more situations. Normally it is the compiler that looks at compiler switches, and makes decisions based on their outcomes, but this switch is actually consulted at macroexpansion time if the compiler is present in the Lisp. This includes regular macros as well as compiler-macros, because macros can lose safety just as easily as compiler-macros.

Currently this switch only affects how defstruct accessors are expanded. If the switch returns true, an accessor that checks for the correct struct type is generated, so that the following:

    CL-USER(18): (defstruct test1 slot1 slot2)
    TEST1
    CL-USER(21): (defstruct test2 slota slotb)
    TEST2
    CL-USER(22): (test1-slot1 (make-test2))

will generate a type error.

When the switch is `nil`, or if the older accessor (which is a closure shared by all other defstruct accessors using the same slot index) is being used, the compiler generates code similar to that in 10.1, i.e that either only checks that the argument is indeed a structure, or else is only one instruction and makes no checks at all. Whether the accessor is the old, unsafe one or the new safe accessor depends on the current value of *expand-defstruct-accessors-unsafely*

See defstruct implementation in implementation.html for more information on defstruct accessors.

See compiling.html for information on the compiler.

# declared-fixnums-remain-fixnums-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

If this switch is true, the compiler will generate code that assumes the sums and differences of declared fixnums are fixnums and that the negative of a single declared fixnum is a fixnum. This switch affects + (e.g. `(+ x y)`) and also + analogs like 1+ and incf, and - (e.g. `(- x y)` or `(- x)`) and also - analogs like 1-, decf and abs.

No assumptions are made about the results of multiplication, division, shifting, or any operation other than + and - and their analogs.

Initially true only if speed is 3 and safety is 0. Non-compliance note: having this switch be true is not compliant with ANSI Common Lisp, which requires that fixnum arithmetic work correctly in all cases. You may turn this switch off entirely by evaluating:

    (setf comp:declared-fixnums-remain-fixnums-switch nil)

Warning: if this switch returns true during compilation but the result of the sum or difference of declared fixnums or of changing the sign of a single declared fixnum is not a fixnum, the compiled code will silently produce erroneous results. Changing the sign includes applying abs to a negative value -- `(abs most-negative-fixum)` which equals `(- most-negative-fixnum)` is a bignum. See Declared fixnums example for examples of incorrect results silently produced because the results of operations on declared fixnums are bignums.

See compiling.html for information on the compiler.

# generate-accurate-x86-float-code-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

This switch affects platforms using 32-bit x86 processors only. These processors can do fast floating-point calculations in 80-bit mode which, if intermingled with 32-bit or 64-bit mode calculations can produce different results in the lower bits from run to run, unless certain flags are set. If this switch is true, those flags are set, but there is a fairly significant computation speed hit if they are. If you want fast computations and are willing to accept lack of repeatability in the lower bits (that is, possibly slightly different answers from run to run), you can compile with this switch false (as it is when speed is 3 and safety 0). If you want the same answer every run, ensure that this switch is `nil`.

We should note that floating-point operations are inherently inaccurate in the lowest bits, so it terms of usefulness of the results, this switch make little or no difference. Also, you may get (on any platform) different answers in the lowest bits from run to run if calculations are done in different orders (as might happen if multiprocessing is used and parts of the calculation is done by different processes which may run in different orders from run to run). If a calculation is unstable (matrix inversion, for example, when the determinant is close to zero), which means that a small change in input results in a much larger change in output, you may see noticeable differences in results when this switch is false, but that is in fact a symptom of the unstable nature of the inputs resulting in untrustworthy results.

If it can be guarateed that the floating point operations are of the same size within a given code segment, the accuracy should not suffer even when this switch returns `nil`. However, for the best guarante of accuracy, at speed cost, this switch should return true.

Initially true if speed is 3 and safety is 0.

See compiling.html for information on the compiler.

# generate-inline-call-tests-switch

variable, compiler package

This compiler switch was rendered ineffective in release 5.0.1. It was undocumented for many releases, but never unexported. In keeping with the desire to document all exported symbols, we have added the documentation back. Setting the value of this variable has no effect. Code which refers to this variable should be removed.

See compiling.html for information on the compiler.

# generate-interrupt-checks-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

If true, code that checks for an interrupt (Control-C on Unix, Break/Pause on Windows) is added in two places in compiled code: (1) at the beginning of the code vector and (2) at any place there is the equivalent of a go in a tagbody (one such place is at least once in an iterative constructs like loops). The initial value is false (meaning that interrupt checking code is not added) only if speed is 3 and safety is 0.

Note that a loop that does not call functions will not be interruptable (either by user action or process/thread preemptions) though users can interrupt by multiple Control-C's (Unix) or using the Franz icon on the system tray (Windows). See startup.html for more information on interrupting when all else fails.

See compiling.html for information on the compiler.

# internal-optimize-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

When true, the register-linking internal optimization is performed, resulting in faster but harder to debug code, which takes longer to compile. Initially true when compilation-speed is less than 2 and either speed is greater than 2 or debug is less than 3. Initially returns `nil` when compilation-speed is 2 or 3 regardless of other values.

See also optimize-large-functions-switch. See compiling.html for information on the compiler.

# optimize-fslot-value-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

When true, calls to fslot-value-typed and fslot-address-typed will be opencoded if possible. See ftype.html. Initially true when speed is greater than safety.

See compiling.html for information on the compiler.

# optimize-large-functions-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

Bound to a function which, given safety, space, speed, debug, and compilation-speed returns `t` if the compiler should continue to provide high optimizations for functions which have grown to become very large. (Doing so might reduce compilation speed significantly.)

There is a definition of "very large", but we are not providing it here, as it may change and the measure requires a lot of explaining. If a function is not 'very large', its compilation is unaffected.

If compilation seems unexpectedly slow, try setting this switch to nil. If that significantly speeds things up, then some function or functions are "very large" when compiled and you can figure out which they are and how much you want to balance compilation speed and execution speed, using declarations which set the value of compilation-speed on a function by function basis to get the balance you want. (Functions which are not very large will compile the same regardless of the value of this switch.)

Initially true if compilation-speed is less than 2. It is important to keep in mind what the switch means: if true, take as long as necessary to compile. If `nil`, quit optimizing if the task takes too long (as indicated by the compiled function becoming too large).

See also internal-optimize-switch. See compiling.html for information on the compiler.

# peephole-optimize-switch

variable, compiler package

This switch no longer has effect. The variable still exists and can be set but its value has no effect on compilation. Its value is not displayed by the explain-compiler-settings function.

See compiling.html for information on the compiler.

# reorder-folded-constants-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the `safety`, `space`, `speed`, `debug`, and `compilation-speed` optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

If true the constant-folding mechanism in the compiler aggressively reorders expressions so that constants can be merged at various levels of computation. This is not a problem for integers, but floating point calculations are sensitive to the order of evaluation. Arrange for this switch to be/return `nil` if it is desired that numeric (especially floating point) calculations should be consistent with interpreted code and/or with results of release 10.1 (agressive constant folding was introduced in version 11.0). See also the section Numeric calculation ordering and consistency in compiling.html for more information.

Initially, this switch is/returns true when speed is 3 and safety is 0 or 1.

See compiling.html for information on the compiler.

# save-arglist-switch

variable, compiler package

This switch no longer has effect. The variable still exists and can be set but its value has no effect on compilation. Its value is not displayed by the explain-compiler-settings function.

See compiling.html for information on the compiler.

# save-local-names-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

If true, the names of local variables will be saved in compiled code. This makes debugging easier. Initially true when debug is greater than 1.

See also *load-local-names-info*.

See compiling.html for information on the compiler.

# save-local-scopes-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

If true, information about when local variables are alive is saved in compiled code, making debugging more easy. Initially true only when debug is 3.

See also *load-local-names-info*.

See compiling.html for information on the compiler.

# save-source-level-debug-info-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

Bound to a function which, given safety, space, speed, debug, and compilation-speed, returns `t` if the compiler should save information in fasl files useful for source-level debugging (see The source stepper) and for coverage analysis (see with-coverage).

Initially true if debug is greater than 2.

Note: when this switch is true, the compiler uses more stack. If you have problem compiling because of stack overflows, evaluate `(setq comp:save-source-level-debug-info-switch nil)` to suppress collection of the data.

See compiling.html for information on the compiler.

# tail-call-non-self-merge-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

If true, compiler will perform non-self-tail-merging (for functions in the tail position different than the function being executed). This switch will affect code only when true at the point of the call.

See Tail merging discussion for more information on tail-merging. Initially true if speed is greater than 1 and debug less than 2.

See compiling.html for information on the compiler.

# tail-call-self-merge-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

If true, compiler will perform self-tail-merging (for functions which call themselves). This switch will affect code only when true at the beginning of the function being self-called (and no other time).

See Tail merging discussion for more information on tail-merging.. Initially true when speed is greater than 0.

See compiling.html for information on the compiler.

# trust-declarations-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

If true, the compiler will trust declarations in code (perhaps other than dynamic-extent declarations -- see trust-dynamic-extent-declarations-switch) and produce code (when it can) that is optimized given the declarations. These declarations typically specify the type of values of variables. If `nil`, declarations will be ignored -- except (declare notinline) and (declare special) which are always complied with.

Initially, this switch is true when speed is greater than safety.

See compiling.html for information on the compiler.

# trust-dynamic-extent-declarations-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

If true, and if the compiler trusts declarations (that is trust-declarations-switch is true), the compiler will trust dynamic-extent declarations in code and produce code (when it can) that is optimized given the declarations. One optimization that is possible when objects are declared dynamic-extent (and the declaration is trusted) is stack allocation (where the object is stored on the stack and not in memory, see Stack consing, avoiding consing using apply, and stack allocation in compiling.html).

Having a switch which controls dynamic-extent declarations when declarations are trusted (via the general trust-declarations-switch) allows dynamic-extent declarations to be ignored while other declarations are trusted. When using multiprocessing, trusting `dynamic-extent` declarations may be unsafe when trusting other declarations is safe. See Stack consing, avoiding consing using apply, and stack allocation in compiling.html for a discussion of the issues surrounding multiprocessing and dynamic extent.

If trust-declarations-switch is `nil`, this switch is ignored.

Initially true when speed is greater than or equal to safety, which means that this switch will be true in the default when the trust-declarations-switch is true in the default (which is when speed is greater than safety). If there is an issue with multiprocessing, you should bind or set this switch to `nil`, or design your own function.

See compiling.html for information on the compiler.

# trust-table-case-argument-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

This switch modifies the behavior of a case macro form which would be compiled in a table-driven fashion. Normally all values are checked, including ranges and types, and although the method of testing is very efficient, it contributes to the overhead of the case form. When trust-table-case-argument-switch returns true, and when the type of the test value is limited to what is acceptable by a table-driven case statement (see ;Itab labels in compiler-explanations.html), then the overhead of testing for this type and range is removed, and the case form gets more efficient.

This optimization is not implemented in all architectures (the value is ignored on architectures where it is not implemented). It is implemented at least on x86 and amd64 based versions of Allegro CL, and may be implemented on others as needed.

This declaration may cause erros when variables are not of the type declared and these errors may cause incorrect results rather than actual errors. Like all speed 3/safety 0 switches, this one whould be used with care.

See compiling.html for information on the compiler.

# verify-argument-count-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

If true, the compiler will add code that checks that the correct number of arguments are passed to a function. Initially true if speed is less than 3 or safety is greater than 0.

See compiling.html for information on the compiler.

# verify-car-cdr-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

If true, code calling car and cdr will check that the argument is appropriate (i.e. a list). The switch is only effective on platforms which have `:verify-car-cdr` on the *features* list. Platforms lacking that feature ignore this switch since the verification is done differently but always. Initially true if speed is less than 3 or safety is greater than 1.

See compiling.html for information on the compiler.

# verify-format-argument-count-switch

variable, compiler package

This compiler switch can direct the compiler to examine format statements being compiled to check whether the number of arguments supplied in the format statement corresponds to the number called for in the format control string. Further it will be consulted whenever the compiler is available in the Lisp and the formatter function is compiled (i.e. expanded into its state tree).

Format statements may have the exact number of arguments called for:

    (format t "~d days left for a ~d percent discount~%" 10 20)

Too few arguments:

    (format t "~d days left for a ~d percent discount~%" 10 )

Or too many arguments:

    (format t "~d days left for a ~d percent discount~%" 10 20 30 40)

Having exactly the number of arguments called for is normal practice. It is not an error (indeed it is explicilty permitted) to have more than are called for. Having too few is not in itself an error but if the form is ever evaluated, an error will be signaled.

This compiler switch variable differs from other in that its value can be one of the integers 0, 1, 2, 3, and 4, as well as `nil` (equivalent to 0) and `t` (equivalent to 2). Actually, any non-`nil` value other than 0, 1, 2, 3, and 4 is equivalent to `t` (which, again, is equivalent to 2).

When the value of this switch is 1, 2 (or `t`), 3, or 4, then when a format form is compiled, information is collected on whether the number of arguments supplied is less than, equal to, or more than the number called for in the format string. If the format string is too complex to analyse (perhaps because it will not be known until run time whether or not there are enough arguments), that information is also collected. Finally, if certain errors in the format form are detected, that information is collected.

Like other switches, this one can be set or bound to one of the legal values, or set or bound to a function object that accepts five arguments and returns `t` or `nil` or 0, 1, 2, 3, or 4. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order.

Here is the behavior for the various values of the switch:

- 0 or `nil`: Collect no statistics, signal no warning or compiler notes.
- `t`, 1, 2, 3, or 4: Collect statistics about format argument counts compared to what is called for in format strings; about format strings too complex to analyze; and about syntactic errors in format forms.
- 1: Gather statistics only. Signal no warnings or compiler notes.
- `t` or 2: Gather statistics, signal style-warning if not enough arguments.
- 3: Like 2, but signal a compiler-note when too many arguments are detected. (It is not an error to supply too many arguments, but a compiler-note can be useful if that is not what is intended.)
- 4: Like 3, but also signal a compiler-note when a format string is too complex to analyse.

Statistics are only kept if the value of the variable *format-arg-count-stats* is a list of six fixnums (representing all, missing args, args equal in number to needed, args more than needed, too complex, and syntax error). These numbers are incremented appropriately as format forms are analysed. Warnings and compiler-notes are printed if the switch value calls for them. The function format-arg-count-stats prints the collected statistics.

This switch is initially bound to a function which returns 1 for safety 0 and compilation-speed 0 or 1; returns 2 for safety 1, 2 or 3 and compilation-speed 0 or 1; and returns 0 for compilation speed 2 or 3. The initial values of safety and compilation-speed are both 1, so initially this switch returns 2.

See Checking format forms during compilation in miscellaneous.html for more information.

# verify-funcalls-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

If false, funcall's of objects which are known to be funcall'able at compile time will be compiled in such a way that the jump is directly to the function start addresses. This speeds up funcall'ing but at the cost of easier debugging (as stepping and profiler call counting will not work). That is why this variable is true for debug values other than 0. Initially true (i.e. slower funcall's) if speed is less than 3 or if safety is greater than 1 or if debug is greater than 0.

See compiling.html for information on the compiler.

# verify-non-generic-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

If true, code is generated that an object of undeclared type is of the correct type when it appears as the argument to specialized functions like svref and rplaca. Thus the argument to svref must be a simple vector and, if this switch is true, code will check that (and give a meaningful error message). See Argument type for a specialized function example for an example. Note that generic has nothing to do with (CLOS) generic functions. The name long predates CLOS.

Initially true for speed less than 3 or safety greater than 1.

See compiling.html for information on the compiler.

# verify-stack-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

This switch only has effect on platforms with `:verify-stack` on the *features* list. On such platforms, checking whether the stack pointer has gone beyond the stack cushion is expensive. (A stack cushion is an artifical stack limit.If Lisp can detect when this limit is reached, it can warn that the stack is about to be exhausted -- if the stack truly runs out, Lisp will fail.) If this switch is nil, code is not added to check the stack cushion.

Highly recursive functions, at least, should be compiled with this switch true since they might cause unrecoverable stack overflow. In general, we do not recommend globally setting speed to 3 and safety to 0, which is what causes this switch to be `nil`, but instead selectively compiling functions at that setting when it is known that having this switch `nil` will not cause a problem.

See compiling.html for information on the compiler.

# verify-symbol-value-is-bound-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

If true, code will be added to ensure that a symbol is bound before the value of that symbol is used. The result (as shown in Bound symbol example) is a guaranteed error and a better error message in code compiled with this switch true. Initially true if speed is less than 3 or safety is greater than 1.

In code compiled when this switch returns `nil`, when a symbol is evaluated, the contents of the symbol-value slot of the symbol object are accessed. If the symbol is unbound, those contents may nonetheless be apparently valid and will be used without further checking. This can lead to mysterious failures later in execution or in apparently valid but in fact invalid results.

See compiling.html for information on the compiler.

# verify-type-declarations-switch

variable, compiler package

As with most compiler switch variables, the value of this variable can be `t`, `nil`, or a function object that accepts five arguments and returns `t` or `nil`. The arguments passed to the function will be the values of the safety, space, speed, debug, and compilation-speed optimization qualities, in that order. `nil` is equivalent to a function that always returns `nil` and `t` to a function that always returns `t`. When the value is a function and we say `t` (or true) or `nil` (or false) in the text below, we mean that the function returns, respectively, `t` or `nil`.

Code compiled with this switch true will have additional runtime type checking done of any lambda or let bindings of a declared variable and any setqs to that variable to ensure that the value is of the correct type. If the variable is bound to an inappropriate value, a continuable type-error is generated.

The declared types are checked in the following three places:

1. The binding of a lexical variable in a lambda form

2. The binding of a lexical variable in a let form

3. The setq'ing of a lexical variable

Further:

- The variable must be lexical (currently closed-over and special variables are excluded).

- The declaration must be in effect during the operation where the check might be performed (this excludes free declarations after the fact, but does not exclude setq's within the scope of the free declaration).

- The verify-type-declarations-switch must return true at the point of the binding or set. Like trust-declarations-switch, a declaration at the beginning of a lambda or let form has a scope which includes the bindings of the lambda/let variables to be bound.

### Example

As we note below, in the default this switch is true when safety is greater than 1. Speed 3/Safety 2, used in this example, makes this switch and the various trust-* switches true in the default.

    cl-user(1): (compile
                  (defun foo (x y)
                    (declare (optimize (speed 3) (safety 2)) (integer x))
                    (setq x y)
                    (let ((z x))
                      (declare (fixnum z))
                      z)))
    foo
    nil
    nil
    cl-user(2): (foo 10 20)
    20
    cl-user(3): (foo 10 (1+ most-positive-fixnum))
    Error: about to bind z to 536870912, which is not of type
           (integer -536870912 536870911).
      [condition type: type-error]

    Restart actions (select using :continue):
     0: store the value anyway.
     1: Return to Top Level (an "abort" restart).
     2: Abort entirely from this (lisp) process.
    [1] cl-user(4): :cont
    536870912
    cl-user(5): (foo 10 20.0)
    Error: about to setq x to 20.0, which is not of type (integer * *).
      [condition type: type-error]

    Restart actions (select using :continue):
     0: store the value anyway.
     1: Return to Top Level (an "abort" restart).
     2: Abort entirely from this (lisp) process.
    [1] cl-user(6): :res
    cl-user(7): (foo 10.0 20)
    Error: about to bind function argument x to 10.0, which is not of type
           (integer * *).
      [condition type: type-error]

    Restart actions (select using :continue):
     0: store the value anyway.
     1: Return to Top Level (an "abort" restart).
     2: Abort entirely from this (lisp) process.
    [1] cl-user(8):

Initially true if safety is greater than 1. This means that (optimize (speed 3) (safety 2)) is (with default values) the only safety/speed combination that turns on both this switch and trust-declarations-switch and trust-dynamic-extent-declarations-switch.

See compiling.html for information on the compiler.

Copyright (c) Franz Inc. Lafayette, CA., USA. All rights reserved.

ToC | DocOverview | CGDoc | RelNotes | FAQ | Index | PermutedIndex
| Allegro CL version 11.0