# Question about double precision on ARM processors

**URL:** <https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763>\
**Category:** Uncategorized\
**Created:** [November 10, 2023, 8:05pm UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763 "2023-11-10T20:05:37Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![IanMartinAjzenszmidt](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ianmartinajzenszmidt/32/1992_2.png) [@IanMartinAjzenszmidt](https://fortran-lang.discourse.group/u/IanMartinAjzenszmidt)\
**Post date:** [November 10, 2023, 8:05pm UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/1 "2023-11-10T20:05:37Z")

</div>

Double precision variables in Fortran are said to be run as single precision real variables when run on ARM hardware . Fortran can currently be run offline on ubuntu and debian linux on the userland app on android 12 or 13.  
Ian Martin Ajzenszmidt

---

<div class="post-metadata">

**Author:** ![IanMartinAjzenszmidt](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ianmartinajzenszmidt/32/1992_2.png) [@IanMartinAjzenszmidt](https://fortran-lang.discourse.group/u/IanMartinAjzenszmidt)\
**Post date:** [November 10, 2023, 8:13pm UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/2 "2023-11-10T20:13:03Z")

</div>

**Floating Point Operations**

ARM processors support both single precision and double precision floating point operations. However, the performance of double precision floating point operations can vary depending on the specific processor model.

Some ARM processors have dedicated hardware for double precision floating point operations, while others use software emulation. Processors with dedicated hardware for double precision floating point operations will generally have better performance.

It is important to check the documentation for your specific processor to see what level of support it provides for double precision floating point operations.

---

<div class="post-metadata">

**Author:** ![IanMartinAjzenszmidt](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ianmartinajzenszmidt/32/1992_2.png) [@IanMartinAjzenszmidt](https://fortran-lang.discourse.group/u/IanMartinAjzenszmidt)\
**Post date:** [November 10, 2023, 9:47pm UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/3 "2023-11-10T21:47:11Z")

</div>

userland@localhost:~ gfortran testarmdp.f userland@localhost:~ ./a.out  
7.1100000494631581E+024  
0.711000025  
userland@localhost:~$ cat testarmdp.f  
double precision dp /.711E25/

```
          real sp /.711/
          print *,dp
           print *,sp
           end program

```

userland@localhost:~ userland@localhost:~ lscpu  
Architecture: aarch64  
CPU op-mode(s): 32-bit, 64-bit  
Byte Order: Little Endian  
CPU(s): 4  
On-line CPU(s) list: 0-3  
Vendor ID: ARM  
Model name: Cortex-A53  
Model: 4  
Thread(s) per core: 1  
Core(s) per cluster: 4  
Socket(s): -  
Cluster(s): 1  
Stepping: r0p4  
CPU max MHz: 2001.0000  
CPU min MHz: 850.0000  
BogoMIPS: 26.00  
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid  
Vulnerabilities:  
Itlb multihit: Not affected  
L1tf: Not affected  
Mds: Not affected  
Meltdown: Not affected  
Spec store bypass: Not affected  
Spectre v1: Mitigation; \_\_user pointer sanitization  
Spectre v2: Not affected  
Srbds: Not affected  
Tsx async abort: Not affected  
userland@localhost:~$

---

<div class="post-metadata">

**Author:** ![JohnCampbell](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@JohnCampbell](https://fortran-lang.discourse.group/u/JohnCampbell)\
**Post date:** [November 10, 2023, 11:57pm UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/4 "2023-11-10T23:57:01Z")

</div>

These claims regarding double precision should be verified, else removed.

The example of “7.1100000494631581E+024” above suggests that variable dp is real(8), but is initialised with real(4) constant. If this is the basis of the claims, they appear to be wrong.  
try “double precision dp /.711D25/”

It would be unfortunate if these wrong claims persisted.

---

<div class="post-metadata">

**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\
**Post date:** [November 11, 2023, 12:06am UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/5 "2023-11-11T00:06:11Z")

</div>

@IanMartinAjzenszmidt I merged all your threads into this one. When commenting here, just start a thread and then add comments to it, don’t start a new thread for every comment.

As pointed out by @JohnCampbell your example is using single precision constant. If you use the following code:

```fortran
double precision :: dp = 0.711D25
real :: sp = 0.711
print *,dp
print *,sp
end program

```

Then it works correctly with both GFortran and LFortran on Apple M1 (ARM):

```console
$ gfortran a.f90 && ./a.out 
   7.1099999999999997E+024
  0.711000025    
$ lfortran a.f90 
7.10999999999999974e+24
7.11000025e-01

```

---

<div class="post-metadata">

**Author:** ![IanMartinAjzenszmidt](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ianmartinajzenszmidt/32/1992_2.png) [@IanMartinAjzenszmidt](https://fortran-lang.discourse.group/u/IanMartinAjzenszmidt)\
**Post date:** [November 11, 2023, 2:39am UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/6 "2023-11-11T02:39:59Z")

</div>

I have run the same code on a Latitude E7440 as well. Here is the run.

```auto
(base) ian@ian-Latitude-E7440:~/Downloads$ nano gfortranx86dp.f
(base) ian@ian-Latitude-E7440:~/Downloads$ gfortran gfortranx86dp.f
(base) ian@ian-Latitude-E7440:~/Downloads$ ./a.out
   7.1100000494631581E+024
  0.711000025    
(base) ian@ian-Latitude-E7440:~/Downloads$ cat gfortranx86dp.f
          double precision dp /.711E25/
          real sp /.711/
          print *,dp
           print *,sp
           end program
   
(base) ian@ian-Latitude-E7440:~/Downloads$ lscpu
Architecture: x86_64
  CPU op-mode(s): 32-bit, 64-bit
  Address sizes: 39 bits physical, 48 bits virtual
  Byte Order: Little Endian
CPU(s): 4
  On-line CPU(s) list: 0-3
Vendor ID: GenuineIntel
  Model name: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
    CPU family: 6
    Model: 69
    Thread(s) per core: 2
    Core(s) per socket: 2
    Socket(s): 1
    Stepping: 1
    CPU max MHz: 2900.0000
    CPU min MHz: 800.0000
    BogoMIPS: 4988.33
    Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mc
                         a cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss 
                         ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arc
                         h_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
                         cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vm
                         x smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1
                          sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsav
                         e avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_s
                         ingle pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexprio
                         rity ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep
                          bmi2 erms invpcid xsaveopt dtherm ida arat pln pts md_
                         clear flush_l1d
Virtualization features: 
  Virtualisation: VT-x
Caches (sum of all):     
  L1d: 64 KiB (2 instances)
  L1i: 64 KiB (2 instances)
  L2: 512 KiB (2 instances)
  L3: 3 MiB (1 instance)
NUMA:                    
  NUMA node(s): 1
  NUMA node0 CPU(s): 0-3
Vulnerabilities:         
  Gather data sampling: Not affected
  Itlb multihit: KVM: Mitigation: VMX disabled
  L1tf: Mitigation; PTE Inversion; VMX conditional cache flushe
                         s, SMT vulnerable
  Mds: Mitigation; Clear CPU buffers; SMT vulnerable
  Meltdown: Mitigation; PTI
  Mmio stale data: Unknown: No mitigations
  Retbleed: Not affected
  Spec rstack overflow: Not affected
  Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer
                          sanitization
  Spectre v2: Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIB
                         P conditional, RSB filling, PBRSB-eIBRS Not affected
  Srbds: Mitigation; Microcode
  Tsx async abort: Not affected
(base) ian@ian-Latitude-E7440:~/Downloads$ 

```

---

<div class="post-metadata">

**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\
**Post date:** [November 11, 2023, 3:05am UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/7 "2023-11-11T03:05:46Z")

</div>

Can you do:

```console
cat gfortranx86dp.f

```

The `dp` number must be equal to `0.711D25`, not `0.711E25`.

---

<div class="post-metadata">

**Author:** ![JohnCampbell](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@JohnCampbell](https://fortran-lang.discourse.group/u/JohnCampbell)\
**Post date:** [November 11, 2023, 3:16am UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/8 "2023-11-11T03:16:55Z")

</div>

This thread only highlights the pedantic rules in the Fortran Standard regarding data constants, which are just not in the interest of minimising coding bugs for Fortran users.  
If you read the same constant from a data file, you get the required result.

This delight was introduced in F90, when so many other positive improvements were made.  
There are clearly Fortran users that struggle to understand this approach.

Why can’t a modern fortran optimising compiler accept the following line of code !  
integer\*8 :: i8 = 29000000000

---

<div class="post-metadata">

**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\
**Post date:** [November 11, 2023, 3:23am UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/9 "2023-11-11T03:23:57Z")

</div>

> [@JohnCampbell](#):
>
> This delight was introduced in F90, […]

It was also the case in most f77 and earlier compilers. The behavior was only specified clearly in f90, before that it was ambiguous. If you wanted consistent behavior prior to f90, you would also have specified the double precision constant in the source code.

In modern code, I think it is probably best to avoid DOUBLE PRECISION and D exponents entirely. They are still supported, for backwards compatiblity reasons, but modern code should be using the fortran KIND convention for both declarations and for literal constants.

---

<div class="post-metadata">

**Author:** ![JohnCampbell](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@JohnCampbell](https://fortran-lang.discourse.group/u/JohnCampbell)\
**Post date:** [November 11, 2023, 4:12am UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/10 "2023-11-11T04:12:29Z")

</div>

Please Ron,

What was the intent of the following statements ?

double precision dp /.711E25/  
integer\*8 :: i8 = 29000000000

Why should we have a standard that clearly ignores this intent ?

I would actually like to have the following statement recognised:  
integer\*8 :: i8 = 2^32

---

<div class="post-metadata">

**Author:** ![IanMartinAjzenszmidt](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ianmartinajzenszmidt/32/1992_2.png) [@IanMartinAjzenszmidt](https://fortran-lang.discourse.group/u/IanMartinAjzenszmidt)\
**Post date:** [November 11, 2023, 4:39am UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/11 "2023-11-11T04:39:02Z")

</div>

(base) ian@ian-Latitude-E7440:~/Downloads$ ls \*.f  
dprecdemo.f gfortranx86dp.f q2.f secret\_message.f testx86.f  
(base) ian@ian-Latitude-E7440:~/Downloads$ gfortran dprecdemo.f  
(base) ian@ian-Latitude-E7440:~/Downloads$ ./a.out  
Double Precision Result: 1111111128.0000000  
Real Result: 1.11111117E+09  
(base) ian@ian-Latitude-E7440:~/Downloads$ cat dprecdemo.f  
PROGRAM DoublePrecisionDemo

- This program demonstrates the use of Double Precision and Real variables.

- Initialize the variables  
dVar1 = 123456789.123456789  
dVar2 = 987654321.987654321

- Perform arithmetic operations  
dResult = dVar1 + dVar2  
rResult = rVar1 + rVar2

- Display the results  
PRINT \*, 'Double Precision Result: ', dResult  
PRINT \*, 'Real Result: ', rResult

(base) ian@ian-Latitude-E7440:~/Downloads$ lscpu  
Architecture: x86\_64  
CPU op-mode(s): 32-bit, 64-bit  
Address sizes: 39 bits physical, 48 bits virtual  
Byte Order: Little Endian  
CPU(s): 4  
On-line CPU(s) list: 0-3  
Vendor ID: GenuineIntel  
Model name: Intel(R) Core™ i5-4300U CPU @ 1.90GHz  
CPU family: 6  
Model: 69  
Thread(s) per core: 2  
Core(s) per socket: 2  
Socket(s): 1  
Stepping: 1  
CPU max MHz: 2900.0000  
CPU min MHz: 800.0000  
BogoMIPS: 4988.33  
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant\_tsc arch\_perfmon pebs  
bts rep\_good nopl xtopology nonstop\_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds\_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4\_1 sse4\_2 x2apic movbe popcnt  
tsc\_deadline\_timer aes xsave avx f16c rdrand lahf\_lm abm cpuid\_fault epb invpcid\_single pti ssbd ibrs ibpb stibp tpr\_shadow vnmi flexpriority ept vpid ept\_ad fsgsbase tsc\_adjust b  
mi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts md\_clear flush\_l1d  
Virtualization features:  
Virtualisation: VT-x  
Caches (sum of all):  
L1d: 64 KiB (2 instances)  
L1i: 64 KiB (2 instances)  
L2: 512 KiB (2 instances)  
L3: 3 MiB (1 instance)  
NUMA:  
NUMA node(s): 1  
NUMA node0 CPU(s): 0-3  
Vulnerabilities:  
Gather data sampling: Not affected  
Itlb multihit: KVM: Mitigation: VMX disabled  
L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable  
Mds: Mitigation; Clear CPU buffers; SMT vulnerable  
Meltdown: Mitigation; PTI  
Mmio stale data: Unknown: No mitigations  
Retbleed: Not affected  
Spec rstack overflow: Not affected  
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl  
Spectre v1: Mitigation; usercopy/swapgs barriers and \_\_user pointer sanitization  
Spectre v2: Mitigation; Retpolines, IBPB conditional, IBRS\_FW, STIBP conditional, RSB filling, PBRSB-eIBRS Not affected  
Srbds: Mitigation; Microcode  
Tsx async abort: Not affected  
(base) ian@ian-Latitude-E7440:~/Downloads$

---

<div class="post-metadata">

**Author:** ![IanMartinAjzenszmidt](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ianmartinajzenszmidt/32/1992_2.png) [@IanMartinAjzenszmidt](https://fortran-lang.discourse.group/u/IanMartinAjzenszmidt)\
**Post date:** [November 11, 2023, 5:10am UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/12 "2023-11-11T05:10:05Z")

</div>

The same second code run on an ARM Cortex -M53 instead of genuine intel. userland@localhost:~ nano testarm.f userland@localhost:~ gfortran testarm.f -ffree-form  
userland@localhost:~ ./a.out Double Precision Result: 2.5042347108182738E-312 Real Result: 1.11111117E+09 userland@localhost:~ cat testarm.f  
DOUBLE PRECISION dVar1, dVar2, dResult  
REAL rVar1, rVar2, rResult

!Initialize the variables  
dVar1 = 123456789.123456789  
dVar2 = 987654321.987654321

rVar1 = 123456789.123456789  
rVar2 = 987654321.987654321

!Perform arithmetic operations  
Result = dVar1 + dVar2  
rResult = rVar1 + rVar2

!Display the results  
PRINT \*, 'Double Precision Result: ', dResult  
PRINT \*, 'Real Result: ', rResult

END PROGRAM

userland@localhost:~ lscpu Architecture: aarch64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Vendor ID: ARM Model name: Cortex-A53 Model: 4 Thread(s) per core: 1 Core(s) per cluster: 4 Socket(s): - Cluster(s): 1 Stepping: r0p4 CPU max MHz: 2001.0000 CPU min MHz: 850.0000 BogoMIPS: 26.00 Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid Vulnerabilities: Itlb multihit: Not affected L1tf: Not affected Mds: Not affected Meltdown: Not affected Spec store bypass: Not affected Spectre v1: Mitigation; \_\_user pointer sanitization Spectre v2: Not affected Srbds: Not affected Tsx async abort: Not affected userland@localhost:~

---

<div class="post-metadata">

**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\
**Post date:** [November 11, 2023, 6:26am UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/13 "2023-11-11T06:26:54Z")

</div>

> [@JohnCampbell](#):
>
> What was the intent of the following statements ?

That is exactly the problem. Without looking at how these values are used, the intent is unclear, both to a human looking at the code and also for a compiler looking at the code. Maybe the programmer intended to have 64-bit accuracy, maybe he intended to have 32-bit accuracy. But one thing is almost certain about this situation, the programmer does not want different behavior on different processors. The programmer almost certainly wants the code to do the same thing on different compilers, or on the same compiler on different days, or with new and old versions of a compiler, or on different hardware that supports the same floating point formats.

If I ask you what is the intent of the following code:

```auto
use, intrinsic:: iso_fortran_env, only: sp=>real32, dp=>real64
real(sp) :: s = 0.1234_sp
real(dp) :: ds = 0.1234_sp, dd = 0.1234_dp

```

then I’m pretty sure we will both agree. And when a compiler looks at that code, it will agree with us. My point is that with the fortran KIND system, introduced in f90, this is now a solved problem, the code can be clearly written in an almost self-documenting way. There is no longer any need to argue about what is or isn’t intended by some ambiguous declarations or assignments.

---

<div class="post-metadata">

**Author:** ![IanMartinAjzenszmidt](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ianmartinajzenszmidt/32/1992_2.png) [@IanMartinAjzenszmidt](https://fortran-lang.discourse.group/u/IanMartinAjzenszmidt)\
**Post date:** [November 11, 2023, 10:43am UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/14 "2023-11-11T10:43:42Z")

</div>

Following is a run listing including suggested edits:  
(base) ian@ian-Latitude-E7440:~/Downloads$ cat testx86.f  
use, intrinsic:: iso\_fortran\_env, only: sp=\>real32, dp=\>real64  
real(sp) :: s = 0.1234\_sp  
real(dp) :: ds = 0.1234\_sp, dd = 0.1234\_dp  
!double precision :: dp = 0.711D25  
!real :: sp = 0.711  
print \*,dp  
print \*,sp  
print \*,s  
print \*,ds  
print \*,dd  
end program  
(base) ian@ian-Latitude-E7440:~/Downloads$ gfortran testx86.f -o testx86  
(base) ian@ian-Latitude-E7440:~/Downloads$ ./testx86  
8  
4  
0.123400003  
0.12340000271797180  
0.12340000000000000  
(base) ian@ian-Latitude-E7440:~/Downloads$ ^C  
(base) ian@ian-Latitude-E7440:~/Downloads$ lscpu  
Architecture: x86\_64  
CPU op-mode(s): 32-bit, 64-bit  
Address sizes: 39 bits physical, 48 bits virtual  
Byte Order: Little Endian  
CPU(s): 4  
On-line CPU(s) list: 0-3  
Vendor ID: GenuineIntel  
Model name: Intel(R) Core™ i5-4300U CPU @ 1.90GHz  
CPU family: 6  
Model: 69  
Thread(s) per core: 2  
Core(s) per socket: 2  
Socket(s): 1  
Stepping: 1  
CPU max MHz: 2900.0000  
CPU min MHz: 800.0000  
BogoMIPS: 4988.39  
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca c  
mov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm  
pbe syscall nx pdpe1gb rdtscp lm constant\_tsc arch\_perfmon  
pebs bts rep\_good nopl xtopology nonstop\_tsc cpuid aperfm  
perf pni pclmulqdq dtes64 monitor ds\_cpl vmx smx est tm2 s  
sse3 sdbg fma cx16 xtpr pdcm pcid sse4\_1 sse4\_2 x2apic mov  
be popcnt tsc\_deadline\_timer aes xsave avx f16c rdrand lah  
f\_lm abm cpuid\_fault epb invpcid\_single pti ssbd ibrs ibpb  
stibp tpr\_shadow vnmi flexpriority ept vpid ept\_ad fsgsba  
se tsc\_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dt  
herm ida arat pln pts md\_clear flush\_l1d  
Virtualization features:  
Virtualisation: VT-x  
Caches (sum of all):  
L1d: 64 KiB (2 instances)  
L1i: 64 KiB (2 instances)  
L2: 512 KiB (2 instances)  
L3: 3 MiB (1 instance)  
NUMA:  
NUMA node(s): 1  
NUMA node0 CPU(s): 0-3  
Vulnerabilities:  
Gather data sampling: Not affected  
Itlb multihit: KVM: Mitigation: VMX disabled  
L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes,  
SMT vulnerable  
Mds: Mitigation; Clear CPU buffers; SMT vulnerable  
Meltdown: Mitigation; PTI  
Mmio stale data: Unknown: No mitigations  
Retbleed: Not affected  
Spec rstack overflow: Not affected  
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl  
Spectre v1: Mitigation; usercopy/swapgs barriers and \_\_user pointer sa  
nitization  
Spectre v2: Mitigation; Retpolines, IBPB conditional, IBRS\_FW, STIBP c  
onditional, RSB filling, PBRSB-eIBRS Not affected  
Srbds: Mitigation; Microcode  
Tsx async abort: Not affected  
(base) ian@ian-Latitude-E7440:~/Downloads$

---

<div class="post-metadata">

**Author:** ![mecej4](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/mecej4/32/855_2.png) [@mecej4](https://fortran-lang.discourse.group/u/mecej4)\
**Post date:** [November 11, 2023, 1:00pm UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/15 "2023-11-11T13:00:35Z")

</div>

> [@IanMartinAjzenszmidt](#):
>
> !Perform arithmetic operations  
> Result = dVar1 + dVar2

The last line should have been  
`dResult = dVar1 + dVar2`  
As it is, your program prints out dResult without assigning the variable a value.

Because of this error, apparent misunderstandings on your part of the consequences of assigning an expression of type REAL to a variable of type DOUBLE PRECISION, and undue haste in drawing conclusions, this thread is rather misleading and pointless.

---

<div class="post-metadata">

**Author:** ![jacobwilliams](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jacobwilliams/32/10_2.png) [@jacobwilliams](https://fortran-lang.discourse.group/u/jacobwilliams)\
**Post date:** [November 11, 2023, 3:09pm UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/16 "2023-11-11T15:09:44Z")

</div>

![double-precision.002](https://global.discourse-cdn.com/free1/uploads/fortran_lang/original/2X/9/91cbda7198d94997c5a5bc6a2472d7db25eb7e83.png)

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [November 11, 2023, 3:25pm UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/17 "2023-11-11T15:25:43Z")

</div>

Only that `real64` doesn’t guarantee double precision accuracy, but only an exact storage size…

 ![Screenshot_20231111-162259](https://global.discourse-cdn.com/free1/uploads/fortran_lang/original/2X/7/7578953cc7e845835b19b27749c1947eeb5f5fbc.png)

---

<div class="post-metadata">

**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\
**Post date:** [November 11, 2023, 5:04pm UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/19 "2023-11-11T17:04:05Z")

</div>

> [@IanMartinAjzenszmidt](#):
>
> 8  
> 4  
> 0.123400003  
> 0.12340000000000000  
> 0.12340000271797180

The first and last floating point values are **exactly** the same internally. This is because every floating point real can be represented exactly as a double precision. One could see this by printing the variables with a Z or B format. The difference you see here is an artifact of the list-directed i/o conventions. Namely, the real value is printed with fewer digits, so it is displayed as the rounded version of the last value. If instead of list-directed formatting you use a specific format for both variables, say something like f20.17, then you should see the same digits printed for the first and last values.

So in addition to the difference in the output due to the different precisions of the constants, there is also this quirk related to list-directed i/o.

> [@ivanpribec](#):
>
> Only that `real64` doesn’t guarantee double precision accuracy, […]

This is correct. In practice, you usually get a little **more** than twice the precision. For example, 24-bits for real and 53-bits for double precision (counting the hidden bits).

---

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [November 11, 2023, 5:14pm UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/20 "2023-11-11T17:14:35Z")

</div>

> [@JohnCampbell](#):
>
> What was the intent of the following statements ?
> 
> double precision dp /.711E25/  
> integer\*8 :: i8 = 29000000000
> 
> Why should we have a standard that clearly ignores this intent ?

We have had this discussion before, and the answers to these questions have been giiven.

---

<div class="post-metadata">

**Author:** ![jacobwilliams](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jacobwilliams/32/10_2.png) [@jacobwilliams](https://fortran-lang.discourse.group/u/jacobwilliams)\
**Post date:** [November 11, 2023, 5:20pm UTC](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763/21 "2023-11-11T17:20:56Z")

</div>

But is there any compiler where real64 /= double precision?

Beginners are confused by selected\_real\_kind, and all these subtle details about how to use real numbers in Fortran. It’s just way too complicated. People come from other languages where there is only one kind of floating point number (or where double is the default) and make these errors every time.

[Next page](https://fortran-lang.discourse.group/t/question-about-double-precision-on-arm-processors/6763.md?page=2)