f



Compaq Visual Fortran discontinued: upgrade to Intel Visual Fortran?

Hi,
I use the latest version of Compaq Visual Fortran on a Windows system. CVF 
development is being discontinued as of the end of this year. They offer an 
upgrade to Intel Visual Fortran 9.0. Any thoughts on whether this is 
advisable/desirable/necessary would be highly appreciated. Does anybody have 
experiences going that route already?
Thanks a lot.
--hh
-- 
 


0
not13 (52)
11/28/2005 4:25:45 PM
comp.lang.fortran 11941 articles. 1 followers. Post Follow

75 Replies
2727 Views

Similar Articles

[PageSpeed] 46

It would be also interesting to know what happens with and AMD Athlon 
processor. Does the Intel Visual Fortran proposes optimizations for AMD ?

NN a �crit :
> Hi,
> I use the latest version of Compaq Visual Fortran on a Windows system. CVF 
> development is being discontinued as of the end of this year. They offer an 
> upgrade to Intel Visual Fortran 9.0. Any thoughts on whether this is 
> advisable/desirable/necessary would be highly appreciated. Does anybody have 
> experiences going that route already?
> Thanks a lot.
> --hh
0
11/28/2005 5:27:22 PM
Vincent wrote:
> It would be also interesting to know what happens with and AMD Athlon 
> processor. Does the Intel Visual Fortran proposes optimizations for AMD ?
> 
ifort has options which support both AMD and Intel processors, but none 
which intentionally favor AMD over Intel.
0
tprince (584)
11/28/2005 6:26:31 PM
NN articulated on 11/28/05 17:25:
> Hi,
> I use the latest version of Compaq Visual Fortran on a Windows system. CVF 
> development is being discontinued as of the end of this year. They offer an 
> upgrade to Intel Visual Fortran 9.0. Any thoughts on whether this is 
> advisable/desirable/necessary would be highly appreciated. Does anybody have 
> experiences going that route already?
> Thanks a lot.
> --hh

When I compile my nonlinear finite element code using

ifort -O3 -ip -ipo -c *.f90

the resulting executable is roughly 3 times faster than that produced by

g95 -O3 -malign-double -march=pentium4 -mfpmath=sse -funroll-loops
-ffast-math -c *.f90

on Debian Linux version 3.1 running on Pentium M 1.7 GHz with 1GB RAM.
Note that, if I use the -fast option of ifort, execution is even faster
but the results produced are garbage and thus this does not count.

Of course, this does not provide a comparison of ifort with CVF's f90.
However, CVF's f90 does not run on Linux, and the comparison above might
give a hint as to how well ifort performs.

Does CVF's f90 perform 3 times better than g95 on Windows using the same
switches?

-- 
FCC.
===
The only way a woman can ever reform her husband is by boring him so
completely that he loses all possible interest in life.
-Oscar Wilde (1854-1900)
0
fccaner (35)
11/28/2005 7:06:14 PM
In article <rZHif.24530$dO2.10203@newssvr29.news.prodigy.net>,
Tim Prince  <tprince@nospamcomputer.org> wrote:

>ifort has options which support both AMD and Intel processors, but none 
>which intentionally favor AMD over Intel.

Wow. Now that's some interesting double-speak.

-- greg


0
lindahl (697)
11/28/2005 7:34:31 PM
Greg Lindahl wrote:
> In article <rZHif.24530$dO2.10203@newssvr29.news.prodigy.net>,
> Tim Prince  <tprince@nospamcomputer.org> wrote:
> 
> 
>>ifort has options which support both AMD and Intel processors, but none 
>>which intentionally favor AMD over Intel.
> 
> 
> Wow. Now that's some interesting double-speak.
> 
> -- greg
> 
> 

Speaking for PathScale, Intel's direct competitor and your employer, or for 
yourself?

cheers,

Rich
0
rhdt (1081)
11/28/2005 7:44:58 PM
Tim Prince wrote:
> Vincent wrote:
> 
>> It would be also interesting to know what happens with and AMD Athlon 
>> processor. Does the Intel Visual Fortran proposes optimizations for AMD ?
>>
> ifort has options which support both AMD and Intel processors, but none 
> which intentionally favor AMD over Intel.

In other words, some optimisation for AMD, but not enough to threaten Intel.
0
bogle (300)
11/28/2005 7:45:56 PM
FCC wrote:

> Does CVF's f90 perform 3 times better than g95 on Windows using the same
> switches?

On your code.  How can he answer that?
0
bogle (300)
11/28/2005 7:46:58 PM
In article <dmfmpq$7i$1@scrotar.nss.udel.edu>,
Rich Townsend  <rhdt@barVOIDtol.udel.edu> wrote:

>Speaking for PathScale, Intel's direct competitor and your employer, or for 
>yourself?

I think my history answers that pretty well: speaking for myself, not
PathScale. BTW, Intel does not consider our relationship to be
competition; we receive support from Intel for our efforts to produce
the best EM64T compiler, as well as for our future PCI
Express-connected interconnect chip, which will mostly be used
with Intel cpus.

-- greg
(working for, not speaking for, PathScale.)

0
lindahl (697)
11/28/2005 8:00:25 PM
Gib Bogle articulated on 11/28/05 20:46:
> FCC wrote:
> 
> 
>>Does CVF's f90 perform 3 times better than g95 on Windows using the same
>>switches?
> 
> 
> On your code.  How can he answer that?

OK, I will find it out tomorrow and post the results.

-- 
FCC.
===
I think................I am paid.
-Anonymous
0
fccaner (35)
11/28/2005 8:31:01 PM
> I use the latest version of Compaq Visual Fortran on a Windows system. CVF development is being discontinued as of the end of this 
> year. They offer an upgrade to Intel Visual Fortran 9.0. Any thoughts on whether this is advisable/desirable/necessary would be 
> highly appreciated. Does anybody have experiences going that route already?

Yes, IVF 9 and MS Visual Studio 2003 are a good combo except for
one item.  MSVS 2003 and IVF do not support lookup of fortran symbols.
That is a major, major pain.

Lynn


0
nospam21 (19047)
11/28/2005 10:24:45 PM
Lynn McGuire wrote:
>>I use the latest version of Compaq Visual Fortran on a Windows system. CVF development is being discontinued as of the end of this 
>>year. They offer an upgrade to Intel Visual Fortran 9.0. Any thoughts on whether this is advisable/desirable/necessary would be 
>>highly appreciated. Does anybody have experiences going that route already?
> 
> 
> Yes, IVF 9 and MS Visual Studio 2003 are a good combo except for
> one item.  MSVS 2003 and IVF do not support lookup of fortran symbols.

Excuse my thick-headedness, but what does "lookup of fortran symbols" mean?

cheers,

paulv

-- 
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
0
paul.vandelst (1947)
11/28/2005 10:31:01 PM
>> Yes, IVF 9 and MS Visual Studio 2003 are a good combo except for
>> one item.  MSVS 2003 and IVF do not support lookup of fortran symbols.
>
> Excuse my thick-headedness, but what does "lookup of fortran symbols" mean?

I am sorry, I meant to say that the source code browser in MSVS does not
work with fortran symbols.  That means that the right mouse click "go to
definition" and "go to declaration" do not work for fortran variables and
fortran subroutines/functions.  Very painfull.

You can see a little more here:
   http://softwareforums.intel.com/ids/board/message?board.id=5&message.id=15754

Lynn


0
nospam21 (19047)
11/28/2005 11:19:48 PM
"Lynn McGuire" <nospam@nospam.com> wrote in message
news:11on44lp9etfs62@corp.supernews.com...
> >> Yes, IVF 9 and MS Visual Studio 2003 are a good combo except for
> >> one item.  MSVS 2003 and IVF do not support lookup of fortran symbols.
> >
> > Excuse my thick-headedness, but what does "lookup of fortran symbols"
mean?
>
> I am sorry, I meant to say that the source code browser in MSVS does not
> work with fortran symbols.  That means that the right mouse click "go to
> definition" and "go to declaration" do not work for fortran variables and
> fortran subroutines/functions.  Very painfull.

There are numerous reasons why IVF 9 and MS Visual Studio 2003/05 are NOT a
good combo, lookup of fortran symbols being least among them. This is
entirely due to intel ineptitude, Microsoft gave them all the latitude they
needed but they simply faltered, floundered, and failed. The duplicitous
intel automoton sees otherwise, but he's a mere corporate lackey paid to
decieve.

-- 
Cheers,
Hrundi V.B.
______
"I promise there will be fewer nuclear disasters with me as your mayor than
with me as your nuclear safety inspector."  Homer Simpson




0
11/29/2005 6:26:21 AM
Vincent wrote:

> It would be also interesting to know what happens with and AMD Athlon 
> processor. Does the Intel Visual Fortran proposes optimizations for AMD ?
> 
I can't answer you about optimisations, but for me the upgrade process 
was just a question of recompiling. YMMV of course, the code I'm working 
on is far from cutting edge F95. I have an AMD Athlon processor and have 
never had a problem with any compiler with it.

Catherine.

> NN a �crit :
> 
>> Hi,
>> I use the latest version of Compaq Visual Fortran on a Windows system. 
>> CVF development is being discontinued as of the end of this year. They 
>> offer an upgrade to Intel Visual Fortran 9.0. Any thoughts on whether 
>> this is advisable/desirable/necessary would be highly appreciated. 
>> Does anybody have experiences going that route already?
>> Thanks a lot.
>> --hh

0
spamtrap7925 (139)
11/29/2005 10:30:54 AM
Is your program faster or slower with Intel Visual Fortran than with 
Compaq Visual Fortran ?
Vincent


