version 71 versus version 80

[viper]

I have both version 71 and version 8.0, but i still feel comfortable with version 71. I feel that version 71 is more mature and stable for large codes with lots of advanced features than version 8.0. I was wondering how many other users feel the same way. Simple things that work well in version 71 have to be hacked in version 8.0
1) v8.0 cannot determine if a function is external or internal unless you specify external
2)problem with structures and array bounds. Usually leads to segmentation fault
3)the -gui debugger does not work in rh9. It comes up, but there is no test.

thanks

[Steven_L_Intel1]

The initial 8.0 release was a little shaky, but it is alot better now, and better in many ways than 7.1.

I don't know of general problems along the lines you mention.

[viper]

Steve,
Thanks for the input. Its just that i am nervous with anything new and when i tested the 1st release of v80 on some research codes the results were disappointing and so i played it safe and reverted back to v71 on linux platforms.
ash

[Steven_L_Intel1]

Please feel free to try 8.0 again - 8.0.047 is current on Linux, I think. Let us know if you encounter problems.

[Keith_R_]

Steve lionel is correct that 8.0 was a big step backwards. Despite
all the subsequent fixes, it is still showing some immaturity. Early
versions used to crash on USEs of large modules which themselves USEd
other modules.
In fact the last two patches have reintroduced "internal compiler error"
crashes which I wasn't seeing before, and still haven't managed to boil down to a test case.


Your third issue, the text (I guess this is what you meant) missing from
the -gui debugger pane is something I also see on Mandrake (9.1, 9.2, 10.0).
I have a Premier Support issue active on this one.

[Steven_L_Intel1]

I certainly did not say that 8.0 was a "big step backwards". It was a major leap forwards in many areas, including support of the full Fortran language, as well as features and extensions long demanded by Intel users.

I would urge anyone who is still having problems to submit a report to Intel Premier Support. If you have trouble isolating a test case, just send us the whole thing and we'll do the work.

[Keith_R_]

Apologies. My posting was badly expressed and conflated Steve's opinion
with my own.

What I meant to say was that in *my* opinion 8.0 was a
step backwards in terms of robustness and stability, in that early versions
broke (ie crash or otherwise fail) on code which worked fine under 7.1.

[pilla]

I am experiencing some segmentation faults with the 178.galgel benchmark from SPEC2000 fp and IFC 8.0. Does somebody can confirm that this is a compiler issue and that downgrading to 7.1 should fix it?

Anyway, I'm now downloading 7.1 to test it.

[Steven_L_Intel1]

Which version 8.0? I know there have been some issues with galgel over time, but am not aware of anything current.

[Intel_C_Intel]

I have been trying to upgrade my cluster to use the 8.0
compilers. I have been very excited about some of the
changes included in v8.0 including the front-end parser,
support for -convert big_endian, support for -zero, and
the 30% speed increase for MM5.

I needed the new front end parser to be able to compile
WRF. Version 7.1 didn't like the 'overly' overloaded operators
in Fortran 90.

I do have one big problem though. I have a code that
cannot produce consistent results. Each time I run it,
it produces slightly different results. This does not
happen under v7.1, but it does under v8.0. I also
changed the OS though, so I cannot blame it solely on
the compiler yet. I am working with Premier on this,
but it isn't easy to create a small test

I have users that have asked for v8.0 because they aren't
having any problems with the compiler and their codes run
30% faster now (not MM5, but another code).

When we go production on this OS base, unless I solve the
problem with inconsistent results, I will make 7.1 the default
but have 8.0 installed for those who want it.

Crig

[Steven_L_Intel1]

It seems likely that your program with the inconsistent results is referencing an uninitialized variable, or has a "shape mismatch" error in an array operation. Unfortunately, 8.0 doesn't help you detect these (and 7.1's detection is unreliable.) 8.0 puts temporary copies of arrays on the stack, which can lead to unpredictable values for uninitialized elements.

[Intel_C_Intel]

We have determined the problem with our code
was caused by the kernel and not the compiler.
We swapped out the Fedora Core 1 kernel with
a stock 2.4.26 kernel and we get consistent
answers now.

Craig

[Steven_L_Intel1]

This sort of problem hurts adoption of Linux. There are just too many combinations of kernel, glibc, pthreads, etc. out there, changing inconsistently and often breaking binary compatibility as new versions of one or the other is released.

I'm glad you solved the problem, however. Intel does not list Fedora as a validated distribution. It seems to work for many people, but you have apparently found a case where it doesn't.