I'm having some trouble getting my 64-bit Fortran compiler to work.  I've installed the Microsoft Visual Studio 8 Professional software on my computer, then I installed the Intel Visual Fortran Composer XE 2011 (the only one I can find available from the Intel site).  

When I run mex -setup it doesn't find the compiler because it's looking in a different location.  I give it the location of the ifort.exe file instead ( C:\Program Files (x86)\Intel\ComposerXE-2011\bin\intel64) and the setup routine seems to be happy.  But when I try to compile a file with 'mex -v yprimef.F' it throws an error:

 Error: Could not find the compiler "ifort" on the DOS path. 
         Use mex -setup to configure your environment properly.

Am I doing something wrong?  I've checked my DOS path and the path I entered above during setup is present (although I had to tweak it to make it present).  Any ideas on what's going on?

Thanks,
D

Intel Visual Fortran Composer XE 2011 is version 12.0.

At this point it is not supported for use with MATLAB:
http://www.mathworks.com/support/compilers/R2010b/index.html

Gadi

The Composer version seems to be the only compiler available from Intel right now.  Do you happen to know of a link to download the 11.1 compiler?  If Intel no longer offers the older versions of Fortran, would it be fair to say that Matlab does not currently support fortran mex in 64-bit systems?

In any case, the version problem doesn't seem to address the error that I'm receiving, namely that it can't find "ifort" on the DOS path when it is very clearly there.  If the compiler version was the problem I'd expect a compiler version error, not an error saying it cannot find a file that exists on my computer.  It it possible for Matlab to use a compiler that is not formally supported by Mathworks?  Like the newest Intel above or the gcc compilers?

Thanks,
Doug

Gadi Reinhorn <greinhorn@mathworks.com> wrote in message <ieqjkc$8q7$2@fred.mathworks.com>...
> Intel Visual Fortran Composer XE 2011 is version 12.0.
> 
> At this point it is not supported for use with MATLAB:
> http://www.mathworks.com/support/compilers/R2010b/index.html
> 
> Gadi

Gadi Reinhorn <greinhorn@mathworks.com> wrote in message <ieqjkc$8q7$2@fred.mathworks.com>...
> Intel Visual Fortran Composer XE 2011 is version 12.0.
> 
> At this point it is not supported for use with MATLAB:
> http://www.mathworks.com/support/compilers/R2010b/index.html
> 
> Gadi

And as far as I can know, if you are licensed to use Fortran Composer XE 2011 you are also licensed for previous versions such as 11.1.070. Different versions can be installed in parallel.

"Doug" wrote in message <ieqocj$39m$1@fred.mathworks.com>...
> The Composer version seems to be the only compiler available from Intel right now.  Do you happen to know of a link to download the 11.1 compiler?

If you have a supported license, after logging in to the support and download page you can select different versions for download. In my case, as far back as 8.0 update 035.

For 30-day evaluation versions it looks like only the 2011 version is available.

"Mark Shore" wrote in message <ieqprf$649$1@fred.mathworks.com>...
> "Doug" wrote in message <ieqocj$39m$1@fred.mathworks.com>...
> > The Composer version seems to be the only compiler available from Intel right now.  Do you happen to know of a link to download the 11.1 compiler?
> 
> If you have a supported license, after logging in to the support and download page you can select different versions for download. In my case, as far back as 8.0 update 035.
> 
> For 30-day evaluation versions it looks like only the 2011 version is available.

Yeah, unfortunately, budgets being what they are these days, I'd like to try it before I buy it...

Doug,

As Mark said, if you have a license for Composer 2011, then you can get 
version 11.1.  Since Intel does still offer that Fortran compiler for 
64-bit, we do consider MATLAB supporting Fortran MEX on 64-bit systems.

I'm sorry that the evaluation level of support is not working for you. 
That is unfortunate, you should contact Intel to see if they will offer 
you a trail of version 11.1.

We do understand your concern regarding the frequency with which Intel 
releases new versions of its compiler.  We are aware of the issue and do 
our best to stay as current as possible with Intel.

Regarding the ifort error you are seeing. When you ran mex -setup, you 
were not given an option for version 12.  When you tried to set the 
install directory of version 11.1 to your 12.0 location, the software 
was use incorrectly.  At the point where you did that, we no longer do 
version qualification.  We assume you read the direction in setup that 
refer to a specific version and we assume you know that you are 
overriding regular behavior.

If you want to work with an unsupported compiler my guess is that you 
would have to change a bunch of little things in the options files. 
None of that is supported of course.

I'm sorry I can't give you better news.

Gadi

Gadi Reinhorn wrote:
....

> If you want to work with an unsupported compiler my guess is that you 
> would have to change a bunch of little things in the options files. None 
> of that is supported of course.
....

