Strange Floating Point XMM Errors on WIN64
lazarus / 64-FPC development

----------------------------------------------------------------------
schuler · 2017-10-13 07:07

Hello Pascal Lovers 

I'm not sure if I'm typing here with the goal to save time to others
in the case that they get the same error as I got or if I want to know
if I found a bug. Anyway, here we go.

I have 3 functions: A, B and C. Function A calls B. B calls C. C
contains both pascal and asm code.

Function A shows strange floating point errors including division by
zero error.

This is a portion of function C:

Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i   asm  ... 
vmovups ymm6, [rax+64]  ...    end  [    'RAX',    'XMM6',    'ymm6' 
]; 
After 4 or 5 hours debugging, I found that a floating point value
stored on XMM6 on function A was being lost. Then, I found this link:

http://wiki.lazarus.freepascal.org/Win64/AMD64_API

From above link, I can read:
Quoteother nonvolatile registers, if used, should be pushed on stack.
These registers are R12 through R15, RDI, RSI, RBX, XMM6 through XMM15

I though that signaling usage of either XMM6 or YMM6 would solve the
problem:
https://www.freepascal.org/docs-html/prog/progse12.html#x149-1500003.4

But I think that this is not the case. Not sure if this is a bug or
not. If I were coding the compiler, I would not to be sure although
I'm tempted to look at how the signaling was implemented.

HOW TO SOLVE
This is how I solved in my case:

Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i var  mxmm6:
array[0..3] of Single;begin  ...  asm  movups mxmm6, xmm6  // saves
xmm6  ...  movups xmm6, mxmm6 // restores xmm6 - YAY!!!  end ['RAX']; 
So far, this problem shows up on Windows 64 only. Linux 64 with same
code works well so far.

Please feel free to comment.

 wish everyone happy coding

----------------------------------------------------------------------
marcov · 2017-10-13 08:01

Some tips:

Please try to make a small demo that demonstrates the problem, that we
can compile with -a on various branches. Fragments can be useful if sb
directly sees the problem, but this probably requires further
investigation

ABI only knows and saves XMM registers, the upper part of YMM is
always considered lost.

If you use YMM you are supposed to run a vzeroupper afterwards, though
afaik that is only a performance optimization.

----------------------------------------------------------------------
schuler · 2017-10-15 06:06

Hello Marcov,
I'll try to create a small demo and post here.

Thank you for your help.

----------------------------------------------------------------------
schuler · 2017-10-25 00:07

MARCOV!!!

Just been able to reproduce with:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i procedure
TestC(); inline;begin  asm    vxorps xmm6, xmm6, xmm6  end
['XMM6','YMM6'];end; procedure TestA();var  S1: Single;begin  S1 :=
1;   TestC();   WriteLn(S1:4:2);end; 
If you call TestA above, you'll see that 1 is loaded into xmm6. Then,
xmm6 is zeroed by TestC.

Should I log a bug report?

  Wish everyone happy coding

----------------------------------------------------------------------
marcov · 2017-11-05 03:41

I can't quickly reproduce since my local build seems corrupt (keeps
saying can't find identifier XMM6).

I think having both xmm6 and ymm6 in the save register list is wrong
(should be only ymm6), and probably never inlinable.

But yes, file a bug even if only for better errrorgeneration

----------------------------------------------------------------------
schuler · 2019-06-21 12:42

Hi ,
Almost 2 years later, came across to the same problem. Today, it
happened to me on WIN64 with release settings (no debug info).

I'm wondering: can anyone try to reproduce this problem please?

----------------------------------------------------------------------
julkas · 2019-06-21 13:29

Quote from: schuler on June 21, 2019, 02:42:11 pmI'm wondering: can
anyone try to reproduce this problem please?
Running your code example in DEBUG mode, result - 1.00. RELEASE - 0.00

----------------------------------------------------------------------
marcov · 2019-06-21 14:29

I compiled it with trunk and yes. xmm6 is callee saved, as per ABI.
That is what putting the register name it in end[] does.

If you don't put it there, it is fine, but since xmm6 is chosen by the
compiler as location for "s1", this is extremely dodgy code.

----------------------------------------------------------------------
schuler · 2019-06-21 15:11

@julkas and marcov,
Thank you for your super quick replies!

From what you've both replied, I can conclude that we do have a
problem on FPC 3.0.4 that has already been fixed on trunk. This is
good news.

 Wish everyone happy pascal coding