Catherine Rees Lay a �crit :
> I can't answer you about optimisations, but for me the upgrade process 
> was just a question of recompiling. YMMV of course, the code I'm working 
> on is far from cutting edge F95. I have an AMD Athlon processor and have 
> never had a problem with any compiler with it.
> 
> Catherine.
0
11/29/2005 11:10:30 AM
FCC articulated on 11/28/2005 8:06 PM:

>NN articulated on 11/28/05 17:25:
>  
>
>>Hi,
>>I use the latest version of Compaq Visual Fortran on a Windows system. CVF 
>>development is being discontinued as of the end of this year. They offer an 
>>upgrade to Intel Visual Fortran 9.0. Any thoughts on whether this is 
>>advisable/desirable/necessary would be highly appreciated. Does anybody have 
>>experiences going that route already?
>>Thanks a lot.
>>--hh
>>    
>>
>
>When I compile my nonlinear finite element code using
>
>ifort -O3 -ip -ipo -c *.f90
>
>the resulting executable is roughly 3 times faster than that produced by
>
>g95 -O3 -malign-double -march=pentium4 -mfpmath=sse -funroll-loops
>-ffast-math -c *.f90
>
>on Debian Linux version 3.1 running on Pentium M 1.7 GHz with 1GB RAM.
>Note that, if I use the -fast option of ifort, execution is even faster
>but the results produced are garbage and thus this does not count.
>
>Of course, this does not provide a comparison of ifort with CVF's f90.
>However, CVF's f90 does not run on Linux, and the comparison above might
>give a hint as to how well ifort performs.
>
>Does CVF's f90 perform 3 times better than g95 on Windows using the same
>switches?
>
>  
>
OK, I had to boot to WinXP only to answer my own question. ifort on
WinXP, using the same switches as above, runs 5 times faster than g95
(cygwin version).

-- 
FCC.

===
We are what we repeatedly do. Excellence, therefore, is not an act but a
habit.
-Aristotle.
0
fccaner (35)
11/29/2005 11:35:50 AM
FCC articulated on 11/28/2005 8:06 PM:

>NN articulated on 11/28/05 17:25:
>  
>
>>Hi,
>>I use the latest version of Compaq Visual Fortran on a Windows system. CVF 
>>development is being discontinued as of the end of this year. They offer an 
>>upgrade to Intel Visual Fortran 9.0. Any thoughts on whether this is 
>>advisable/desirable/necessary would be highly appreciated. Does anybody have 
>>experiences going that route already?
>>Thanks a lot.
>>--hh
>>    
>>
>
>When I compile my nonlinear finite element code using
>
>ifort -O3 -ip -ipo -c *.f90
>
>the resulting executable is roughly 3 times faster than that produced by
>
>g95 -O3 -malign-double -march=pentium4 -mfpmath=sse -funroll-loops
>-ffast-math -c *.f90
>
>on Debian Linux version 3.1 running on Pentium M 1.7 GHz with 1GB RAM.
>Note that, if I use the -fast option of ifort, execution is even faster
>but the results produced are garbage and thus this does not count.
>
>Of course, this does not provide a comparison of ifort with CVF's f90.
>However, CVF's f90 does not run on Linux, and the comparison above might
>give a hint as to how well ifort performs.
>
>Does CVF's f90 perform 3 times better than g95 on Windows using the same
>switches?
>
>  
>
OK, I had to boot to WinXP only to answer my own question. The
executable ifort produces on WinXP, using the same switches as above,
runs 5 times faster than that produced by g95 (cygwin version).

-- 
FCC.

===
We are what we repeatedly do. Excellence, therefore, is not an act but a
habit.
-Aristotle.
0
fccaner (35)
11/29/2005 11:37:26 AM
FCC articulated on 11/28/2005 8:06 PM:

>NN articulated on 11/28/05 17:25:
>  
>
>>Hi,
>>I use the latest version of Compaq Visual Fortran on a Windows system. CVF 
>>development is being discontinued as of the end of this year. They offer an 
>>upgrade to Intel Visual Fortran 9.0. Any thoughts on whether this is 
>>advisable/desirable/necessary would be highly appreciated. Does anybody have 
>>experiences going that route already?
>>Thanks a lot.
>>--hh
>>    
>>
>
>When I compile my nonlinear finite element code using
>
>ifort -O3 -ip -ipo -c *.f90
>
>the resulting executable is roughly 3 times faster than that produced by
>
>g95 -O3 -malign-double -march=pentium4 -mfpmath=sse -funroll-loops
>-ffast-math -c *.f90
>
>on Debian Linux version 3.1 running on Pentium M 1.7 GHz with 1GB RAM.
>Note that, if I use the -fast option of ifort, execution is even faster
>but the results produced are garbage and thus this does not count.
>
>Of course, this does not provide a comparison of ifort with CVF's f90.
>However, CVF's f90 does not run on Linux, and the comparison above might
>give a hint as to how well ifort performs.
>
>Does CVF's f90 perform 3 times better than g95 on Windows using the same
>switches?
>
>  
>
OK, I had to boot to WinXP only to answer my own question. The
executable ifort produces on WinXP, using the same switches as above,
that runs 5 times faster than that produced by g95 (cygwin version).

-- 
FCC.

===
We are what we repeatedly do. Excellence, therefore, is not an act but a
habit.
-Aristotle.
===
If income was directly proportional to technical proficiency and
education, classical and jazz musicians would be some of the most
affluent people in the world.
-Robert Coleman
0
fccaner (35)
11/29/2005 11:38:11 AM
FCC articulated on 11/28/2005 8:06 PM:

>NN articulated on 11/28/05 17:25:
>  
>
>>Hi,
>>I use the latest version of Compaq Visual Fortran on a Windows system. CVF 
>>development is being discontinued as of the end of this year. They offer an 
>>upgrade to Intel Visual Fortran 9.0. Any thoughts on whether this is 
>>advisable/desirable/necessary would be highly appreciated. Does anybody have 
>>experiences going that route already?
>>Thanks a lot.
>>--hh
>>    
>>
>
>When I compile my nonlinear finite element code using
>
>ifort -O3 -ip -ipo -c *.f90
>
>the resulting executable is roughly 3 times faster than that produced by
>
>g95 -O3 -malign-double -march=pentium4 -mfpmath=sse -funroll-loops
>-ffast-math -c *.f90
>
>on Debian Linux version 3.1 running on Pentium M 1.7 GHz with 1GB RAM.
>Note that, if I use the -fast option of ifort, execution is even faster
>but the results produced are garbage and thus this does not count.
>
>Of course, this does not provide a comparison of ifort with CVF's f90.
>However, CVF's f90 does not run on Linux, and the comparison above might
>give a hint as to how well ifort performs.
>
>Does CVF's f90 perform 3 times better than g95 on Windows using the same
>switches?
>
>  
>
OK, I had to boot to WinXP only to answer my own question. The
executable ifort produces on WinXP, using the same switches as above,
runs 5 times faster than that produced by g95 (cygwin version), using
the same switches as above.

I tried to check the run time with DVF, but for some reason I am getting
a linker error.

-- 
FCC.

===
We are what we repeatedly do. Excellence, therefore, is not an act but a
habit.
-Aristotle.
0
fccaner (35)
11/29/2005 11:40:00 AM
Vincent wrote:

> Is your program faster or slower with Intel Visual Fortran than with 
> Compaq Visual Fortran ?
> Vincent
> 

Sorry, it's not that sort of program - it's entirely user-interface driven.

Having said that, have you seen these?

http://www.polyhedron.com/pb05/win32/f90bench_p4.html

If nothing else, it demonstrates just how problem-dependent the relative 
speed of different compilers is :-) But it might be specifically useful 
if your code is very like one of the benchmarks.

Catherine (I work for Polyhedron as a programmer).

> 
> Catherine Rees Lay a �crit :
> 
>> I can't answer you about optimisations, but for me the upgrade process 
>> was just a question of recompiling. YMMV of course, the code I'm 
>> working on is far from cutting edge F95. I have an AMD Athlon 
>> processor and have never had a problem with any compiler with it.
>>
>> Catherine.

0
spamtrap7925 (139)
11/29/2005 1:50:10 PM
Thank you very much, everybody, for your responses so far. While 
interesting, I regret to say that none of the responses so far has been very 
helpful for my decision and I'm sure that's entirely my fault for not being 
specific enough. Let me try again.
(1)   More speed is nice, but it's not really an issue since I learned a 
long time ago that this can easily become a game of diminishing returns. 
I'll gladly sacrifice a factor of 2 in speed if I can have code that's easy 
to debug and maintain.
(2)   Is the integrated editor/debugger environment of IVF similar/different 
from CVF? If different, what are the differences?
(3)   Does windows-specific code compile (i.e., code that uses graphics 
routines)? Are there any problems linking the CVF-specific libraries? (Or 
are there similar ones in IVF?)
(4)   Are there other issues with code portability?

I should say, that for my present needs CVF is perfectly okay. My question 
therefore is: Should I shell out $650 now for an upgrade to IVF, to preserve 
the option of further upgrades down the road, or should I simply stick with 
CVF for now and perhaps at some later stage, if the need arises, buy a full 
version of IVF.

Thank you.
--hh



"NN" <not@home.net> wrote in message 
news:ZbGif.18969$ih5.10988@dukeread11...
> Hi,
> I use the latest version of Compaq Visual Fortran on a Windows system. CVF 
> development is being discontinued as of the end of this year. They offer 
> an upgrade to Intel Visual Fortran 9.0. Any thoughts on whether this is 
> advisable/desirable/necessary would be highly appreciated. Does anybody 
> have experiences going that route already?
> Thanks a lot.
> --hh
> -- 
>
>
> 


