#58 Compiler option (*$c-*) is broken

[Hideaki Tominaga]

Compiler option ($c-) is broken.

Minimal code that can reproduce this issue:

(*$t-,l+,d+,c-*)
program OptionTest(Output);
var
  i: Integer;
begin
  for i:=1 to 10 do 
    Writeln('Hello, world.');
end.

Result:

P5 Pascal compiler vs. 1.4.x
Pascal-P5 complies with the requirements of level 0 of ISO/IEC 7185.


     1      -28 {$t-,l+,d+,c-}
     2      -28 program optiontest(output);
     3      -28 var
     4      -28   i: Integer;
     5      -28 begin
     6        3   for i:=1 to 10 do
     6   ****               ^500
     7       15     writeln('Hello, world.');
     8       33 end.

Errors in program: 1

Error numbers in listing:
-------------------------
500  Compiler internal error

More errors occur in iso7185pat.pas.

[Scott Franco]

Thanks, I'll look it up.

General note: there are several fixes that went into P6 that didn't make it to P5. I did just go through a series of transfers from P6 to P5, but that was so that they would run the same test
suite (both negative and positive).

The purpose of replacing P5 with P6 is not just so that we don't have to perform backwards compatibility, but also because P5 is not really a practical stand-alone compiler, vs. the plan for P6 is.

Scott Franco
San Jose, CA

[Scott Franco]

Kicked forward, I don't have an installation of GPC that works at the moment. Windows 10/Ubuntu 20.04 both have issues.

[Hideaki Tominaga]

Because of the difficulty in getting GPC to work, I have modified Pascal-P5 so that it can be compiled in Delphi.
Passes ISO 7185 PAT. Of course, self-compilation is not possible.
https://github.com/ht-deko/Pascal-P5

[Scott Franco]

Well, good on you.

There are four paths to a working implementation. fpc used to be a one line change, if I recall it was down to oddities in the way fpc reads from header files. I was working with the FPC group to fix them, but it was too low on their priority list, and I gave it up.

gpc is now broken on both the Linux and windows (current implementation). I use the 2006 (frozen) copy so its down to bit rot. However, the issues looked minor and should be correctable.

The last one is the C interpreter in P6, which makes it dependent on gcc only. There is a recipe for that which generates .exes (it embeds the interpreter).

In short, it just needs some attention.

Scott Franco
San Jose, CA

[Scott Franco]

Verified. c- should turn the option off, no?

So what this is doing is suppressing the intermediate code generation, something I rarely do here. My guess is it is causing a bookkeeping error. Did you have a specific reason to turn this off?

Scott

[Hideaki Tominaga]

There is no specific reason to turn it off. I guess I can use it to check my grammar. The other reason is that it is an option that exists in Pascal-P4.
https://homepages.cwi.nl/~steven/pascal/book/1lexical.html#options

[Scott Franco]

Alright, a bit of progress.

First, the reason GPC won't run on my windows version is (I believe) it needs to be matched to a similar or exact version of mingw, since the gcc compiler needs to be 3.4.5. I couldn't locate that version offhand, I suspect at one time I did find it. In any case, the documentation does not go into this, and that is clearly wrong (my error). I don't really use windows for GPC anymore, the Linux version (yes, 2006, that version) is 64 bit, and less fussy about its environment, since it does not need the mingw package.

Second, to get the Linux GPC running I added:

PFLAGS=--classic-pascal-level-0 --no-warnings --transparent-file-names \
-L/usr/lib/gcc/x86_64-linux-gnu/9

To the make file, required in my case because I am running gcc version 9.3.0. I think it should actually go into the LIBRARY_PATH environment variable, I'll try a cleaner fix later.

With this setup I can reproduce the issue.

With regards to the ticket:

1. Yes, I undoubtedly broke it (c option) between P4 and P5. Likely P6 as well, I have not checked.
2. It will get fixed on both P5 and P6 (if broken).
3. The workaround is not to use the flag. It makes no functional difference, since you can simply discard the intermediate file.

Estimated fix time, 1 week.

Scott Franco

[Hideaki Tominaga]

Thank you. I appreciate it.

[Scott Franco]

