Some interesting feature of the Intel Fortran.

[hiroshi-murakami]

I feel fun. that Intel fortran can use ++ or -- in the expression, which GNU fortran make the syntax errors.

It might be useful, however, this makes typing mistakes to pass OK.

print*, 2.0

print*,-2.0

print*, --2.0  !  number 2 with two minus signs is the number 2 back.

print*,---2.0 ! number 2 with three minus signs is the minus 2.

print*,+3.0

print*,++3.0 ! number 3 with two plus sign is the number 3.

print*, +++3.0

print*, -4.0  ! gives -4.0 as usual.

print*,+-4.0 ! gives -4.0

print*,-+-4.0 ! gives 4.0

print*, 1.0--2.0  !gives 3.0

print*, 1.0---3.0 ! gives -2.0.

print*, x--y, x++y, x+-y, x-+y, x---y, x--+y !  etc.

Hiroshi Murakami

[TimP]

If you set -stand, I suppose ifort should report error.

[Anonymous66]

The Fortran standard does not explicitly disallow or allow stacking unary operators. We chose to allow it.

Annalee

[hiroshi-murakami]

1E--3, 1E++5

In the program are syntax errors.

When a data is read, --3.0 or ++3.0 causes errors since these are just signs and are not operators.

And another interesting  thing is, IEEE 754 floating point number system has signs for zeros, the positive zero and negative zero.

write(*,'(Z,3X,Z)') +0.0,-0.0

will reveal different binary representations are used for 0.0 and -0.0.

And, 1.0/(+0.0),1.0/(-0.0) gives Infinity and -Infinity correctly.

But,  (0.0)==(-0.0) gives  True!

Thus we need not write  abs(x)==0.0 to test if x is zero (positive zero or negative zero)

but write just x==0.0

[Anonymous66]

negative 0 is an interesting beast 

[TimP]

Annalee (Intel) wrote:

The Fortran standard does not explicitly disallow or allow stacking unary operators. We chose to allow it.

Annalee

There are some situations where naked unary operators show up in applications where it's not permitted by standard and is not always reasonably interpreted by compilers which accept it e.g. A ** - B

Metcalf, Reid, Cohen have some discussion about this but don't appear to have a firm conclusion on the point Annalee just made.

[hiroshi-murakami]

read(*,*)x     ! this is very standard.

write(*,*)x    ! this is very standard.

read(*,*),x    ! ifort accepts this.

write(*,*),x   ! ifort accepts this.

read(*,*),   ! ifort accepts this also.

write(*,*),   ! ifort accepts this also.

read*,,x     ! ifort does not accept this.

print*,,x    ! ifort does not accept this.

[Harald]

hiroshi-murakami wrote:

And another interesting  thing is, IEEE 754 floating point number system has signs for zeros, the positive zero and negative zero.

write(*,'(Z,3X,Z)') +0.0,-0.0

will reveal different binary representations are used for 0.0 and -0.0.

And, 1.0/(+0.0),1.0/(-0.0) gives Infinity and -Infinity correctly.

But,  (0.0)==(-0.0) gives  True!

Thus we need not write  abs(x)==0.0 to test if x is zero (positive zero or negative zero)

but write just x==0.0

That's actually what the Fortran standard requires.

4.4.2.3 Real type

[...]

The real type includes a zero value. Processors that distinguish between positive and negative zeros shall treat
them as mathematically equivalent
   • in all intrinsic relational operations,

See also Note 4.8 in that section of the standard.

[Lorri_M_Intel]

hiroshi-murakami wrote:

read(*,*)x     ! this is very standard.

write(*,*)x    ! this is very standard.

read(*,*),x    ! ifort accepts this.

write(*,*),x   ! ifort accepts this.

read(*,*),   ! ifort accepts this also.

write(*,*),   ! ifort accepts this also.

read*,,x     ! ifort does not accept this.

print*,,x    ! ifort does not accept this.

If you compile your program with standards checking enabled, you will get a message that your program is not standards-conforming.
Yes, Intel Fortran accepts the comma between the I/O specification and the I/O list as an extension. 

[Steven_L_Intel1]

Consecutive operators, such as ++ or -- are explicitly disallowed in the standard, though it can be exasperating trying to figure that out from the syntax rules. As said., we allow them as extensions. In fact, Intel Fortran, with its roots back to the 1970s DEC FORTRAN-IV-PLUS, allows a LOT of non-standard syntax by default. As required by the standard, we provide a "means of detection" of such non-standard syntax, but you have to ask for it.

One aspect of this that confuses many is that an entity such as -3 is actually two syntax tokens - the minus unary operator applied to the integer literal 3.

[hiroshi-murakami]

It would be preferable that the compiler detects every non-standard feature
used in the source code by default to promote the standard or the provider
is trying to lock users and codes.
It would be better for the historical features or the experimental ones,
they are enabled only by setting the corresponding compiler options
somthing such as "--intel".

[Steven_L_Intel1]

Our experience has been that the majority of customers prefer the compiler to be more relaxed by default, and we get many complaints when we tighten error checking. You can always make -stand be the default by adding it to an ifort.cfg file.  See the documentation for information on how to use configuration files.

[hiroshi-murakami]

The intel Fortran compiler supports IEEE's quadruple precision floating point numbers.

I would like to know if the rounding mode of the arithmetics  for the quadruple precision numbers

can be controlled by the  mode flag for FPU and SSE unit as the usual hardware implemented

single or double precision numbers.

Does  the software implementation of quadruple precision arithmetics used by the intel compiler reflects

the rounding mode control flags (round-up, round-down, round-nearest, round-to-zero) as if the Q-precision

is implemented by the hardware instructions.

The mode flag can be changed by the user by calling C with assembler routines.

If the rounding mode can be used to controll the Q-precision or Q and other precision arithmetics,

we can elegantly write code that enable interval arithmetics in Q-precision.

[TimP]

If IEEE_set_rounding_mode et al. aren't working for you, why don't you file a reproducer?

Yes, for compilers such as gfortran which don't support IEEE_arithmetic, several of these functions can be written to support native floating point by iso_c_binding calls to e.g.

int ieee_set_rounding_mode(unsigned int rounding_mode) {
#ifdef HAVE_FENV
    fesetround(rounding_mode);
#else   // xmmintrin
    _MM_SET_ROUNDING_MODE (rounding_mode);
#endif
}

but why would you bypass documented features of ifort in favor of hypothetical undocumented ones?

Even for gfortran libquadmath you would probably want to study the docoumentation and source code before launching off in such diirections.

[Steven_L_Intel1]

I'm not completely sure that the IEEE_ARITHMETIC routines affect quadruple precision - they may, but I have a vague memory that says they don't. If not, then they would use the default mode which is "Round to nearest".