0
not13 (52)
11/29/2005 4:28:05 PM
NN wrote:
> 
> Thank you very much, everybody, for your responses so far. While
> interesting, I regret to say that none of the responses so far has been very
> helpful for my decision and I'm sure that's entirely my fault for not being
> specific enough. Let me try again.
> (1)   More speed is nice, but it's not really an issue since I learned a
> long time ago that this can easily become a game of diminishing returns.
> I'll gladly sacrifice a factor of 2 in speed if I can have code that's easy
> to debug and maintain.
> (2)   Is the integrated editor/debugger environment of IVF similar/different
> from CVF? If different, what are the differences?
> (3)   Does windows-specific code compile (i.e., code that uses graphics
> routines)? Are there any problems linking the CVF-specific libraries? (Or
> are there similar ones in IVF?)
> (4)   Are there other issues with code portability?

I'd think the thing to do would be to download the trial version and
play w/ it some.  My understanding is that you have to have the MS
Visual Studio in addition to the Intel-supplied compiler/components to
get the IDE as MS chose to not license it to Intel for the integration
w/ the compiler as was done w/ CVF.
 
> I should say, that for my present needs CVF is perfectly okay. My question
> therefore is: Should I shell out $650 now for an upgrade to IVF, to preserve
> the option of further upgrades down the road, or should I simply stick with
> CVF for now and perhaps at some later stage, if the need arises, buy a full
> version of IVF.
....

I'd say only you can answer the last question, but unless you're working
on a commercial product it would seem quite unneeded.
0
dpbozarth (544)
11/29/2005 4:37:55 PM
"Duane Bozarth" <dpbozarth@swko.dot.net> wrote in message 
news:438C83E3.76058372@swko.dot.net...
> NN wrote:
>>
>> Thank you very much, everybody, for your responses so far. While
>> interesting, I regret to say that none of the responses so far has been 
>> very
>> helpful for my decision and I'm sure that's entirely my fault for not 
>> being
>> specific enough. Let me try again.
>> (1)   More speed is nice, but it's not really an issue since I learned a
>> long time ago that this can easily become a game of diminishing returns.
>> I'll gladly sacrifice a factor of 2 in speed if I can have code that's 
>> easy
>> to debug and maintain.
>> (2)   Is the integrated editor/debugger environment of IVF 
>> similar/different
>> from CVF? If different, what are the differences?
>> (3)   Does windows-specific code compile (i.e., code that uses graphics
>> routines)? Are there any problems linking the CVF-specific libraries? (Or
>> are there similar ones in IVF?)
>> (4)   Are there other issues with code portability?
>
> I'd think the thing to do would be to download the trial version and
> play w/ it some.  My understanding is that you have to have the MS
> Visual Studio in addition to the Intel-supplied compiler/components to
> get the IDE as MS chose to not license it to Intel for the integration
> w/ the compiler as was done w/ CVF.

Yes, tried to do that, of course, but, as you said, it won't work without 
the MS IDE. Strangely enough, the compiler won't even run from the command 
line. Perhaps, there might be a way to integrate it with the IDE of CVF, but 
I don't know how. (Anybody know if that's possible?)



>
>> I should say, that for my present needs CVF is perfectly okay. My 
>> question
>> therefore is: Should I shell out $650 now for an upgrade to IVF, to 
>> preserve
>> the option of further upgrades down the road, or should I simply stick 
>> with
>> CVF for now and perhaps at some later stage, if the need arises, buy a 
>> full
>> version of IVF.
> ...
>
> I'd say only you can answer the last question, but unless you're working
> on a commercial product it would seem quite unneeded.

Well, that would be my first reaction as well, that I don't need it right 
now, but maybe I'm missing some compelling reasons. That's why I posed the 
question to this forum.

Thanks.
--hh



0
not13 (52)
11/29/2005 4:59:29 PM
In article <rZHif.24530$dO2.10203@newssvr29.news.prodigy.net>,
Tim Prince  <tprince@nospamcomputer.org> wrote:
>Vincent wrote:
>> It would be also interesting to know what happens with and AMD Athlon 
>> processor. Does the Intel Visual Fortran proposes optimizations for AMD ?
>> 
>ifort has options which support both AMD and Intel processors, but none 
>which intentionally favor AMD over Intel.

It's worth pointing out that that's not entirely true:  IFC is nobbled
for AMD processors (under some circumstances it refuses to allow
SSE/SSE2 code to run on AMD chips). Having said that,

a) this (in my experience) isn't a significant problem for 64-bit code
b) can be easily worked around by either patching the compiler or
   patching the executable to remove the 'am I running on an Intel chip'
   test (see http://www.swallowtail.org/naughty-intel.html for details)

Intel's checking for the 'GenuineIntel' CPU identifier string and
reducing performance if it isn't found is definitely evidence of 'bad
faith' on their part, so that may inform your decision. However, it does
produce the fastest code for my software, so I use it anyway and hold my
nose :).

-- 
Mark Mackey   http://www.swallowtail.org/
code code code code code code code code code code code code code bug code co
de code code code bug code code code code code code code code code code code
code code code code code code code code code code code code code code code c
0
markm13 (51)
11/29/2005 5:02:48 PM
NN wrote:
> 
> "Duane Bozarth" <dpbozarth@swko.dot.net> wrote in message
> news:438C83E3.76058372@swko.dot.net...
> > NN wrote:
> >>
> >> Thank you very much, everybody, for your responses so far. While
> >> interesting, I regret to say that none of the responses so far has been
> >> very
> >> helpful for my decision and I'm sure that's entirely my fault for not
> >> being
> >> specific enough. Let me try again.
> >> (1)   More speed is nice, but it's not really an issue since I learned a
> >> long time ago that this can easily become a game of diminishing returns.
> >> I'll gladly sacrifice a factor of 2 in speed if I can have code that's
> >> easy
> >> to debug and maintain.
> >> (2)   Is the integrated editor/debugger environment of IVF
> >> similar/different
> >> from CVF? If different, what are the differences?
> >> (3)   Does windows-specific code compile (i.e., code that uses graphics
> >> routines)? Are there any problems linking the CVF-specific libraries? (Or
> >> are there similar ones in IVF?)
> >> (4)   Are there other issues with code portability?
> >
> > I'd think the thing to do would be to download the trial version and
> > play w/ it some.  My understanding is that you have to have the MS
> > Visual Studio in addition to the Intel-supplied compiler/components to
> > get the IDE as MS chose to not license it to Intel for the integration
> > w/ the compiler as was done w/ CVF.
> 
> Yes, tried to do that, of course, but, as you said, it won't work without
> the MS IDE. Strangely enough, the compiler won't even run from the command
> line. Perhaps, there might be a way to integrate it with the IDE of CVF, but
> I don't know how. (Anybody know if that's possible?)

I was under the impression that there was a command line option (altho
I've not tried).

I doubt the current version will interact w/ previous versions of VS.

 
> >
> >> I should say, that for my present needs CVF is perfectly okay. My
> >> question
> >> therefore is: Should I shell out $650 now for an upgrade to IVF, to
> >> preserve
> >> the option of further upgrades down the road, or should I simply stick
> >> with
> >> CVF for now and perhaps at some later stage, if the need arises, buy a
> >> full
> >> version of IVF.
> > ...
> >
> > I'd say only you can answer the last question, but unless you're working
> > on a commercial product it would seem quite unneeded.
> 
> Well, that would be my first reaction as well, that I don't need it right
> now, but maybe I'm missing some compelling reasons. That's why I posed the
> question to this forum.

In the same situation I've found no reason to switch.  Only thing I see
would be if one needs some feature not currently available w/ your
present compiler or need active vendor support.
0
dpbozarth (544)
11/29/2005 5:08:30 PM
Duane Bozarth wrote:
> 
> NN wrote:
> >
....

> > Yes, tried to do that, of course, but, as you said, it won't work without
> > the MS IDE. Strangely enough, the compiler won't even run from the command
> > line. Perhaps, there might be a way to integrate it with the IDE of CVF, but
> > I don't know how. (Anybody know if that's possible?)
> 
> I was under the impression that there was a command line option (altho
> I've not tried).
... 

OK, I shoulda' looked before posting... :)

http://www.intel.com/cd/software/products/asmo-na/eng/compilers/219994.htm

links to the requirements page.

For IA32 says _do_ need VS installed.  If limit to Itanium appears the
MS SDK is ok.
0
dpbozarth (544)
11/29/2005 5:36:30 PM
>> I am sorry, I meant to say that the source code browser in MSVS does not
>> work with fortran symbols.  That means that the right mouse click "go to
>> definition" and "go to declaration" do not work for fortran variables and
>> fortran subroutines/functions.  Very painfull.
>
> There are numerous reasons why IVF 9 and MS Visual Studio 2003/05 are NOT a
> good combo, lookup of fortran symbols being least among them.

Can you state these reasons please ?

Thanks,
Lynn McGuire


0
nospam21 (19047)
11/29/2005 7:09:03 PM
NN wrote:
> "Duane Bozarth" <dpbozarth@swko.dot.net> wrote in message 
> news:438C83E3.76058372@swko.dot.net...
>>I'd think the thing to do would be to download the trial version and
>>play w/ it some.  My understanding is that you have to have the MS
>>Visual Studio in addition to the Intel-supplied compiler/components to
>>get the IDE as MS chose to not license it to Intel for the integration
>>w/ the compiler as was done w/ CVF.
> 
> Yes, tried to do that, of course, but, as you said, it won't work without 
> the MS IDE. Strangely enough, the compiler won't even run from the command 
> line. Perhaps, there might be a way to integrate it with the IDE of CVF, but 
> I don't know how. (Anybody know if that's possible?)

The Intel compiler also depends on some parts of MS Visual Studio other 
than the IDE -- my recollection is that it depends on the linker or 
something of that nature.

