issue#-188 compiler trap with SYSTEM.VAL

[Josef Templ]

I have created this issue for fixing a compiler trap when using SYSTEM.VAL in a very special case.
See https://redmine.blackboxframework.org/issues/188.

After some analysis it turned out that the compiler correctly reports an error but in subsequent steps it generates a trap
and that is why the error message is not shown.

A simple work around is to replace the ASSERT by an error message
in DevCPL486.CheckForm leading to

Code: Select all

	PROCEDURE CheckForm (form: BYTE; VAR mf: INTEGER);
	BEGIN
		IF form = Real32 THEN mf := 0
		ELSIF form = Real64 THEN mf := 4
		ELSIF form = Int32 THEN mf := 2
		ELSIF form = Int16 THEN mf := 6
		ELSE DevCPM.err(111); mf := 2
		END
	END CheckForm;

But I am not sure that this is the best place for the fix.

- Josef

[Josef Templ]

I have fixed the bug now with a different approach.
If detecting an illegal SYSTEM.VAL the resulting item (x) is set to the target form (f) and a dummy mode (Stk).
This avoids all traps known so far.

For the diffs see https://redmine.blackboxframework.org/p ... 0d3f0409c2.

- Josef

[Robert]

I have fixed the bug now with a different approach.

Thanks; that works nicely with my reported issue.
(Hopefully it has not introduced any nasty side-effects!)

It is an odd coincidence that both Oleg & I should encounter this bug, which presumably has been there for a long time, within a day or two of each other.
It is an even odder coincidence that I should come across it while working on a problem that Oleg asked me about.

[Josef Templ]

Thanks; that works nicely with my reported issue.
(Hopefully it has not introduced any nasty side-effects!)

It is an odd coincidence that both Oleg & I should encounter this bug, which presumably has been there for a long time, within a day or two of each other.
It is an even odder coincidence that I should come across it while working on a problem that Oleg asked me about.

Aaah, you were in contact with Oleg. That explains the coincidence.

Anyway, there cannot be any side effects to correct programs because the change only affects
the case where an error is reported due to SYSTEM.VAL limitations.
The fix only sets the result of the failed conversion such that the code generator
can continue with the current statement. After that it will terminate anyway.

- Josef

[Robert]

Hopefully it has not introduced any nasty side-effects!

Anyway, there cannot be any side effects to correct programs because the change only affects
the case where an error is reported due to SYSTEM.VAL limitations.

Just out of idle curiosity, do we understand how this bug was introduced, since it apparently was not in BlackBox 1.6?

[Josef Templ]

Just out of idle curiosity, do we understand how this bug was introduced, since it apparently was not in BlackBox 1.6?

Yes, the trap you observed was a side effect of the fix in issue-#126, which removed
another trap that appeared before the fix.
The fix was at the same place in the code generator.
The current fix completes/improves the fix of issue-#126, hopefully.

- Josef

[Robert]

The current fix completes/improves the fix of issue-#126, hopefully.

Is this a related, or new, bug? I think the PSI document says this is legal, but the error message is "unsupported mode of size of second argument of SYSTEM.VAL"?

Code: Select all

PROCEDURE  Do;
  VAR
    a, b   :  LONGINT;
    x      :  REAL;
  BEGIN
    x  :=  SYSTEM.VAL(REAL, a + b);
  END  Do

[Josef Templ]

This was also flagged by the compiler before the fix.
The fix does not add any new checks or restrictions.
It only avoids follow-up traps after an error has been detected.

- Josef

[Robert]

This was also flagged by the compiler before the fix.

But thats the bug; it should not be flagged, I think.

If that is correct we need a new issue.

[Josef Templ]

This is a property of the i386 architecture.
It has different register sets for integers and reals.
Therefore it is not possible to treat an integer register as a real and vice versa.

If you want to convert integers and reals you must make sure that they are in memory.
You can cast a LONGINT variable to a REAL and vice versa but not a register.
All you need is an auxiliary variable.

- Josef