Recent

Author Topic: Internal error 2014011604  (Read 1074 times)

af0815

  • Sr. Member
  • ****
  • Posts: 436
Internal error 2014011604
« on: March 21, 2019, 09:34:17 am »
i have the following line
Code: Pascal  [Select]
  1.   Memo := TFPReportMemo.Create(DataBand);
  2.   Memo.Layout.Left := (trunc(DataBand.Layout.Width) div 3) * 0; // < =================
  3.   Memo.Layout.Top := 0;
  4.   Memo.Layout.Width := trunc(DataBand.Layout.Width) div 3;
  5.  
and the marked line rises the internal error 2014011604, if i remove the '* 0' it compiles

Lazarus 2.0.1 r60486 FPC 3.2.0 i386-win32-win32/win64 (= Laz fixes20 and fpc fixes32)

?! it a bug or a feature or i miss something ?

BTW in the Forumsearch i found no thread about it.
regards
Andreas

Ñuño_Martínez

  • Hero Member
  • *****
  • Posts: 935
    • Burdjia
Re: Internal error 2014011604
« Reply #1 on: March 21, 2019, 10:35:02 am »
I don't know what's wrong, but that line will result always in assigning 0 (zero) to the left layout, won't it?
Are you interested in game programming? Join the Pascal Game Development community!
Also visit the Game Development Portal

engkin

  • Hero Member
  • *****
  • Posts: 2513
Re: Internal error 2014011604
« Reply #2 on: March 21, 2019, 10:38:18 am »
Internal errors are always bugs that need to be reported.

Thaddy

  • Hero Member
  • *****
  • Posts: 9403
Re: Internal error 2014011604
« Reply #3 on: March 21, 2019, 11:12:41 am »
Internal errors are always bugs that need to be reported.
Indeed. It is maybe even allowed to shout a little:
Internal errors are always bugs that need to be reported.

Explanation:
Internal errors are errors in a code path that the compiler developers did not expect.
They are there to identify a code path by the compiler that should theoretically not be possible.
So if you encounter them, they should always be reported because they are compiler bugs and not end-user bugs.
They are considered much more serious than other bugs for that reason and will get immediate attention from the compiler dev team.
That doesn't mean that they are immediately resolved: extreme border cases that do not warrant immediate resolve or deep architectural problems.

And this is of course such a border case:
Code: Pascal  [Select]
  1.   Memo.Layout.Left := (trunc(DataBand.Layout.Width) div 3) * 0; // < =================
It is a bug by itself. But the compiler should not throw an internal error for every stupid programming mistake.
- The result is always zero
- The compiler is allowed to optimize divisions to multiplications by reciprocal

The first is a programming mistake, the second is probably the cause of the internal error because of the first, a division by zero that should not be possible.
« Last Edit: March 21, 2019, 11:41:14 am by Thaddy »
also related to equus asinus.

af0815

  • Sr. Member
  • ****
  • Posts: 436
Re: Internal error 2014011604
« Reply #4 on: March 21, 2019, 01:31:58 pm »
The first is a programming mistake, the second is probably the cause of the internal error because of the first, a division by zero that should not be possible.
This was not a programming mistake, because the >0< was only a placeholder for later design-emprovements. Yes i know that the value is 0 - excactly 0.0. And with 0.0 it works. 
regards
Andreas

asdf121

  • New Member
  • *
  • Posts: 35
Re: Internal error 2014011604
« Reply #5 on: March 21, 2019, 01:59:43 pm »
Code: Pascal  [Select]
  1.   Memo.Layout.Left := (trunc(DataBand.Layout.Width) div 3) * 0; // < =================
It is a bug by itself. But the compiler should not throw an internal error for every stupid programming mistake.
- The result is always zero
- The compiler is allowed to optimize divisions to multiplications by reciprocal

The first is a programming mistake, the second is probably the cause of the internal error because of the first, a division by zero that should not be possible.

It's not a programming mistake, it's a compiler mistake!
Code: Pascal  [Select]
  1. (trunc(DataBand.Layout.Width) div 3)
can be changed to a multiplication as you said (so I guess it'll look like the following)
Code: Pascal  [Select]
  1. (trunc(DataBand.Layout.Width) * 1/3)
but then there is just the
Code: Pascal  [Select]
  1. * 0
which is an absolute valid mathematical operation!

The compiler should be able to optimize the expression to 0 while compiling as the previous argument (completely expressed in brackets) is multiplied by 0.

af0815

  • Sr. Member
  • ****
  • Posts: 436
Re: Internal error 2014011604
« Reply #6 on: March 21, 2019, 02:47:17 pm »
With the actual fixes_3_2 41756 it is gone.

THX
regards
Andreas

Thaddy

  • Hero Member
  • *****
  • Posts: 9403
Re: Internal error 2014011604
« Reply #7 on: March 21, 2019, 03:00:40 pm »
The first is a programming mistake, the second is probably the cause of the internal error because of the first, a division by zero that should not be possible.
This was not a programming mistake, because the >0< was only a placeholder for later design-emprovements. Yes i know that the value is 0 - excactly 0.0. And with 0.0 it works.
No: 0 is interpreted as an integer literal and 0.0 is interpreted as a single. That's the difference. The compiler generates different code for the different types.
An integer literal is more likely to cause a division by zero, whereas a single real type is more likely to cause things like infinity or NaN etc.
Your bug is that you did not realize you chose a bad placeholder, which was also ambivalent, which makes it a border case.

But the internal error is always a bug.

So plz report the bug. And note that 0.0 works but 0 not! That is because of the above.
« Last Edit: March 21, 2019, 08:08:29 pm by Thaddy »
also related to equus asinus.