[Support]

Hello!

Max value of SourceBPS is 8 there, min value is 0

I have checked the code in x32 and x64, all results were equal and there was not overflow or range errors.

Do you have problems with this code? Maybe you can give me the Png-file which can't be processed? I will test why it happens.

[HeDiBo]

'Support' wrote:

Hello!

Max value of SourceBPS is 8 there, min value is 0

I have checked the code in x32 and x64, all results were equal and there was not overflow or range errors.

Do you have problems with this code? Maybe you can give me the Png-file which can't be processed? I will test why it happens.

I didn't say there was an overflow or range error. In my 64 bit delphi (Delphi XE4) the code generated is simply wrong.

This is the stack trace:

acPNG.MulDiv16(0,0,0)

acPNG.TColorManager.RowConvertIndexed8((…),$5710618,40,128)

acPNG.TColorManager.ConvertRow((…),$5710618,40,128)

acPNG.TPNGGraphic.LoadIDAT((no value))

acPNG.TPNGGraphic.LoadFromStream($82D5BD0)

sGraphUtils.LoadBmpFromPngStream($53C8E40,$82D5BD0)

acAlphaImageList.TsAlphaImageList.GenerateStdList

acAlphaImageList.TsAlphaImageList.Loaded

System.Classes.NotifyGlobalLoading

System.Classes.InitInheritedComponent($531DEB0,TClass($6F1738))

Vcl.Forms.TCustomForm.Create($53B74E0)

Vcl.Forms.TApplication.CreateForm(TComponentClass($927278),(no value))

ac64BitBug.ac64BitBug

:00007FFCDD051FE4 ; C:WINDOWSSystem32KERNEL32.DLL

:00007FFCDD35EFC1 ;

This is a sample project, As soon as image 1 is loaded, the DIvision by Zero exception occurs.

[attachment=8702:ac64BitBug.zip]

[Support]

Thank you for the demo.

Really, I see that old x64 compilers has this bug.

I will search a better solution.

This solution is the best, I think (2 shl (n-1)-1), but I will check it: https://stackoverflo…on-in-delphi-xe

[HeDiBo]

'Support' wrote:

Thank you for the demo.

Really, I see that old x64 compilers has this bug.

I will search a better solution.

This solution is the best, I think (2 shl (n-1)-1), but I will check it: https://stackoverflo…on-in-delphi-xe

Thanks!

Will you report here when you think you programmed around this Delphi bug? I'll try it again then.

[HeDiBo]

In AC 13.04 the 64 bit code changed to:

Code:

acPNG.pas.2891: MaxInSample := byte(integer(1 shl SourceBPS) – 1);
000000000084CEC9 C7C001000000 mov eax,$00000001
000000000084CECF 480FB64D27 movzx rcx,byte ptr [rbp+$27]
000000000084CED4 80E11F and cl,$1f
000000000084CED7 D3E0 shl eax,cl
000000000084CED9 80E801 sub al,$01
000000000084CEDC 884529 mov [rbp+$29],al

And that seems to work

PS. Is there anyway you can eliminate the generated tabs in the code text? They're always wrong 😰

[Support]

This is how it looks in the my editor.

[attachment=8714:Code.png]

Please, show how it looks on your side.

[HeDiBo]

'Support' wrote:

This is how it looks in the my editor.

[attachment=8714:Code.png]

Please, show how it looks on your side.

Sorry, I didn't mean in the Delphi editor, but in the [code}..[/code] part on this website.

[Support]

Hello!

I understand now, but can't change it in the form engine, unfortunately.

[HeDiBo]

'Support' wrote:

Thank you for the demo.

Really, I see that old x64 compilers has this bug.

I will search a better solution.

This solution is the best, I think (2 shl (n-1)-1), but I will check it: https://stackoverflo…on-in-delphi-xe

The problem is solved. But the change in the source code is not marked with a comment, explaining the need for the used construct. That's important to prevent forgetting where it's for or for a third person maintaining the code in the future.

[Author]

Posts