Summary

Some compiler rewrites marked "safe" are really unsafe

Metadata

Description

Due to a currently unknown reason, sometimes the scrutinizer seems to be able to prevent hardwired compiler rewrites from being done.

If the following code is interpreted, it will print two lines saying "error". If it is compiled, it will either print "error" and "smaller", or in case of a DEBUGBUILD, it will print "error" and show a low-level type assertion error.

 #!scm
 (use ports)
 (handle-exceptions exn
     (print 'error)
     (print (if (char<? 1 #\a) 'smaller 'bigger-or-equal) ))
 (handle-exceptions exn
     (print 'error)
     (print (if (char<? (with-input-from-string "1" read) #\a)
                'smaller 'bigger-or-equal)))

Perhaps it's a good idea to remove the compiler rewrites completely (they are in c-platform.scm), and, where suitable, move the rewrites to types.db. This will prevent bogus rewrites like the one above, and should also make the compiler simpler. We must ensure this doesn't mess up performance too bad. Benchmarking will help.

Changes and comments

[2015-08-27 08:49:10 UTC] sjamaan changed milestone from 4.10.0 to 4.11.0

[2015-08-27 08:49:10 UTC] sjamaan wrote:

See also #1216; it shows that this bug is more serious than previously thought

[2015-11-20 15:01:17 UTC] sjamaan wrote:

OK, the "unknown reason" is now known: The topmost call won't get replaced due to attempted constant-folding via constant-form-eval, which fails (due to the exception), and therefore added to the broken-constant-nodes list.

These broken constant nodes are exempt from simplification in optimizer.scm, right at the top of walk in perform-high-level-optimizations. This is unrelated to #1216, I think.

[2015-11-20 15:03:33 UTC] sjamaan changed summary

[2015-11-30 14:07:55 UTC] sjamaan changed status from new to closed

[2015-11-30 14:07:55 UTC] sjamaan set resolution to fixed

[2015-11-30 14:07:55 UTC] sjamaan wrote:

Fixed with 379a019 / 274e7af