Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Bug(s) in 2020 (Update 1)

Greynolds__Alan
Beginner
1,907 Views

Unzip files

ifort -c designer.f90 to reproduce first bug

To get around it change

  logical j2,air; air(k)=abs(GlassIndex(k))==ONE

To

  logical j2,air(100) !; air(k)=abs(GlassIndex(k))==ONE

recompile to get second bug.

Al

 

0 Kudos
1 Solution
Ron_Green
Moderator
1,911 Views

Here's a distilled reproducer.  I'll open a bug report

subroutine LensGraphics()

  round(x)=sign(smal*(aint(abs(x)/smal)+1),x)

  return

contains

  subroutine splots()
  real,parameter :: ONE=1

  integer :: iCLR(2)
  real :: GlassIndex(10)
  logical air; air(k)=abs(GlassIndex(k))==ONE

    if (i==0) then
      ip=iCLR(2)
    endif
  end subroutine
 
End

 

View solution in original post

0 Kudos
10 Replies
FortranFan
Honored Contributor III
1,911 Views

I presume you're following up as per this thread at comp.lang.fortran: https://groups.google.com/d/msg/comp.lang.fortran/ZsPiXq5X39E/KKNnaODrAAAJ

I suggest you share here the actual Fortran source files for the MODULE (mod) files in ABERRAT, CONSOLE, and OPTIONS and also any source files for the modules these may USE.

At first glance, there appears to be some error in your code starting with how the same letter may get mapped in an IMPLICIT type statement multiple times given how you've inserted the INCLUDE files and things may be percolating from there.  Other compilers may have been more lenient previously.  One would need to see the whole code to disentangle the issues.  That would also help create bug reproducers for Intel Fortran team for any bugs that get identified in the process with their latest compiler. 

0 Kudos
Greynolds__Alan
Beginner
1,911 Views

Here's an updated bug.zip file with all necessary source.  To compile

ifort -c modules.f90 designer.f90

 

0 Kudos
Greynolds__Alan
Beginner
1,911 Views

I reviewed the code after your comments and agree there's a case of overkill with respect to multiple IMPLICITs so I commented out a seemingly unnecessary include

:

  subroutine splots(x,y,i)
!  include 'default.fh'
  intent(in) x,y,i

::

However, this has no effect on the resulting inexplicable errors reported by the compiler.

 

 

0 Kudos
Ron_Green
Moderator
1,912 Views

Here's a distilled reproducer.  I'll open a bug report

subroutine LensGraphics()

  round(x)=sign(smal*(aint(abs(x)/smal)+1),x)

  return

contains

  subroutine splots()
  real,parameter :: ONE=1

  integer :: iCLR(2)
  real :: GlassIndex(10)
  logical air; air(k)=abs(GlassIndex(k))==ONE

    if (i==0) then
      ip=iCLR(2)
    endif
  end subroutine
 
End

 

0 Kudos
mecej4
Honored Contributor III
1,911 Views

Great condensation work by Ron Green! Here is an even shorter reproducer. The bug is present in 18.x and 19.x, but not in 16.0.8.

subroutine LG()
  round(x)=real(nint(x))                        ! unused StmtFunc
  return
contains
  subroutine splots(i,ip,iclr)                  ! unused subroutine
    ir(k)=iclr - 1                              ! unused StmtFunc
    if (i==0) then
      ip=iclr + 2
    endif
  end subroutine
End

 

0 Kudos
FortranFan
Honored Contributor III
1,911 Views

@Greynolds, Alan:

I'm personally very glad to read the progress here once you shared your code with the 2 Intel Blackbelts being able to take that and put together nice, small reproducers.

Hopefully the bug can be fixed soon enough.

In the meantime, would you consider refactoring your code to move away from statement functions which are marked obsolescent in the standard?  You're already using "internal" (aka contained) procedures.  So with a bit of added verbosity but with greater clarity and flexibility, you can replace the statement functions.  The compiler can then do its optimization, as appropriate with inlining, etc. and give you performance too.

 

0 Kudos
Greynolds__Alan
Beginner
1,911 Views

How about this for a deal? I'll stop using statement functions if Intel provides a free "community" version of its Fortran compiler (even if it's just for command-line).

0 Kudos
FortranFan
Honored Contributor III
1,911 Views

Greynolds, Alan wrote:

How about this for a deal? I'll stop using statement functions if Intel provides a free "community" version of its Fortran compiler (even if it's just for command-line).

Intel is already offering you a deal: see this

https://software.intel.com/en-us/articles/qualify-for-free-software

https://software.intel.com/en-us/articles/open-source-contributor-faq

If you're a student, educator, or a significant open-source contributor - or you can become one, you can get your "free" edition.

If you can "open source" your "lens graphics" code or any other code you may have developed over the years and/or start contributing toward other open source projects such as the initiative for a Fortran "standard" library (https://github.com/fortran-lang/stdlib), that all *might* help you as well as the Fortran community.

0 Kudos
Greynolds__Alan
Beginner
1,911 Views

I obviously wouldn't have brought it up if I fit (or could fit) into any of those "pigeon holes". I'm a retired independent researcher that still publishes papers every year based on my optical engineering code (partly owned but no longer used by my former employer).  For more info see:

https://www.spie.org/profile/Alan.Greynolds-6273

Also I still think a separate streamlined command-line only install is a good idea. Intel seems to by moving in that direction on the Mac as they are dropping Xcode support. 

0 Kudos
Ron_Green
Moderator
1,880 Views

THis bug was fixed in our PSXE 2020 Update 2 available now. I will close this issue, thank you for sending this in for us to fix.


0 Kudos
Reply