As a side commentary, there are the versions p4, p5, and p6, and as many have discovered or decided, a fairly dramatic difference between p5 1.0 and 1.4 versions. The difference in these versions is that the error checking from the ISO 7185 standard was enforced in 1.4 version. So why didn't this justify a pX version?

The reason is in the mission statement. P5 was aimed at improving P4 into a full ISO 7185 compatible implementation. As many people have noticed, P5 1.0 will compile ISO 7185 code, but does an incomplete job of verifying it complies with ISO 7185 rules. So while I acknowledge that the P5 1.0 code is simpler, P5 1.4 and later truly implements the standard.

I like the P5 compiler. However, there is nothing in P5 that P6 does not also do, in fact I frequently check them against each other. So, for example, P6 can bootstrap itself on standard gcc whereas P5 cannot. I suspect that with the degeneration of GPC the time for that may have come, since (as you have seen), getting a GPC running is more of a challenge of late.

Scott

[Scott Franco]

As expected, P6 does not do this:

samiam@samiam-h-pc-2:~/projects/pascal/pascal-p6$ p6 test
Compiling test...
P6 Pascal compiler vs. 0.1.x
Pascal-P6 complies with the requirements of Pascaline version 0.4
and the following annexes: A,B,C,E.

 1      -48 (*$t-,l+,d+,c-*) 
 2      -48 program OptionTest(Output); 
 3      -48 var 
 4      -48   i: Integer; 
 5      -48 begin 
 6        7   for i:=1 to 10 do  
 7       17     Writeln('Hello, world.'); 
 8       36 end.

Errors in program: 0
P6 Pascal interpreter vs. 0.1.x

Assembling/loading program

*** Program load error: [18] unexpected eof on input

program complete

Meaning it got fixed in P6. The "eof on input" is because the intermediate was not found in pass 2.

As mentioned above, not every bug in P5 found in the P6 project was copied back to P5, since it was expected that users would move on to P6, which is completely upward compatible. It is simply to much work to keep them completely in sync.

Scott Franco
San Jose, CA

[Scott Franco]

Fixed. Here's the patch:

samiam@samiam-h-pc-2:~/projects/pascal/pascal-p5$ git diff
diff --git a/source/pcom.pas b/source/pcom.pas
index 66b53c0..cd93ed7 100644
--- a/source/pcom.pas
+++ b/source/pcom.pas
@@ -1439,7 +1439,7 @@ end;
if not list then writeln(output)
end
else if ch1 = 'd' then switch(debug)
- else if ch1 = 'c' then switch(prcode)
+ else if ch1 = 'c' then switch(prcode)
else if ch1 = 'v' then switch(chkvar)
else if ch1 = 'r' then switch(chkref)
else if ch1 = 'u' then switch(chkudtc)
@@ -3518,7 +3518,7 @@ end;
begin topnew := topnew + i;
if topnew < topmin then topmin := topnew;
if toterr = 0 then
- if topnew > 0 then error(500) { stack should never go positive }
+ if (topnew > 0) and prcode then error(500) { stack should never go positive }
end;

   procedure mes(i: integer);

@@ -5914,7 +5914,8 @@ end;
printed := false; chkrefs(display[top].fname, printed);
chkudf(display[top].fname);
if toterr = 0 then
- if topnew <> 0 then error(500); { stack should have wound to zero }
+ if (topnew <> 0) and prcode then
+ error(500); { stack should have wound to zero }
if fprocp <> nil then
begin

Pushed to repo.

Scott Franco
San Jose, CA

[Hideaki Tominaga]

Mm... I think the issue occurs when the variable topnew is set to non-zero when prcode = False. It looks like this patch just stops the error from being displayed, but doesn't it affect the subsequent processing?

Do you get any errors when you try iso7185pat.pas?

[Scott Franco]

It does not throw an error on balance cases. Those checks were put in by me (reference the p4 code). The balance condition does not get corrected, but this is just bookkeeping for the error,
which is done on expression temps allocs and stack local allocs. No side effects.

I didn't run a full test suite on p5, but p6 was run on full test suite. Let me know.

Scott

PS offsets generated by the expression temps are wrong, which are discarded because the intermediate is discarded. Theorectically there is an overflow issue, but you would have to compile megabytes of code to trip that.