The command-line parts of MS Visual Studio that are needed for Intel 
Fortran are available from MS as a no-cost download, though I don't 
remember the URL offhand.  With these, one can use the compiler in 
command-line mode without having to install Visual Studio.

- Brooks


-- 
The "bmoses-nospam" address is valid; no unmunging needed.
0
bmoses-nospam (1266)
11/29/2005 8:06:23 PM
Mr Hrundi V Bakshi wrote:
> ...The duplicitous
> intel automoton sees otherwise, but he's a mere corporate lackey paid to
> decieve (sic).

I didn't think you needed to pay automatons.


-- 
Mark Hadfield          "Kei puwaha te tai nei, Hoea tahi tatou"
m.hadfield@niwa.co.nz
National Institute for Water and Atmospheric Research (NIWA)
0
m.hadfield (294)
11/29/2005 10:13:26 PM
In article <dmijq5$gnu$2@newsreader.mailgate.org>,
Mark Hadfield  <m.hadfield@niwa.co.nz> wrote:

>I didn't think you needed to pay automatons.

Nor do trolls need feeding.

-- g
0
lindahl (697)
11/29/2005 10:28:35 PM
Greg Lindahl wrote:
> In article <dmijq5$gnu$2@newsreader.mailgate.org>,
> Mark Hadfield  <m.hadfield@niwa.co.nz> wrote:
> 
> 
>>I didn't think you needed to pay automatons.
> 
> 
> Nor do trolls need feeding.
> 
> -- g

Oh, now that's a bit harsh. He's not a troll, he's the group's pet gimp. 
He's....  'special'.

cheers,

Rich
0
rhdt (1081)
11/30/2005 12:12:30 AM
NN wrote:

> Thank you very much, everybody, for your responses so far. While 
> interesting, I regret to say that none of the responses so far has been very 
> helpful for my decision and I'm sure that's entirely my fault for not being 
> specific enough. Let me try again.
> (1)   More speed is nice, but it's not really an issue since I learned a 
> long time ago that this can easily become a game of diminishing returns. 
> I'll gladly sacrifice a factor of 2 in speed if I can have code that's easy 
> to debug and maintain.
> (2)   Is the integrated editor/debugger environment of IVF similar/different 
> from CVF? If different, what are the differences?
> (3)   Does windows-specific code compile (i.e., code that uses graphics 
> routines)? Are there any problems linking the CVF-specific libraries? (Or 
> are there similar ones in IVF?)
> (4)   Are there other issues with code portability?
> 
> I should say, that for my present needs CVF is perfectly okay. My question 
> therefore is: Should I shell out $650 now for an upgrade to IVF, to preserve 
> the option of further upgrades down the road, or should I simply stick with 
> CVF for now and perhaps at some later stage, if the need arises, buy a full 
> version of IVF.

Don't top-post.  I haven't switched.
0
g.bogle (180)
11/30/2005 2:09:30 AM
Duane Bozarth wrote:
> NN wrote:
> 
>>Thank you very much, everybody, for your responses so far. While
>>interesting, I regret to say that none of the responses so far has been very
>>helpful for my decision and I'm sure that's entirely my fault for not being
>>specific enough. Let me try again.
>>(1)   More speed is nice, but it's not really an issue since I learned a
>>long time ago that this can easily become a game of diminishing returns.
>>I'll gladly sacrifice a factor of 2 in speed if I can have code that's easy
>>to debug and maintain.
>>(2)   Is the integrated editor/debugger environment of IVF similar/different
>>from CVF? If different, what are the differences?
>>(3)   Does windows-specific code compile (i.e., code that uses graphics
>>routines)? Are there any problems linking the CVF-specific libraries? (Or
>>are there similar ones in IVF?)
>>(4)   Are there other issues with code portability?
> 
> 
> I'd think the thing to do would be to download the trial version and
> play w/ it some.  My understanding is that you have to have the MS
> Visual Studio in addition to the Intel-supplied compiler/components to
> get the IDE as MS chose to not license it to Intel for the integration
> w/ the compiler as was done w/ CVF.

I've never heard that MS refused to license to Intel.  My understanding 
was that the licensing would have been identical to that offered to 
Lahey and Salford and others and Intel chose not to go that route 
(cost?, lesser integration than CVF provided).  Is that not true?

>  
> 
>>I should say, that for my present needs CVF is perfectly okay. My question
>>therefore is: Should I shell out $650 now for an upgrade to IVF, to preserve
>>the option of further upgrades down the road, or should I simply stick with
>>CVF for now and perhaps at some later stage, if the need arises, buy a full
>>version of IVF.
> 
> ...
> 
> I'd say only you can answer the last question, but unless you're working
> on a commercial product it would seem quite unneeded.


-- 

Gary Scott
mailto:garyscott@ev1.net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

Why are there two?  God only knows.


If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford
0
garyscott (569)
11/30/2005 2:43:40 AM
Gib Bogle wrote:

> NN wrote:
> 
>> Thank you very much, everybody, for your responses so far. While 
>> interesting, I regret to say that none of the responses so far has 
>> been very helpful for my decision and I'm sure that's entirely my 
>> fault for not being specific enough. Let me try again.
>> (1)   More speed is nice, but it's not really an issue since I learned 
>> a long time ago that this can easily become a game of diminishing 
>> returns. I'll gladly sacrifice a factor of 2 in speed if I can have 
>> code that's easy to debug and maintain.
>> (2)   Is the integrated editor/debugger environment of IVF 
>> similar/different from CVF? If different, what are the differences?
>> (3)   Does windows-specific code compile (i.e., code that uses 
>> graphics routines)? Are there any problems linking the CVF-specific 
>> libraries? (Or are there similar ones in IVF?)
>> (4)   Are there other issues with code portability?
>>
>> I should say, that for my present needs CVF is perfectly okay. My 
>> question therefore is: Should I shell out $650 now for an upgrade to 
>> IVF, to preserve the option of further upgrades down the road, or 
>> should I simply stick with CVF for now and perhaps at some later 
>> stage, if the need arises, buy a full version of IVF.
> 
> 
> Don't top-post.  I haven't switched.

I haven't switched.  I probably will hold off as long as possible.  If 
they come out with an integrated CVF-like product rather than a half 
measure, I will buy it within seconds of becoming aware of it (multiple 
copies).  If I reach a point where CVF no longer supports my needs and 
IVF is still inadequate, I will likely be forced to go another route.

-- 

Gary Scott
mailto:garyscott@ev1.net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

Why are there two?  God only knows.


If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford
0
garyscott (569)
11/30/2005 2:50:20 AM
"Gary L. Scott" <garyscott@ev1.net> wrote in message
news:11oq4f6lakp3da1@corp.supernews.com...

> >
> >>I should say, that for my present needs CVF is perfectly okay.
>> My question therefore is: Should I shell out $650 now for an upgrade to
IVF, to preserve
> >>the option of further upgrades down the road, or should I simply stick
with
> >>CVF for now and perhaps at some later stage, if the need arises, buy a
full
> >>version of IVF.
> >

oN, or aer u as dume as de oder futon (maybe it be fortran, who cares?)
dingbats.

Isn't fortran fun or not?
--
Howdy partnert,
Hrundi V.B.


0
11/30/2005 7:13:46 AM
"NN" <not@home.net> wrote in message news:wN%if.8$fz5.2@dukeread04...
> "Duane Bozarth" <dpbozarth@swko.dot.net> wrote in message 
> news:438C83E3.76058372@swko.dot.net...
>> NN wrote:
>>>
>>> Thank you very much, everybody, for your responses so far. While
>>> interesting, I regret to say that none of the responses so far has been 
>>> very
>>> helpful for my decision and I'm sure that's entirely my fault for not 
>>> being
>>> specific enough. Let me try again.
>>> (1)   More speed is nice, but it's not really an issue since I learned a
>>> long time ago that this can easily become a game of diminishing returns.
>>> I'll gladly sacrifice a factor of 2 in speed if I can have code that's 
>>> easy
>>> to debug and maintain.
>>> (2)   Is the integrated editor/debugger environment of IVF 
>>> similar/different
>>> from CVF? If different, what are the differences?
>>> (3)   Does windows-specific code compile (i.e., code that uses graphics
>>> routines)? Are there any problems linking the CVF-specific libraries? 
>>> (Or
>>> are there similar ones in IVF?)
>>> (4)   Are there other issues with code portability?
>>
>> I'd think the thing to do would be to download the trial version and
>> play w/ it some.  My understanding is that you have to have the MS
>> Visual Studio in addition to the Intel-supplied compiler/components to
>> get the IDE as MS chose to not license it to Intel for the integration
>> w/ the compiler as was done w/ CVF.
>
> Yes, tried to do that, of course, but, as you said, it won't work without 
> the MS IDE. Strangely enough, the compiler won't even run from the command 
> line. Perhaps, there might be a way to integrate it with the IDE of CVF, 
> but I don't know how. (Anybody know if that's possible?)
>

Works very well on the commandline with
Visual C++ Toolkit 2003
http://www.microsoft.com/downloads/details.aspx?FamilyID=272be09d-40bb-49fd-9cb0-4bfa122fa91b&DisplayLang=en


Alex 


0
news166 (117)
11/30/2005 1:37:44 PM
Thanks for that.  I didn't write the above quoted material.

