Internal error 2014011604

[af0815]

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.

[Ñuño_Martínez]

I don't know what's wrong, but that line will result always in assigning 0 (zero) to the left layout, won't it?

[engkin]

Internal errors are always bugs that need to be reported.

[Thaddy]

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.

[af0815]

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. 

[asdf121]

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]

With the actual fixes_3_2 41756 it is gone.

THX

[Thaddy]

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.