Intel® Fortran Compiler

PSXE 2017 Update 2 - Internal Compiler Error(s) involving PARAMETER constants and /debug-parameters /debug options

PSXE 2017 Update 2 - Internal Compiler Error(s) involving PARAMETER constants and /debug-parameters /debug options

A defect (regression) has been found in the Intel® Parallel Studio XE 2017 Update 2 (17.0 compiler) release involving the use of PARAMETER constants along with the /debug-parameter and /debug options. The combined use can led to multiple internal compiler errors.

The following example (complements of andrew_4619) demonstrates usage that will trigger the internal error:

rc.exe not found

I have a piece of code that runs on another computer that I'm trying to compile and run on my computer but whenever I try to build the solution I get an error rc.exe not found. I've done some research and believe that the issue is related to having the wrong combination of Visual Studio and Intel Fortran installed together. I've tried uninstalling and reinstalling several different version of both VS and Parallel Studio, ranging from 2013 - 2017 but I have not had much luck.

Оптимизировали, оптимизировали, да не выоптимизировали!

Оптимизация? Конечно, каждый сталкивался с данной задачей при разработке своих, сколь-нибудь значительных, требующих определённых вычислений, приложений. При этом способов оптимизировать код существует огромное множество, и, как следствие, различных путей сделать это в автоматическом режиме с помощью опций компилятора. Вот здесь и возникает проблема – как выбрать то, что нужно нам и не запутаться?

DisableProcessWindowsGhosting function

Is there a problem with this prototype in user32.f90?  The MS documentation indicate that the function name includes an s after the word part "window", but this prototype does not.  I'm getting a link error.

subroutine DisableProcessWindowGhosting () bind(C,name="DisableProcessWindowGhosting")
    !DEC$ ATTRIBUTES STDCALL :: DisableProcessWindowGhosting
end subroutine DisableProcessWindowGhosting

Doctor Fortran in "It Takes All KINDs"

Recently there was an extended thread in the comp.lang.fortran newsgroup about Fortran KIND values, started by someone learning Fortran who had a basic misunderstanding of how they worked. Most of the advice in the thread was good, but there were some folk who, while very knowledgeable and whose expertise I admire, offered a suggestion I thought flat-out wrong. Thus begat this post.
Subscribe to Intel® Fortran Compiler