pl1 generates incorrect code for string concatenation in some cases (MCR10029)

[Charles]

In cat_op:

switch(1):

ea: if ^{p1 -> reference.long_ref}

then do;

if size2 ^{= bits_per_word then goto ee1;
if p2 -> reference.ref_count < 1 then call compile_exp(q2);
else p2 = compile_exp$save(q2); /* needed later */
goto aa_2a;
end;}

the code does the "compile_exp$save(q2)" which generates the csl to temporary storage,and goes to aa_2a.

aa_2: if size2 = bits_per_word & mod(code,2) ^{= 0}

then do;

call expmac((lda),p2);

aa_2a: call expmac((ldq),p3);

end;

else do;

aa_3: call compile_exp(q3);

There we see the missing 'lda'. Moving the label up one, the compiler generates:

tbits = fbits

(16)"0"b;

000011 aa 6 00032 3735 20 epp7 pr6|26,*
000012 aa 7 00002 3715 20 epp5 pr7|2,*
000013 aa 003 100 060 500 csl (pr),(pr),fill(0),bool(move)
000014 aa 5 00000 00 0044 descb pr5|0,36 fbits
000015 aa 6 00102 00 0044 descb pr6|66,36 fbits
000016 aa 6 00102 2351 00 lda pr6|66 fbits
000017 aa 000000 2360 07 ldq 0,dl
000020 aa 6 00100 7571 00 staq pr6|64 tbits

which is looks correct.

Building the test code with the patched compiler:

r 11:07 0.790 27

[pwd]>pl1 -list testbitcat
PL/1 33e
r 11:08 0.870 26

[pwd]>testbitcat

ubits = 000073FC4D9598677

fsbits = CFF136566 (12/02/16 1108.1 pst Fri)

The inline results:

assignbits = CFF1365660000
substrbits = CFF1365660000
concatbits = CFF1365660000

The subroutine results:

assignbits = CFF1365660000
substrbits = CFF1365660000
concatbits = CFF1365660000

r 11:08 0.110 0

In so sense do I believe that this fix is correct; it is a blind stab, and requires review by someone who understands the compiler. It appears to fix testbitcat, but who knows what it breaks.

test source at: ​https://sourceforge.net/projects/dps8m/files/drop/Charles/testbitcat.pl1

[admin]

I created a version of the compiler with a call to ioa_ to alert the user if the code path in question was executed, and then recompiled all of hardcore. No messages were displayed. So no hardcore modules are affected by either fixing or not fixing this bug. I'm going to perform the same exercise on >sss, >tools, and >unb.

[Eric Swenson]

Here are the list of PL/1 segments that exercise the code path in question:

hardcore: init_empty_root.pl1, tape_mult_parse_.pl1, log_wakeup_.pl1

sss: check_info_segs.pl1

tools: tolts_ttyio_end_pl1, mtdsim_.pl1

unbundled: comp_write_page_.pl1, process_compout.pl1, *ibm2780_.pl1*, gtss_abs_.pl1, apl_parse_.pl1

None of these segments was compiled with the 33e (MR12.5, buggy) compiler, except ibm2780_.pl1. That module might have incorrect code generated for a bit concatenation. It should get recompiled with a compiler that includes a fix for this issue.

[Eric Swenson]

MCR10029 addresses this issue: ​http://swenson.org/multics_wiki/downloads/doc/MCR10029.pdf

[Eric Swenson]

MCR10029 approved, implemented, and audited as of 2/11/2017. Compiler being bootstrapped in preparation for installation in MR12.6f.

[Eric Swenson]

Fix installed on GHM. Will be in MR12.6f.