Compiler crash with foreign types and very specific options in ssdebug grades
Closed this issue · 4 comments
I found a compiler crash which affects compiling using intermodule optimizations, some optimization levels (at least -O 6, although -O 1 seems to be fine), grade subdirs, and ssebug grades. I'm using the 2020-04-28 ROTD, and specifically the hlc.gc.spf.ssdebug grade.
It seems to be related to a module having a predicate that accepts a foreign type in the interface (possibly just something like array(foreign)). This crash also occurs when compiling https://github.com/juliensf/mercury-json in the json.m module, but fortunately I found a much smaller module in my program which also has this problem which was easier to reduce.
The specific command I used for the linked source file is:
mmc --make crash -O 6 --intermodule-optimization --use-grade-subdirs --grade=hlc.gc.spf.ssdebug
I've had a look using the current ROTD. We can reduce the command line needed to reproduce the bug to:
mmc --make crash.c -O3 --intermodule-optimization --grade=hlc.gc.ssdebug
So, the problem is specifically with the .ssdebug component. Compiling at -O2 yields:
Warning: cannot open `Mercury/opts/ssdb.opt'
I think this problem may be related to the fact we are not building and/or installing the optimisation interface for the ssdb library.
Actually, it's nothing to do with the lack of ssdb.opt since we treat the modules for mdb similarly. There's an abort occurring in compiler/ssdebug.m in one of the calls to list.det_drop/3 at -O3 --intermodule-optimization and above.
The issue here is that the source-to-source debugging transformation is attempting to transform a predicate introduced by the higher-order specialisation optimisation (for the specialisation of the call to array.foldl2/6 in the test case). The source-to-source debugging transformation is attempting to compute the number of arguments minus the number of arguments introduced by the polymorphism transformation; it unfortunately is not aware that higher-order specialisation has removed the higher-order argument, so it calls list.det_drop/3 with a negative first argument. (This probably used to work by accident because before Mercury 20.01, drop would have accepted a negative first argument.)
I think the short of this is that you need to be quite conservative with what optimisations, if any, are enabled when in .ssdebug grades for the time being since it doesn't appear as though that transformation is particularly aware about what other parts of the Mercury compiler are doing.
Thank you for the fix, even if it's only a temporary solution!