The following code with a BLOCK construct (Fortran 2008) within an ASSOCIATE construct fails to compile when the associate-name is used inside the block. Is this only to be expected per the standard? I couldn't find anything in the standard that says this is not allowed.
As can be seen in the attached program, when I am trying to open, read and write data into an array, I am getting an error which says as follows:
"forrtl: severe (59): list-directed I/O syntax error".
Any suggestions or insight into this would be greatly helpful.
here's another bug report about the Coarray implementation of the Intel Compiler (version 15.0.2). The following code fails with a segfault:
Sometimes it is useful, or even necessary(?), to type in compile flags manually in the property field Configuration Properties->Command Line->Additional Options. However, "Additional Options" behave somewhat inconsistently.
Although Visual Studio and other applications appeared to remain in working order after the (very time consuming) Windows Update installation of windows10 tech preview, none of my Intel software tools except Impi came up by themselves. The culprit appeared to be multiple visible versions even though the latest had been installed with the choice to replace the previous. Impi also had 2 visible versions, but that didn't stop it from coming up. Un-installing everything possible and re-installing seemed to recover, but then I had to find a working ifort.cfg elsewhere.
My code currently targets a baseline architecture of SSE2 (/arch:SSE2) and an additional code path (/QaxAVX).
I want users of the Haswell (AVX2) to benefit without making the code fall back to SSE2 when AVX is available. Does that make sense?
The help for /Qax says it adds multiple code paths without specifying how many paths that could be so I thought if I add /QaxCORE-AVX2 as well as /QaxAVX I would get 3 code paths in total but the compiler says /QaxCORE-AVX2 overrides /QaxAVX. What should I do?
I just downloaded and installed the latest update(w_fcompxe_2015.2.179) and am now getting an error that I did not get when using the version from October of 2012(w_fcompxe_novsshell_2013.1.119).
I uninstalled the latest and went back to October 2012 version and do not get the error.
Then installed the latest and get the error again. It appears that something has changed. Do I need to declare the pass by value differently now?
Below is the error I get with the latest version of the Intel Fortran compiler:
I am working as a software developer in a company with a code based on FORTRAN 90. Recently we have found that code was failing with lack of enough memory at some stage of the run. Tests have shown that using the "Deallocate" makes the pointers used "unassociated", but for some pointers the memory is not released. This could be a large amount causing the code to crash eventually. The situation becomes worse as we are allocating and deallocating the same pointers several times during the runtime.
Those of you who follow my @DoctorFortran Twitter feed have seen this already, but for the rest of you... I have acquired five MinnowboardMAXes - small single-board computers with dual-core Atom processors and 2GB of RAM. My primary goal for these is to form a Linux cluster and demonstrate coarrays on them, but I took one of them and loaded Windows 10 and Visual Fortran on it. Works fine, if not the speediest thing in the world.
I have a .rc resource file in a Fortran DLL project where I set information like the version number. Is there a way to automatically increment part of the file version number with each build? I currently manually edit the file version number, which is not onerous, but automation would be welcome. It looks like the .rc file is a text file that could perhaps be modified by a script, unless that would corrupt it. Thanks for any advice.