floating invalid error

[Cilke__Jim]

In my large Fortran application, I sometimes get a "forrtl: error (65): floating invalid" error message.  And I am at a loss as to why.  Below is a sample program which generates the error.  I create a table, within a large array.  I initialize all values in the array to zero.  For each row, i want to divide the value in column 2 by value in column 1 and put the result in column 2.  I only do this calculation if column 2 is positive.  In my example, in the first row, column  2 is zero.  When I run, i get the floating invalid error message.  Interestingly, before i do the divide, i write out to the log file the values for columns 1 and 2, then my program runs to completion.  In my example I have commented out the write statement.  Also, this exact code runs without incident in Debug Mode.

      program test

      parameter nra=3,nca=3,nta=100000, xa_size=nra*nca*nta
      double precision xa(nra,nca,nta)
      data xa /xa_size*0./

      xa(1,01,1) = 0.
      xa(1,02,1) = 0.
      xa(2,01,1) = 40000000.
      xa(2,02,1) = 100.
      xa(3,01,1) = 10000000.
      xa(3,02,1) = 5.

      do 800 i=1,3

!      write(6,50) i, xa(i,01,1), xa(i,02,1)
! 50   format(1x,'check here',i4,2f10.0)
 
        if (xa(i,02,1) > .01) xa(i,03,1) = xa(i,01,1) / xa(i,02,1)
 800  continue
       
      do 810 i=1,3
        write(6,100) i, xa(i,01,1), xa(i,02,1), xa(i,03,1)
 100    format(1x,'results',i4,3f10.0)
 810  continue
   
      end 

-------------------------------------------------------------------------------------------------------------------------------------------

The following is the critical line in my code which builds the executable.

ifort /nologo /I%MPI_include% /real_size:64 /libs:static /threads /list /debug:none /check:format /check:nopower /check:uninit /Qinit:snan,arrays /traceback /c test.f90

What am I doing wrong.  I hope there is an easy fix.

Thank-you in advance.

Jim

[Cilke__Jim]

sorry for the typo.  I put the result in column 3.

[mecej4]

To see the errors, add IMPLICIT NONE after the first line and attempt to compile. It may also be helpful to use relevant compiler options to check for the code's adherence to the Fortran standard.

(SPOILER: what is the type of xa_size?)

[TimP]

It looks like an error which ifort should flag and refuse to compile even without IMPLICIT NONE, but it's possible the compiler isn't fully tested without that.

[jimdempseyatthecove]

Experiment:

Configure to produce error (comment out the write in do 800).
Verify error
Then initialize x1(1,02,1) = 0.000001

IOW something less than your threshold.

If this corrects the error, then my guess is the compiler had vectorized the 800 loop and use a conditional move to not move the excluded case.

Then, if the above corrects the case, restore the initialization to 0, but then insert

!DIR$ NOVECTOR

in front of the do 800 statement.

Jim Dempsey

[Steve_Lionel]

I don't see that the failure to declare xa_size has any relevance here, and there is no error for the compiler to detect. The form of the PARAMETER statement here is nonstandard and xa_size takes on the type of the value, which is integer, but otherwise it is fine, syntax-wise.

I have not done any further analysis.

[gib]

With my old (version 11.075) compiler, building with

ifort err.f90

or

ifort /real_size:64 err.f90

gives an executable that runs OK, giving

 results   1        0.        0.        0.
 results   2 40000000.      100.   400000.
 results   3 10000000.        5.  2000000.

If I try

ifort /real_size:64 /libs:static err.f90

I get this link error:

LINK : fatal error LNK1104: cannot open file 'LIBC.lib'

[Steve_Lionel]

You must also have a newer Visual Studio installed that doesn't supply libc.lib.

[Steve_Lionel]

When I build and run this, with the options shown, under 18.0.3, it runs successfully.

[gib]

"You must also have a newer Visual Studio installed that doesn't supply libc.lib."

Yes, IVF is integrated with VS2005, but I also have VS2010 installed.  Is this a path issue?

[Steve_Lionel]

I think it was VS2005 that dropped libc.lib. Are you rebuilding the entire application or are there some objects or libraries left over from an earlier build? I would expect the compiler driver to not use libc.lib as a dependency.

Try adding libc.lib to the "Ignore libraries" list in the Linker property pages, and add libcmt.lib as an additional dependency. I am not entirely sure this will work. Or use /libs:dll instead of /libs:static.

[gib]

Steve, I have no problems with VS2005 for my own purposes, I was just trying to be helpful by testing the OP's code, and just mentioned the libc.lib issue as an interesting discovery.  In my own work I always build using the IDE, and everything has been working fine for years.

[Cilke__Jim]

First, thank-you all for taking the time to look at my problem.

Through some trial and error, I believe I have found the "smoking gun", or at least something that is contributing to the "floating invalid" error message I am getting.  In my simple example (see my original post), if I remove the compile option "/qinit:snan,arrays", my simple program runs fine.  Or if I remove the "snan" such that the option is "/qinit:arrays", my simple program runs fine.

Steve: with this fix, "/libs:dll" and "/libs:static"  appear to work equally well)

But my use of "/qinit:snan" raises the question of whether I need (or should use) this compiler option in my much larger application.  (I can't recall why I added the option in the first place.  But I must have had a reason.)  Let add one more observation (which I perhaps should have included in my original post).  The size of the array matters.  I do not get the "floating invalid" message when the size of the xa array is small. (e.g., when nta=1).  I'm not sure why the size of the array matters; but it does.

So, thoughts experts?  Why is this compiler option causing problems?  Is removing this compiler option something I should be worried about? My next step is to test my large application without this compiler option.

Thanks in advance.

Jim

[gib]

/qinit:snan is an unknown option with my compiler version.

[Lorri_M_Intel]

On Windows, it's spelled /Qinit:snan   (note that the Q is uppercased)

Some of the command line options are case-insensitive, but the vast majority are case-sensitive  (especially ones that begin with Q)

               --Lorri

[gib]

'/Qinit:snan' is also unknown to IVF 11.075.

[Cilke__Jim]

Quite right Lorri.  I should have been more exact in my post and used /Qinit instead of /qinit.

And gib, the compile option /Qinit:snan appears to be known in IVF 15.0.7, as I do not get an "unrecognized keyword" error message.  And, based on the documentation for /Qinit:snan, it seems like it would be useful compiler option to invoke. 

Jim