Ich habe noch ein wenig mehr in system.math gestöbert und dabei folgendes entdeckt (ich habe schon eine Frage auf https://stackoverflow.com/questions/...umbers-to-zero gestellt, weil es wieder etwas esoterisch ist).

Wenn jemand hier das bestätigen kann, und es nicht as-specified ist, würde ich noch einen QC-Issuereport schreiben.

Diese Beobachtung hätte mehr Auswirkungen als der AES-NI-Bug, da die gesamte Arithmetik betroffen wäre, denn denormale Fließkommazahlen sind ein wichtiger kleiner Baustein für genaue Arithmetik.

Das kann gar nicht as designed sein, da das Verhalten bei 32 und 64 Bit unterschiedlich ist.

Zitat von Uwe Raabe:

Das kann gar nicht as designed sein, da das Verhalten bei 32 und 64 Bit unterschiedlich ist.

Na ja, es gibt ja wesentliche Unterschiede bei der Fließkommaarithmetik von 32- und 64-Bit: 64-Bit arbeitet mit SSE und hat keine native 10-Byte-Extended.

Außerdem scheint bei CPUARM irgendeine Besonderheit vorzuliegen und man wollte es einheitlich machen. Das glaube ich zwar nicht, habe aber keine Stelle im Sourcecode gefunden, wo explizit ein Flush-to-Zero eingebaut ist.

Zitat von gammatester:

Das glaube ich zwar nicht, habe aber keine Stelle im Sourcecode gefunden, wo explizit ein Flush-to-Zero eingebaut ist.

Das wird auch nicht explizit gemacht, sondern entsteht durch die Multiplikation zweier sehr kleiner Zahlen. Man kann das im Debugger nachvollziehen.

[QUOTE=Uwe Raabe;1408125]

Zitat von gammatester:

Das wird auch nicht explizit gemacht, sondern entsteht durch die Multiplikation zweier sehr kleiner Zahlen. Man kann das im Debugger nachvollziehen.

Ich würde hier dem Debugger nicht unbedingt trauen, was wird denn für x nach x := PDouble(@twopm1030)^ angezeigt?

Interessanterweise gibt es bei FPC-64 noch eine zusätzliche Variante: x*x wird richtig berechnet, aber x := ldexp(1,-1030) crasht mit EOverflow: Floating point overflow

Edit: Da scheint noch mehr faul zu sein. Und vermutlich liegt das Problem in ldexp. Ich habe jetzt den Debugger angeworfen und x ist korrekt angezeigt nach der Konstantenzuweisung. Allerdings hat er mit auch x:=ldexp(1,-510) als 0 angezeigt und das wird durch writeln bestätigt.

Die 32-Bit-Version zeigt richtig an 9.32292591400026E-0156.

Wie scho im letzten Beitrag gesagt, ist ldexp das Problem: Es wird die Overload-Version für Single aufgerufen. Das wirkt sich nur für 64-Bit aus, weil die 32-Bit-Overloads praktisch identisch sind.

Wie kann man eigenlich in die Debg-DCUs rein-steppen?
Ich habe Linking with Debug und Debug-Configuration eingestellt, aber der Debugger verweigert die Sourcecode-Anzeige. Ich bin mir aber sicher, daß die Singleversion genommen wird, weil ich im CPU-Fenster sehe

markieren

Delphi-Quellcode:

call TSingleHelper.SpecialType
...
call TSingleHelper.BuildUp

Werde dann mal einen weiteren Issue-Report schreiben, letztlich geht es also 'nur' um eine Inkonstistenz zwischen 32- und 64-Bit.

Zitat von gammatester:

Wie kann man eigenlich in die Debg-DCUs rein-steppen?

Projektoptionen -> Delphi-Compiler -> Compilieren -> Mit Debug-DCUs

Zitat von Uwe Raabe:

Zitat von gammatester:

Wie kann man eigenlich in die Debg-DCUs rein-steppen?

Projektoptionen -> Delphi-Compiler -> Compilieren -> Mit Debug-DCUs

Danke, hat auf Anhieb funktioniert!

Auch bei Fehlermeldungen bitte ich den Themen-Titel präziser zu wählen. Danke.

Zitat von Daniel:

Auch bei Fehlermeldungen bitte ich den Themen-Titel präziser zu wählen. Danke.

Zu Befehl, passt es so?

Edit: Der QC-Eintrag ist https://quality.embarcadero.com/browse/RSP-20925