- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page