# Issues with nvfortran REAL() function **URL:** \ **Category:** Uncategorized\ **Created:** [November 23, 2020, 1:04am UTC](https://fortran-lang.discourse.group/t/issues-with-nvfortran-real-function/440 "2020-11-23T01:04:22Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [November 23, 2020, 1:04am UTC](https://fortran-lang.discourse.group/t/issues-with-nvfortran-real-function/440/1 "2020-11-23T01:04:22Z")
To make a long story short that dealt with complex variables and segfaults and allocatable arrays being defined as size zero that could not be, I think all the problems have a root cause having to do with REAL() in nvfortran(1). anyone see any reason ‘A’ and ‘B’ should not be returning [1,3,5] and [2,4,6] ? ```auto program testit use, intrinsic :: iso_fortran_env, only : stdout=>OUTPUT_UNIT character(len=*),parameter :: gen='(*(g0,1x))' integer,allocatable :: arr(:) arr=[1,2,3,4,5,6] write(stdout,gen)'A',real(arr(1::2)) write(stdout,gen)'B',real(arr(2::2)) write(stdout,gen)'C',real(arr(1:)) write(stdout,gen)'D',real(arr) write(stdout,gen)'E',arr(1::2) write(stdout,gen)'F',arr(2::2) write(stdout,gen)'a',size(real(arr(1::2))) write(stdout,gen)'b',size(real(arr(2::2))) write(stdout,gen)'c',size(real(arr(1:))) write(stdout,gen)'d',size(real(arr)) write(stdout,gen)'e',size(arr(1::2)) write(stdout,gen)'f',size(arr(2::2)) end program testit ``` ```nohighlight nvfortran 20.7-0 LLVM 64-bit target on x86-64 Linux -tp nehalem NVIDIA Compilers and Tools Copyright (c) 2020, NVIDIA CORPORATION. All rights reserved. ``` ```nohighlight A 1.000000 3.000000 5.000000 0. 0. 16017.00 B 2.000000 4.000000 6.000000 0. 0. C 1.000000 2.000000 3.000000 4.000000 5.000000 6.000000 D 1.000000 2.000000 3.000000 4.000000 5.000000 6.000000 E 1 3 5 F 2 4 6 a 6 b 5 c 6 d 6 e 3 f 3 ``` ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [November 23, 2020, 3:01am UTC](https://fortran-lang.discourse.group/t/issues-with-nvfortran-real-function/440/2 "2020-11-23T03:01:55Z")
> [@urbanjost](#): > > anyone see any reason ‘A’ and ‘B’ should not be returning > [1,3,5] and [2,4,6] ? No, why would anyone see any reason for it? REAL(A [, KIND]) intrinsic procedure in the Fortran standard is an ELEMENTAL function after all. ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [November 23, 2020, 3:18am UTC](https://fortran-lang.discourse.group/t/issues-with-nvfortran-real-function/440/3 "2020-11-23T03:18:57Z")
Another thing you can try is take the following code which I contend conforms to Fortran 90 standard published nearly 30 years ago and for which there were quite a few robust conforming compilers. How does NVFORTRAN 20.7-0 perform with this code? ```Fortran integer, allocatable :: arr( : ) allocate( arr(6) ) arr = (/ 1,2,3,4,5,6 /) write( unit=6, fmt="(6(f5.1,1x))") real(arr(1::2)) write( unit=6, fmt="(6(f5.1,1x))") real(arr(2::2)) deallocate( arr ) end ``` Compaq Visual Fortran from way back in year 2003 (or more like DEC Fortran, the predecessor to current Intel Fortran compiler), a processor that attempted to conform to Fortran 95, compiles to yield the following output: > C:\Temp\>type p.f90 > integer, allocatable :: arr( : ) > allocate( arr(6) ) > arr = (/ 1,2,3,4,5,6 /) > write( unit=6, fmt=“(6(f5.1,1x))”) real(arr(1::2)) > write( unit=6, fmt=“(6(f5.1,1x))”) real(arr(2::2)) > deallocate( arr ) > end > > C:\Temp\>f90 p.f90 > Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update C) > Copyright 2003 Compaq Computer Corp. All rights reserved. > > p.f90 > Microsoft (R) Incremental Linker Version 6.00.8447 > Copyright (C) Microsoft Corp 1992-1998. All rights reserved. > > /subsystem:console > /entry:mainCRTStartup > /debugtype:cv > /pdb:none > dfor.lib > libc.lib > dfconsol.lib > dfport.lib > kernel32.lib > /out:p.exe > > C:\Temp\>p.exe > 1.0 3.0 5.0 > 2.0 4.0 6.0 > > C:\Temp\> ---
**Author:** ![billlong](https://avatars.discourse-cdn.com/v4/letter/b/71e660/32.png) [@billlong](https://fortran-lang.discourse.group/u/billlong)\ **Post date:** [November 23, 2020, 12:30pm UTC](https://fortran-lang.discourse.group/t/issues-with-nvfortran-real-function/440/4 "2020-11-23T12:30:14Z")
Interesting. With a different compiler I see > ./a.out > A 1.000000 3.000000 5.000000 > B 2.000000 4.000000 6.000000 > C 1.000000 2.000000 3.000000 4.000000 5.000000 6.000000 > D 1.000000 2.000000 3.000000 4.000000 5.000000 6.000000 > E 1 3 5 > F 2 4 6 > a 3 > b 3 > c 6 > d 6 > e 3 > f 3 I suspect a bug in the original compiler. Note that REAL() is usually implemented as in-line code, so it’s probably the compiler and not the intrinsics library. ---
**Author:** ![awvwgk](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/awvwgk/32/154_2.png) [@awvwgk](https://fortran-lang.discourse.group/u/awvwgk)\ **Post date:** [November 23, 2020, 6:09pm UTC](https://fortran-lang.discourse.group/t/issues-with-nvfortran-real-function/440/5 "2020-11-23T18:09:19Z")
Might be worth reporting this issue at the NVIDIA developer forum: > **[nvc, nvc++ and nvfortran](https://forums.developer.nvidia.com/c/accelerated-computing/hpc-compilers/nvc-nvc-and-nvfortran/313)** > > Greetings and welcome to the NVIDIA HPC Compilers forum. Post your questions and comments here pertaining to the NVIDIA C, C++ and Fortran HPC compilers, and to their interoperation with NVCC and other HPC SDK components. ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [November 23, 2020, 11:55pm UTC](https://fortran-lang.discourse.group/t/issues-with-nvfortran-real-function/440/6 "2020-11-23T23:55:23Z")
reported to NVIDIA as an issue