Page 2 of 2

Re: issue-#209 Compiler trap in Real64 op ADR(x)

PostPosted: Mon Sep 14, 2020 5:54 pm
by luowy
1,though they all in backend, but they are at different level, upper is better than lower. if you can solve it in frontend ,that will be best.
2, i agree with you, no need to intro unsigned type, use the integer type is good enough.

P.S. I will be offline for a few days, don't wait for my reply.

Re: issue-#209 Compiler trap in Real64 op ADR(x)

PostPosted: Fri Oct 23, 2020 8:06 pm
by Josef Templ
I would like to propose to resume the voting on this issue.
The proposed fix is simple and looks plausible and I was not able to find a better alternative.

- Josef

Re: issue-#209 Compiler trap in Real64 op ADR(x)

PostPosted: Sat Oct 24, 2020 4:01 am
by luowy
Josef Templ wrote:I would like to propose to resume the voting on this issue.
The proposed fix is simple and looks plausible and I was not able to find a better alternative.

- Josef
You can refer to my solution:DevCPC486.ConvMove
Code: Select all
   | Int32, Set, Pointer, ProcTyp:
               IF xform = Char8 THEN CheckRange(y, 0, 255); FreeHi(y)
               ELSIF xform = Char16 THEN CheckRange(y, 0, 65536);
               ELSIF xform = Int8 THEN CheckRange(y, -128, 127); FreeHi(y)
               ELSIF xform = Int16 THEN CheckRange(y, -32768, 32767)
               ELSIF xform = Int64 THEN LoadLong(y, hint, stop)

               ELSIF (y.form = Pointer)&(xform IN {Real32, Real64}) THEN y.form := Int32; (*add this line*)
               END
this function is dedicated to transform different type in backend, first part is conversion, second part is movement, the fix is in the conversion part, is higher than DevCPL486.

Re: issue-#209 Compiler trap in Real64 op ADR(x)

PostPosted: Fri Nov 13, 2020 11:42 am
by Robert
Sorry - I have not been following the details here.

Is the topic ready for voting, or are there still problems to be resolved?