Indeed... :(

TMW is awfully coy and convoluted in the implementation of the batch 
files that are supplied for mex.

I've an older release of ML and can attest that it takes a significant 
amount of time to delve through the scripts to figure out the specifics 
of which files have to be where and for which environment variables to 
be what values, etc., etc., for the mex -setup script to function for a 
newer release of a given compiler.  I would, however, say in all 
likelihood it is possible given sufficient perseverance on the end 
user's part.

It would be, imo, _a_good_thing_ for TMW to document the mex -setup 
process more thoroughly -- it would undoubtedly pay dividends to them by 
fewer support issues as well as being a service to the user community.

There's no reason why a user of a given compiler should lose the 
facility to keep up w/ version upgrades simply because TMW is so 
dogmatic about hiding the keys to the kingdom.

--

DP,

As one of the people responsible for compiler support updates, I wish it 
was that simple.

We have no interest in hiding the way we support compilers.  We would 
love to have a clean interface that was designed to be extensible.  The 
existing options file/ STP-file interface is NOT.  It is complicated and 
fragile.  Because it was not designed to be extensible, it would not 
help very much to document how to update it.  The directions would be 
too confusing AND get out of date too quickly.  From our experience THAT 
would lead to even MORE support issues.

Furthermore, we take testing and quality very seriously here.  We have 
extensive test suites that we use to qualify the correctness of the 
results of all the compilers we support.

We are concerned about this issue and hope to address it at some point 
in the future.

Thanks for your input.

Gadi



On 12/22/2010 10:23 AM, dpb wrote:
> Gadi Reinhorn wrote:
> ...
>
>> If you want to work with an unsupported compiler my guess is that you
>> would have to change a bunch of little things in the options files.
>> None of that is supported of course.
> ...
>
> Indeed... :(
>
> TMW is awfully coy and convoluted in the implementation of the batch
> files that are supplied for mex.
>
> I've an older release of ML and can attest that it takes a significant
> amount of time to delve through the scripts to figure out the specifics
> of which files have to be where and for which environment variables to
> be what values, etc., etc., for the mex -setup script to function for a
> newer release of a given compiler. I would, however, say in all
> likelihood it is possible given sufficient perseverance on the end
> user's part.
>
> It would be, imo, _a_good_thing_ for TMW to document the mex -setup
> process more thoroughly -- it would undoubtedly pay dividends to them by
> fewer support issues as well as being a service to the user community.
>
> There's no reason why a user of a given compiler should lose the
> facility to keep up w/ version upgrades simply because TMW is so
> dogmatic about hiding the keys to the kingdom.
>
> --

Gadi Reinhorn wrote:
> DP,
> 
> As one of the people responsible for compiler support updates, I wish it 
> was that simple.
> 
> We have no interest in hiding the way we support compilers.  We would 
> love to have a clean interface that was designed to be extensible.  The 
> existing options file/ STP-file interface is NOT.  It is complicated and 
> fragile.  Because it was not designed to be extensible, it would not 
> help very much to document how to update it.  The directions would be 
> too confusing AND get out of date too quickly.  From our experience THAT 
> would lead to even MORE support issues.
....

"Complicated and fragile" I'll certainly agree with.

Although, after finally digging through it enough to get the current 
version of the compiler I use found, it turns out it wasn't _really_ 
that hard; what was hard was figuring out where the pieces of the 
puzzler were hidden; not making those changes.

As far as what I was suggesting, it wouldn't take much other than a 
simple roadmap thru the sequence of m-files and the perl script to lay 
out the location and search pattern used to locate a given vendor's 
supported compiler and the naming convention(s) used in the batch files.

Once that is known and doesn't have to be uncovered by trial and error 
and reading the code, then it is at least relatively straightforward for 
the compiler use to reference an updated version of the same compiler.

The issue of support regarding testing and so on I agree would devolve 
to user-responsibility for the results; I and Doug or any other 
reasonable user would expect nothing else.  Keeping the simplest 
information hidden to even make simply going from V6.5 to V6.6 of the 
same compiler is only obstructionist on TMW's part imo, however.

One would think that after 20+ years the problem would somehow have 
percolated up the importance chain if TMW were really interested in 
making a more easily used/supported interface.  Again, my observation as 
user only, of course...

--

dpb wrote:
....

> The issue of support regarding testing and so on I agree would devolve 
> to user-responsibility for the results; I and Doug or any other 
> reasonable user would expect nothing else.  Keeping the simplest 
> information hidden to even make simply going from V6.5 to V6.6 of the 
> same compiler is only obstructionist on TMW's part imo, however.
....

I'll add that _IF_ (the proverbial "big if") the compiler vendor chooses 
to make changes between revisons that break something it's _NOT_ TMW's 
fault and TMW is under no obligation to solve the problem or otherwise 
respond; it's the user's ball and either they can work it out or find a 
solution from the compiler vendor until TMW makes another scheduled 
release (assuming they choose to do so).

The problem I and so many others seem to have is that there's nothing 
changed that's fundamental to the compiler other than an update but 
there's no way to get the benefit of those bug fixes other than by a 
very painful effort that wouldn't and doesn't need to be so painful in 
most cases.

--