0
gary.l.scott (237)
11/30/2005 5:54:02 PM
"Alex Gibson" <news@alxx.org> wrote in message 
news:3v89v4F1459stU1@individual.net...
>
> "NN" <not@home.net> wrote in message news:wN%if.8$fz5.2@dukeread04...
>> "Duane Bozarth" <dpbozarth@swko.dot.net> wrote in message 
>> news:438C83E3.76058372@swko.dot.net...
>>> NN wrote:
>>>>
>>>> Thank you very much, everybody, for your responses so far. While
>>>> interesting, I regret to say that none of the responses so far has been 
>>>> very
>>>> helpful for my decision and I'm sure that's entirely my fault for not 
>>>> being
>>>> specific enough. Let me try again.
>>>> (1)   More speed is nice, but it's not really an issue since I learned 
>>>> a
>>>> long time ago that this can easily become a game of diminishing 
>>>> returns.
>>>> I'll gladly sacrifice a factor of 2 in speed if I can have code that's 
>>>> easy
>>>> to debug and maintain.
>>>> (2)   Is the integrated editor/debugger environment of IVF 
>>>> similar/different
>>>> from CVF? If different, what are the differences?
>>>> (3)   Does windows-specific code compile (i.e., code that uses graphics
>>>> routines)? Are there any problems linking the CVF-specific libraries? 
>>>> (Or
>>>> are there similar ones in IVF?)
>>>> (4)   Are there other issues with code portability?
>>>
>>> I'd think the thing to do would be to download the trial version and
>>> play w/ it some.  My understanding is that you have to have the MS
>>> Visual Studio in addition to the Intel-supplied compiler/components to
>>> get the IDE as MS chose to not license it to Intel for the integration
>>> w/ the compiler as was done w/ CVF.
>>
>> Yes, tried to do that, of course, but, as you said, it won't work without 
>> the MS IDE. Strangely enough, the compiler won't even run from the 
>> command line. Perhaps, there might be a way to integrate it with the IDE 
>> of CVF, but I don't know how. (Anybody know if that's possible?)
>>
>
> Works very well on the commandline with
> Visual C++ Toolkit 2003
> http://www.microsoft.com/downloads/details.aspx?FamilyID=272be09d-40bb-49fd-9cb0-4bfa122fa91b&DisplayLang=en
>
>
> Alex

Thanks; was looking for that address.
--hh 


0
not13 (52)
12/1/2005 1:23:06 PM
NN wrote:
> 
> I use the latest version of Compaq Visual Fortran on a Windows system. CVF
> development is being discontinued as of the end of this year. They offer an
> upgrade to Intel Visual Fortran 9.0. Any thoughts on whether this is
> advisable/desirable/necessary would be highly appreciated. 

In a nutshell, it's a big unqualified *NO* on all there counts. You
could spend few moments reviewing posts from Intel's Houdini (curiously
absent in this thread) who has been trying endlessly to disguise this
deadbeat compiler with a Microsoft Visual coat, but in small print he
advised as follows:

"This product does NOT include an integrated development environment
(IDE), that is, a graphical developer, editor, debugger. This compiler
is a plug-in to an existing Microsoft C++ .NET or Visual Studio .NET
environment. If you do NOT own the Microsoft.NET environment then this
product will function as a command line compiler ONLY."

0
kia (104)
12/3/2005 6:46:48 AM
Mark Mackey wrote:
> 
> It's worth pointing out that that's not entirely true:  IFC is nobbled
> for AMD processors (under some circumstances it refuses to allow
> SSE/SSE2 code to run on AMD chips). Having said that,
> 
> a) this (in my experience) isn't a significant problem for 64-bit code
> b) can be easily worked around by either patching the compiler or
>    patching the executable to remove the 'am I running on an Intel chip'
>    test (see http://www.swallowtail.org/naughty-intel.html for details)
> 
> Intel's checking for the 'GenuineIntel' CPU identifier string and
> reducing performance if it isn't found is definitely evidence of 'bad
> faith' on their part, so that may inform your decision.

Fascinating example of software forensics - while AMD is probably aware
of it, do bring it to their attention. This is a lot more than "bad
faith" when the offending criminal is also a monopoly.

"It's not easy to get people to read a lawsuit, but we want people to
see there's a dark underside to Intel." 

        http://www.amd.com/breakfree
0
kia (104)
12/3/2005 7:33:05 AM
"kia" <kia@sparrow.com> wrote in message
news:43913D93.27D92536@sparrow.com...
> NN wrote:
> >
> > I use the latest version of Compaq Visual Fortran on a Windows system.
CVF
> > development is being discontinued as of the end of this year. They
offer an
> > upgrade to Intel Visual Fortran 9.0. Any thoughts on whether this is
> > advisable/desirable/necessary would be highly appreciated.
>
> In a nutshell, it's a big unqualified *NO* on all there counts. You
> could spend few moments reviewing posts from Intel's Houdini (curiously
> absent in this thread) who has been trying endlessly to disguise this
> deadbeat compiler with a Microsoft Visual coat, but in small print he
> advised as follows:
>
> "This product does NOT include an integrated development environment
> (IDE), that is, a graphical developer, editor, debugger. This compiler
> is a plug-in to an existing Microsoft C++ .NET or Visual Studio .NET
> environment. If you do NOT own the Microsoft.NET environment then this
> product will function as a command line compiler ONLY."
>

Me Hrundi. Ce?. What? Si. Ce? Si, ce, what? Si. Ce, si, what? Si. ....

Enough of ce?

This is the current score:

For IVF 2003, ADDITIONALLY pay Microsoft ~$90 for MVC standard. (for the
IDE and a nonoptimizing MVC compiler on a par with IVF). With IVF 2005 (if
and when it's available) ADDITIONALLY pay Microsoft ~$300 to lend life to
IVF and its multitude of flaws.

Even money that the serb is first taker!

-- 
You're Welcome,
Hrundi V.B..
______
"As a native of the snow belt of upstate New York, I too claim the feisty
independence of the Northerner. I was raised, I like to say, breathing
cold, clear Canadian air." Camille Paglia.


0
12/3/2005 8:18:54 AM
Alex Gibson wrote:
> Works very well on the commandline with
> Visual C++ Toolkit 2003
> http://www.microsoft.com/downloads/details.aspx?FamilyID=272be09d-40bb-49fd-9cb0-4bfa122fa91b&DisplayLang=en
>
>
> Alex

I tried this MS download along with the Intel Evaluation download and
still had missing libraries (uuid.lib and imagehlp.lib) at link time.

Al Greynolds

0
awgreynolds (138)
12/3/2005 4:18:56 PM
> For IVF 2003, ADDITIONALLY pay Microsoft ~$90 for MVC standard. (for the
> IDE and a nonoptimizing MVC compiler on a par with IVF). With IVF 2005 (if
> and when it's available) ADDITIONALLY pay Microsoft ~$300 to lend life to
> IVF and its multitude of flaws.

Can you please list these "multitude of flaws" ?

I am currently porting to IVF 9.0.  The problems that I am having
with our 550,000 lines of F77 code are of our own making.  They
have nothing to do with IVF.

Thanks,
Lynn McGuire


0
nospam21 (19047)
12/3/2005 11:03:47 PM
In article <4391492E.2A038CAE@sparrow.com>, kia  <kia@sparrow.com> wrote:

>Fascinating example of software forensics - while AMD is probably aware
>of it, do bring it to their attention.

AMD is well aware of it.

-- greg
(working for, not speaking for, PathScale.)
0
lindahl (697)
12/3/2005 11:17:59 PM
Lynn wrote:
>>For IVF 2003, ADDITIONALLY pay Microsoft ~$90 for MVC standard. (for the
>>IDE and a nonoptimizing MVC compiler on a par with IVF). With IVF 2005 (if
>>and when it's available) ADDITIONALLY pay Microsoft ~$300 to lend life to
>>IVF and its multitude of flaws.
> 
> 
> Can you please list these "multitude of flaws" ?
> 
> I am currently porting to IVF 9.0.  The problems that I am having
> with our 550,000 lines of F77 code are of our own making.  They
> have nothing to do with IVF.

IVF, er the "F" part of it is fine, even great as such things go.  If 
you're happy with a lesser overall product than DVF/CVF, it should be 
fine for you.

> 
> Thanks,
> Lynn McGuire
> 
> 


-- 

Gary Scott
mailto:garyscott@ev1.net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

Why are there two?  God only knows.


If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford
0
garyscott (569)
12/4/2005 1:16:59 AM
Mr Hrundi V Bakshi wrote:
>
> For IVF 2003, ADDITIONALLY pay Microsoft ~$90 for MVC standard. (for the
> IDE and a nonoptimizing MVC compiler on a par with IVF). With IVF 2005 (if
> and when it's available) ADDITIONALLY pay Microsoft ~$300 to lend life to
> IVF and its multitude of flaws.

This must be Santa's special, on Programmers Paradise Visual Studio
costs $720. While at it, I searched for CVF prices, and incredibly it
listed only IVF items, touted as "upgrades", and not a single CVF entry.
Very clever, as well as *illegal*, for Intel to  peddle their wares
under a borrowed label.

fyi, to see CVF entries, you must search for "Compaq Visual Fortran" -
they're one third the price of IVF crippled (sans Visual) compiler.

0
kia (104)
12/5/2005 2:56:51 AM
"kia" <kia@sparrow.com> wrote in message
news:4393AB36.27D1139A@sparrow.com...
> Mr Hrundi V Bakshi wrote:
> >
> > For IVF 2003, ADDITIONALLY pay Microsoft ~$90 for MVC standard. (for
the
> > IDE and a nonoptimizing MVC compiler on a par with IVF). With IVF 2005
(if
> > and when it's available) ADDITIONALLY pay Microsoft ~$300 to lend life
to
> > IVF and its multitude of flaws.
>
> This must be Santa's special,

Well not quite!

The Iterant (currently dubbed Intel)/Interloping IVF requires at minimum
VC++ .NET 2003/2005 to exhibit its dysfunctional and surprising multitude
of flaws @ an ADDITIONAL street cost of ~$100/300, respectively.

Think of CVF as Fortran's Elvis, not perfect and plied with Microsoft
uppers, but a darn sight better than its pseudo successors and hanger's on,
including col (sic parker) steveie the wonder, who has on call the
scrap-yard pooch SSgt Schultz (sic Maine) and his toadying c.l.f. groupies,
vaseline supplied.

--
Ce, si?
Hrundi V.B.



0
12/5/2005 4:13:13 AM
Yes, still waiting for Intel to deal with various issues. Their support was
helpful and found workarounds
but these involve compiling/linking from command line and a lot of code
change. Too onerous for the
project so gone back to CVF for the meantime. Hope they get it right.


0
Phil
12/5/2005 7:49:14 PM
> It's worth pointing out that that's not entirely true:  IFC is nobbled
> for AMD processors (under some circumstances it refuses to allow
> SSE/SSE2 code to run on AMD chips). Having said that,
[...]
> Intel's checking for the 'GenuineIntel' CPU identifier string and
> reducing performance if it isn't found is definitely evidence of 'bad
> faith' on their part, so that may inform your decision. 

Nonsense. Ever heard of product liability? This is a US company, and they
need to take such things seriously.

	Jan
0
12/8/2005 10:34:47 AM
> I haven't switched.  I probably will hold off as long as possible.  If 
> they come out with an integrated CVF-like product rather than a half 
> measure, I will buy it within seconds of becoming aware of it (multiple 
> copies).  

I don't understand - just because you have to buy the IDE seperately, as
MS insisted that the bundled variant would cost as much as the unbundled
variant, you're not even considering the product? Surely it's total pur-
chase price that counts.

	Jan
0
12/8/2005 11:04:44 AM
Jan Vorbr=FCggen wrote:
>> I haven't switched.  I probably will hold off as long as possible.  If=
=20
>> they come out with an integrated CVF-like product rather than a half=20
>> measure, I will buy it within seconds of becoming aware of it=20
>> (multiple copies). =20
>=20
>=20
> I don't understand - just because you have to buy the IDE seperately, a=
s
> MS insisted that the bundled variant would cost as much as the unbundle=
d
> variant, you're not even considering the product? Surely it's total pur=
-
> chase price that counts.
>=20
>     Jan

It is partly a matter of principle.  The prior product was complete, the =

replacement product is not.  It doesn't even justify the "visual" name=20
because it is incomplete.  It isn't an "integrated" product.=20
Installation horror stories abound.  I shouldn't have to perform two=20
separate installations, carefully, manually adjusting any prior=20
installation of MSVC to make sure the installation goes smoothly.  It is =

simply unacceptable to downgrade a product like that.  Give it back to=20
HP/Compaq if you're not going to do it right.

--=20

Gary Scott
mailto:garyscott@ev1.net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

Why are there two?  God only knows.


If you want to do the impossible, don't hire an expert because he knows=20
it can't be done.

-- Henry Ford
0
garyscott (569)
12/9/2005 3:19:23 AM
In article <3vqghmF174cb3U1@individual.net>,
Jan Vorbr�ggen  <jvorbrueggen-not@mediasec.de> wrote:

>> Intel's checking for the 'GenuineIntel' CPU identifier string and
>> reducing performance if it isn't found is definitely evidence of 'bad
>> faith' on their part, so that may inform your decision. 
>
>Nonsense. Ever heard of product liability? This is a US company, and they
>need to take such things seriously.

You mean that the 99.99% of software written by US companies that
doesn't check for "GenuineIntel(tm)" is a legal liability? Wow, I
learn something new every day.

-- greg


0
lindahl (697)
12/9/2005 3:20:29 AM
> You mean that the 99.99% of software written by US companies that
> doesn't check for "GenuineIntel(tm)" is a legal liability? Wow, I
> learn something new every day.

Glad you do 8-).

But we were talking about using software that had processor-specific code,
and declaring support for using that code when you (i.e., Intel) didn't
and couldn't know whether the processor it would run on had implemented
those extensions correctly (i.e., with the same bugs as Intel's own imple-
mentation). An overreaction? Quite possibly, but perhaps you've not heard
of that famous product liability suit in general aviation some decades ago?

	Jan
0
12/9/2005 8:57:51 AM
 > It is  simply unacceptable to downgrade a product like that.  Give it
 > back to HP/Compaq if you're not going to do it right.

As I have understood it, Intel didn't have a choice - Microsoft simply
didn't offer the same deal DEC had made to them. And giving it back wasn't
on the cards, I'd say.

	Jan
0
12/9/2005 9:01:40 AM
Jan Vorbr=FCggen wrote:
>  > It is  simply unacceptable to downgrade a product like that.  Give i=
t
>  > back to HP/Compaq if you're not going to do it right.
>=20
> As I have understood it, Intel didn't have a choice - Microsoft simply
> didn't offer the same deal DEC had made to them. And giving it back was=
n't
> on the cards, I'd say.
>=20
>     Jan
MS didn't offer the exact same ADVANTAGED deal, but they did offer the=20
same deal as they offered Lahey and Salford which both produced a more=20
complete product.  I don't have a problem if Intel wants to offer as an=20
option, an incomplete product such as their existing one.  Just at least =

give me an option of a semi-complete one without requirement to buy a=20
competitor's compiler and install them separately, in the correct order=20
(I note many reported problems with installation on the forum), ensuring =

that I have the exact version that they integrated with, since MS may=20
not even be offering that one any longer.

--=20

Gary Scott
mailto:garyscott@ev1.net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

Why are there two?  God only knows.


If you want to do the impossible, don't hire an expert because he knows=20
it can't be done.

-- Henry Ford
0
garyscott (569)
12/10/2005 2:18:16 AM
> MS didn't offer the exact same ADVANTAGED deal, but they did offer the 
> same deal as they offered Lahey and Salford which both produced a more 
> complete product.  I don't have a problem if Intel wants to offer as an 
> option, an incomplete product such as their existing one.  Just at least 
> give me an option of a semi-complete one without requirement to buy a 
> competitor's compiler and install them separately,

The rationale, AIUI, is that many a customer already owned the MS IDE,
whether with the C compiler or not (and note that there is no MS "compe-
titor's compiler" with regard to Fortran). Thus, the solution Intel chose
will save at least some of their customers money.

Now, if there are installation or versioning problems, that's clearly a
quality of implementation issue that should be resolved - but the general
approach is fine with me. Indeed, most of the time I have used DVF, I had
no need for the IDE.

	Jan
0
12/12/2005 9:55:38 AM
Jan Vorbr�ggen wrote:
>> MS didn't offer the exact same ADVANTAGED deal, but they did offer the 
>> same deal as they offered Lahey and Salford which both produced a more 
>> complete product.  I don't have a problem if Intel wants to offer as 
>> an option, an incomplete product such as their existing one.  Just at 
>> least give me an option of a semi-complete one without requirement to 
>> buy a competitor's compiler and install them separately,
> 
> 
> The rationale, AIUI, is that many a customer already owned the MS IDE,
> whether with the C compiler or not (and note that there is no MS "compe-
> titor's compiler" with regard to Fortran). Thus, the solution Intel chose
> will save at least some of their customers money.
> 
Some old horses are being beat on here, with distortion of the old 
facts, to the extent they could be read on line.  IMHO, it would have 
been laudible if Lahey and Salford had been able to offer native code 
debugging and profiling, and had achieved as much success with their 
Windows products of the last 4 years as they did prior to .NET.  AFAIK, 
no one has been able to support 64-bit Windows with what the poster 
above refers to as a "complete product," nor 32-bit Windows with a 
product combining the advantages of the various products which have been 
available.
How is it that the upper poster above intended to use Lahey or Salford 
CLR compilers without first installing .NET separately?
0
tprince (584)
12/12/2005 2:04:27 PM
In article <3vsv7uF16lgvdU1@individual.net>,
>
>But we were talking about using software that had processor-specific code,
>and declaring support for using that code when you (i.e., Intel) didn't
>and couldn't know whether the processor it would run on had implemented
>those extensions correctly (i.e., with the same bugs as Intel's own imple-
>mentation). An overreaction? Quite possibly, but perhaps you've not heard
>of that famous product liability suit in general aviation some decades ago?

But surely that argument holds true for the generic ia32 ABI as well? If
your argument held water, then the only 'safe' thing for Intel to do
would be to strengthen the check such that the code compiled with the
compiler would not run on any non-Intel chip at all.

The extensions that Intel disables include SSE, which (as I understand
it) AMD directly licensed from Intel, warts and all. The 'we might be
liable' argument surely doesn't hold there. In any case, if any problems
ensued from code running incorrectly on an AMD chip, surely the
liability would be on AMD not Intel.

-- 
Mark Mackey   http://www.swallowtail.org/
code code code code code code code code code code code code code bug code co
de code code code bug code code code code code code code code code code code
code code code code code code code code code code code code code code code c
0
markm13 (51)
12/13/2005 3:46:21 PM
Jan Vorbr=FCggen wrote:
>> MS didn't offer the exact same ADVANTAGED deal, but they did offer the=
=20
>> same deal as they offered Lahey and Salford which both produced a more=
=20
>> complete product.  I don't have a problem if Intel wants to offer as=20
>> an option, an incomplete product such as their existing one.  Just at =

>> least give me an option of a semi-complete one without requirement to =

>> buy a competitor's compiler and install them separately,
>=20
>=20
> The rationale, AIUI, is that many a customer already owned the MS IDE,
> whether with the C compiler or not (and note that there is no MS "compe=
-
> titor's compiler" with regard to Fortran). Thus, the solution Intel cho=
se
> will save at least some of their customers money.
>=20
> Now, if there are installation or versioning problems, that's clearly a=

> quality of implementation issue that should be resolved - but the gener=
al
> approach is fine with me. Indeed, most of the time I have used DVF, I h=
ad
> no need for the IDE.

I understand that some use it that way.  I can't help but believe that=20
is a tiny minority.  The project management facilities in VS are quite=20
good.  I got tired of make files and personal macros years ago.

>=20
>     Jan


--=20

Gary Scott
mailto:garyscott@ev1.net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

Why are there two?  God only knows.


If you want to do the impossible, don't hire an expert because he knows=20
it can't be done.

-- Henry Ford
0
garyscott (569)
12/14/2005 2:11:06 AM
Gary L. Scott <garyscott@ev1.net> wrote:

> Jan Vorbr�ggen wrote:

> > most of the time I have used DVF, I had
> > no need for the IDE.
> 
> I understand that some use it that way.  I can't help but believe that
> is a tiny minority.  The project management facilities in VS are quite
> good.  I got tired of make files and personal macros years ago.

I've never once used the project manaagement facilities, for one huge
reason - portability. My code has to work on other platforms. In fact,
I'm almost always developing on other platforms in the first place and
using DVF just to do a port to Windows. As such, I've already got all
the Makefiles and such.... which do tend to need tweaking for a Windows
port, but at least I've got the base to start from.

And since I pay attention to code portability in the first place, I can
usually get a port done in less time than it would take me to figure out
how to set up a project and otherwise use the fancy IDE.

While there are certainly plenty of people who don't have the same
portability issues, I also know for sure that I'm not the only person
who does.

I personally find Makefile syntax to be abysmal. I won't go into my full
rank on it, and I will try to keep my language under control in this, my
only mention of my opinion about a syntax that you can't parse by
looking at either on the screen or a printout, because blanks vs tabs
matter. But one can do Makefiles pretty portably, anyway, much more so
than any currently available IDE; that turns out to be a pretty major
factor for me.

-- 
Richard Maine                     | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov            |       -- Mark Twain
0
nospam47 (9748)
12/14/2005 4:59:29 PM
Richard E Maine wrote:
<snip>

  But one can do Makefiles pretty portably, anyway, much more so
> than any currently available IDE; that turns out to be a pretty major
> factor for me.
> 
Maybe not "much more so". Photran is available
on a pretty wide variety of systems.

And: you can use your own Makefile to build
under Photran, so this implies that you can do
anything in Photran that you can do without it
(with regard to make files).

-- 
Walt Brainerd         +1-877-355-6640 (voice & fax)
The Fortran Company   +1-520-760-1397 (outside USA)
6025 N. Wilmot Road   walt@fortran.com
Tucson, AZ 85750 USA  http://www.fortran.com
0
walt5852 (198)
12/15/2005 12:35:30 AM
Richard E Maine wrote:
<snip>

  But one can do Makefiles pretty portably, anyway, much more so
> than any currently available IDE; that turns out to be a pretty major
> factor for me.
> 
Maybe not "much more so". Photran is available
on a pretty wide variety of systems.

And: you can use your own Makefile to build
under Photran, so this implies that you can do
anything in Photran that you can do without it
(with regard to make files).

-- 
Walt Brainerd         +1-877-355-6640 (voice & fax)
The Fortran Company   +1-520-760-1397 (outside USA)
6025 N. Wilmot Road   walt@fortran.com
Tucson, AZ 85750 USA  http://www.fortran.com
0
walt5852 (198)
12/15/2005 12:35:44 AM
Richard E Maine wrote:
<snip>

  But one can do Makefiles pretty portably, anyway, much more so
> than any currently available IDE; that turns out to be a pretty major
> factor for me.
> 
Maybe not "much more so". Photran is available
on a pretty wide variety of systems.

And: you can use your own Makefile to build
under Photran, so this implies that you can do
anything in Photran that you can do without it
(with regard to make files).

-- 
Walt Brainerd         +1-877-355-6640 (voice & fax)
The Fortran Company   +1-520-760-1397 (outside USA)
6025 N. Wilmot Road   walt@fortran.com
Tucson, AZ 85750 USA  http://www.fortran.com
0
walt5852 (198)
12/15/2005 12:36:08 AM
Richard E Maine wrote:
> Gary L. Scott <garyscott@ev1.net> wrote:
>=20
>=20
>>Jan Vorbr=FCggen wrote:
>=20
>=20
>>>most of the time I have used DVF, I had
>>>no need for the IDE.
>>
>>I understand that some use it that way.  I can't help but believe that
>>is a tiny minority.  The project management facilities in VS are quite
>>good.  I got tired of make files and personal macros years ago.
>=20
>=20
> I've never once used the project manaagement facilities, for one huge
> reason - portability. My code has to work on other platforms. In fact,
> I'm almost always developing on other platforms in the first place and
> using DVF just to do a port to Windows. As such, I've already got all
> the Makefiles and such.... which do tend to need tweaking for a Windows=

> port, but at least I've got the base to start from.
>=20
> And since I pay attention to code portability in the first place, I can=

> usually get a port done in less time than it would take me to figure ou=
t
> how to set up a project and otherwise use the fancy IDE.
>=20
> While there are certainly plenty of people who don't have the same
> portability issues, I also know for sure that I'm not the only person
> who does.
>=20
> I personally find Makefile syntax to be abysmal. I won't go into my ful=
l
> rank on it, and I will try to keep my language under control in this, m=
y
> only mention of my opinion about a syntax that you can't parse by
> looking at either on the screen or a printout, because blanks vs tabs
> matter. But one can do Makefiles pretty portably, anyway, much more so
> than any currently available IDE; that turns out to be a pretty major
> factor for me.
>=20
True.  It would be relatively easy to write a fairly (native OS, not a=20
browser plugin) portable IDE with GINO.  I'm a little surprised that=20
several other important portable tools (icon editors, font editors, an=20
object library manager, etc.) aren't available for any of the graphics=20
packages (they were all available on the mainframe as a standard part of =

the graphics package).

I'd be ecstatic if a "standard interpreter" (not just a limited=20
preprocessor), was associated with Fortran.  REXX would be nice, but I=20
could hold my nose and live with Perl.

--=20

Gary Scott
mailto:garyscott@ev1.net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

Why are there two?  God only knows.


If you want to do the impossible, don't hire an expert because he knows=20
it can't be done.

-- Henry Ford
0
garyscott (569)
12/15/2005 2:19:17 AM
"Gary L. Scott" wrote:
> 
> complete product.  I don't have a problem if Intel wants to offer as an
> option, an incomplete product such as their existing one.  Just at least
> give me an option of a semi-complete one without requirement to buy a
> competitor's compiler and install them separately, in the correct order

If not a problem for you, it clearly *IS* a problem for Intel. When
marketing as an upgrade to CVF failed to produce they cooked up a
scheme* to eliminate it. Be as it may, it's CVF users they're after
(with *NOTHING* to offer), and evidently users are responding in kind
burying Intel compiler ambitions well before the Feds nail their coffin.

---
* Imagine the IDE Intel could have built in this four years with the
monies they paid HP to *fix* the market for its rejected dos compiler.

0
kia (104)
12/24/2005 12:13:49 AM
kia wrote:
> "Gary L. Scott" wrote:
> >
> > complete product.  I don't have a problem if Intel wants to offer as an
> > option, an incomplete product such as their existing one.  Just at least
> > give me an option of a semi-complete one without requirement to buy a
> > competitor's compiler and install them separately, in the correct order
>
> If not a problem for you, it clearly *IS* a problem for Intel. When
> marketing as an upgrade to CVF failed to produce they cooked up a
> scheme* to eliminate it. Be as it may, it's CVF users they're after
> (with *NOTHING* to offer), and evidently users are responding in kind
> burying Intel compiler ambitions well before the Feds nail their coffin.
>

This is a bit revisionist (and possibly a little paranoid).  I believe
that Compaq was always supposed to terminate CVF at some point.  I've
not seen any marketing data so I can't say anything about whether IVF
has been a comparative failure or not.  It certainly has been with me,
but there appears to be a lot of people out there that are happy with a
half baked product.

> ---
> * Imagine the IDE Intel could have built in this four years with the
> monies they paid HP to *fix* the market for its rejected dos compiler.

Yes, they certainly could have developed their own IDE and eliminated
dependence on MSVC components as well in that time.  I've heard no
rumors of any change so they must be content with the market share
they've achieved as-is.

0
garyscott (569)
12/27/2005 4:51:53 AM
kia wrote:
> "Gary L. Scott" wrote:
> >
> > complete product.  I don't have a problem if Intel wants to offer as an
> > option, an incomplete product such as their existing one.  Just at least
> > give me an option of a semi-complete one without requirement to buy a
> > competitor's compiler and install them separately, in the correct order
>
> If not a problem for you, it clearly *IS* a problem for Intel. When
> marketing as an upgrade to CVF failed to produce they cooked up a
> scheme* to eliminate it. Be as it may, it's CVF users they're after
> (with *NOTHING* to offer), and evidently users are responding in kind
> burying Intel compiler ambitions well before the Feds nail their coffin.
>

This is a bit revisionist (and possibly a little paranoid).  I believe
that Compaq was always supposed to terminate CVF at some point.  I've
not seen any marketing data so I can't say anything about whether IVF
has been a comparative failure or not.  It certainly has been with me,
but there appears to be a lot of people out there that are happy with a
half baked product.

> ---
> * Imagine the IDE Intel could have built in this four years with the
> monies they paid HP to *fix* the market for its rejected dos compiler.

Yes, they certainly could have developed their own IDE and eliminated
dependence on MSVC components as well in that time.  I've heard no
rumors of any change so they must be content with the market share
they've achieved as-is.

0
garyscott (569)
12/27/2005 5:00:17 AM
I just got a copy of ifort 9.0 for Windows.  It compiled our code just 
fine.  However, at runtime we started getting behavior differences.  The 
most prominent has to do with an INQUIRE with file=dir.  This worked 
just fine with CVF 6.x.  It also works with Sun and PGI Linux.

I thought I used a trial version of Intel 8.1 and the INQUIRE with 
file=dir was not a problem.

I still need to do more testing with ifort 9.0.

MikeS

NN wrote:
> Hi,
> I use the latest version of Compaq Visual Fortran on a Windows system. CVF 
> development is being discontinued as of the end of this year. They offer an 
> upgrade to Intel Visual Fortran 9.0. Any thoughts on whether this is 
> advisable/desirable/necessary would be highly appreciated. Does anybody have 
> experiences going that route already?
> Thanks a lot.
> --hh
0
mws116 (5)
1/20/2006 2:44:37 AM
"m sutton" <mws116@usa.com> wrote in message
news:p8Yzf.732$2O6.461@newssvr12.news.prodigy.com...
> I just got a copy of ifort 9.0 for Windows.  It compiled our code just
> fine.  However, at runtime we started getting behavior differences.  The
> most prominent has to do with an INQUIRE with file=dir.  This worked
> just fine with CVF 6.x.  It also works with Sun and PGI Linux.
>
> I thought I used a trial version of Intel 8.1 and the INQUIRE with
> file=dir was not a problem.
>
> I still need to do more testing with ifort 9.0.
>
> MikeS
>
> NN wrote:
> > Hi,
> > I use the latest version of Compaq Visual Fortran on a Windows system.
CVF
> > development is being discontinued as of the end of this year. They
offer an
> > upgrade to Intel Visual Fortran 9.0. Any thoughts on whether this is
> > advisable/desirable/necessary would be highly appreciated. Does anybody
have
> > experiences going that route already?
> > Thanks a lot.
> > --hh

Intel Fortran is a downgrade wrt CVF. Sure, it's a supported compiler but
unlike DVF and CVF, it doesn't have the cooperative support of Microsoft in
bringing a viable product to the Windows market. If all you want to do is
build dos-like apps, stick to unix, get the freebee Intel compiler for that
os, and you're off to the races.


0
1/20/2006 7:54:25 AM
"m sutton" <mws116@usa.com> wrote in message
news:p8Yzf.732$2O6.461@newssvr12.news.prodigy.com...
> I just got a copy of ifort 9.0 for Windows.  It compiled our code just
> fine.  However, at runtime we started getting behavior differences.  The
> most prominent has to do with an INQUIRE with file=dir.  This worked
> just fine with CVF 6.x.  It also works with Sun and PGI Linux.
>
> I thought I used a trial version of Intel 8.1 and the INQUIRE with
> file=dir was not a problem.
>
> I still need to do more testing with ifort 9.0.
>
> MikeS
>


Yes this bit me too. INQUIRE with FILE=name,   name has to be a file and for
a directory one has to write INQUIRE with DIRECTORY=name. Fortunately we
have just a couple of routines which test for existence of a file/directory
and these are called throughout the code so a couple of changes and all the
code was ok.
I also had some minor issues with what had once in CVF been "include <file>"
which came after impicit none statement but now is a "use <file>" which has
to go before the impicit none.
Otherwise the Fortran transfer was generally quite painless.
Now the upgrade of the C/C++ compiler and Visual Studio IDE to .NET and
language separation into separate C/C++ and Fortran projects was a different
matter :-(

Les






0
l.neilson1 (35)
1/20/2006 10:10:25 AM
On Fri, 20 Jan 2006 02:44:37 GMT, m sutton <mws116@usa.com> wrote:

>I just got a copy of ifort 9.0 for Windows.  It compiled our code just 
>fine.  However, at runtime we started getting behavior differences.  The 
>most prominent has to do with an INQUIRE with file=dir.  This worked 
>just fine with CVF 6.x.  It also works with Sun and PGI Linux.

There's been discussion in this group before about the behavior of INQUIRE
with directories.  Since you can't OPEN a directory, the standard doesn't say
that INQUIRE by file should work on it and the results of doing so are
non-portable.  ifort 9.0 added two new keywords to INQUIRE for this purpose.

If you have other issues with Intel Fortran, please bring them to our
attention at Intel Premier Support (see link below) so that we can help you.
Another option is our user forum (link also below).

Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
  http://softwareforums.intel.com/
Intel Fortran Support
  http://developer.intel.com/software/products/support/
0
1/20/2006 2:44:28 PM
Les wrote:
> "m sutton" <mws116@usa.com> wrote in message
> news:p8Yzf.732$2O6.461@newssvr12.news.prodigy.com...
> 
>>I just got a copy of ifort 9.0 for Windows.  It compiled our code just
>>fine.  However, at runtime we started getting behavior differences.  The
>>most prominent has to do with an INQUIRE with file=dir.  This worked
>>just fine with CVF 6.x.  It also works with Sun and PGI Linux.
>>
>>I thought I used a trial version of Intel 8.1 and the INQUIRE with
>>file=dir was not a problem.
>>
>>I still need to do more testing with ifort 9.0.
>>
>>MikeS
>>
> 
> 
> 
> Yes this bit me too. INQUIRE with FILE=name,   name has to be a file and for
> a directory one has to write INQUIRE with DIRECTORY=name. Fortunately we
> have just a couple of routines which test for existence of a file/directory
> and these are called throughout the code so a couple of changes and all the
> code was ok.
> I also had some minor issues with what had once in CVF been "include <file>"
> which came after impicit none statement but now is a "use <file>" which has
> to go before the impicit none.
> Otherwise the Fortran transfer was generally quite painless.
> Now the upgrade of the C/C++ compiler and Visual Studio IDE to .NET and
> language separation into separate C/C++ and Fortran projects was a different
> matter :-(
> 
> Les

I wouldn't be too worried about it if I didn't have to support users 
with a varity of compilers:  CVF, PGI, Sun, HP-UX, SGI, Intel 8.x & 9.x. 
  My software has to be portable.  Many of my users actually recompile 
the code for themselves.

Just today, I submitted two issues regarding Intel Fortran 9.0. I have 
one file that compiles in 1 second with CVF and in 30 seconds with 
Intel.  So, I saw that there was 9.0.028 patch out there.  I loaded that 
with even worse results.  I was now getting an internal compiler error 
in a different file.  Arrrggg!

My initial impressions of Intel 9.0 are very bleak.

I have also had to recode part of my software to workaround bugs PGI 
(Linux) introduced into their 6.x compilers.  An entry point was causing 
some sort of data corruption elsewhere.

My attitude toward the compiler companies is getting bad.  It seems that 
I have to spend many hours to determine that it really is a compiler bug 
and not some stupid coding on my part.

MikeS
0
mws116 (5)
1/21/2006 12:37:40 AM
Steve Lionel wrote:
> On Fri, 20 Jan 2006 02:44:37 GMT, m sutton <mws116@usa.com> wrote:
> 
> 
>>I just got a copy of ifort 9.0 for Windows.  It compiled our code just 
>>fine.  However, at runtime we started getting behavior differences.  The 
>>most prominent has to do with an INQUIRE with file=dir.  This worked 
>>just fine with CVF 6.x.  It also works with Sun and PGI Linux.
> 
> 
> There's been discussion in this group before about the behavior of INQUIRE
> with directories.  Since you can't OPEN a directory, the standard doesn't say
> that INQUIRE by file should work on it and the results of doing so are
> non-portable.  ifort 9.0 added two new keywords to INQUIRE for this purpose.
> 
> If you have other issues with Intel Fortran, please bring them to our
> attention at Intel Premier Support (see link below) so that we can help you.
> Another option is our user forum (link also below).
> 
> Steve Lionel
> Software Products Division
> Intel Corporation
> Nashua, NH

I did find the new INQUIRE options, but are non-standard.  This is a 
pretty drastic change in behavior. I do agree that the new DIRECTORY= 
option is more explicit.

Backward compatibility is a common practice; removing it in this case 
was a poor idea.  There isn't even a compiler switch that can be thrown 
to say hey, use the old way for INQUIRE.  I'm now facing the prospect of 
adding pre-processor stuff just to deal with the differing behavior of 
INQUIRE for Intel 9.0 and Intel 8.x.  Fortran is *not* built around 
pre-processor directives like C/C++.

MikeS
0
mws116 (5)
1/21/2006 1:17:29 AM
> There's been discussion in this group before about the behavior of INQUIRE
> with directories.  Since you can't OPEN a directory, [...]

Hmmm...why would that necessarily be the case? I could well imagine an imple-
mentation that allowed me to OPEN a directory as FORMATTED SEQUENTIAL, and
when reading from that unit number returned (at least) the file names in that
directory in some order. Would that be non-conforming to the standard in any
way?

	Jan
0
1/23/2006 1:40:12 PM
Jan Vorbr�ggen wrote:
>>There's been discussion in this group before about the behavior of INQUIRE
>>with directories.  Since you can't OPEN a directory, [...]
> 
> Hmmm...why would that necessarily be the case? I could well imagine an imple-
> mentation that allowed me to OPEN a directory as FORMATTED SEQUENTIAL, and
> when reading from that unit number returned (at least) the file names in that
> directory in some order. Would that be non-conforming to the standard in any
> way?

Given the standard's extreme laxness is specifying what a "file" is and 
what data one gets from it, I can't imagine that it would be at all 
non-conforming.

It does, in fact, seem like a fairly useful way of doing things.

- Brooks


-- 
The "bmoses-nospam" address is valid; no unmunging needed.
0
bmoses-nospam (1266)
1/23/2006 9:30:11 PM
Reply: