[petsc-users] Intel Internal compiler error: segmentation violation signal raised

[TAY wee-beng]

Hi Barry,

Thanks for the advice. It took me a while to compile and build 
successfully with gfortran due to the stricter rules and entirely 
different options.

But the most problematic thing was that most clusters I work with use 
old versions of gcc/gfortran. With the gcc/gfortran tied to the MPI, it 
seems that I can't just update myself to use the new version, or can I?

Also, can anyone recommend options to get optimized results in gfortran?

I'm using :

-fno-signed-zeros  -fno-trapping-math -ffast-math -march=native 
-funroll-loops -ffree-line-length-none -O3

Thank you.

Yours sincerely,

TAY wee-beng

On 8/4/2014 8:04 PM, Barry Smith wrote:
>     You should never get yourself in a position where you “have to” use a particular compiler. Strive to have portable makefiles that don’t depend on the compiler (with PETSc makefiles this is easy) and to have portable code that doesn’t depend on the compiler. Then switching between compilers takes literally a couple minutes. It is extremely counter productive to do nothing for days because the compiler you are using doesn’t work under a particular circumstance. It really isn’t hard to set things up so changing compilers is easy.
>
>     Barry
>
>
> On Apr 8, 2014, at 6:39 AM, Jed Brown <jed at jedbrown.org> wrote:
>
>> TAY wee-beng <zonexo at gmail.com> writes:
>>> My impression was intel is mostly faster. However, does it apply to
>>> gfortran too? Is it also faster for a lot of code than Intel fortran?
>>> I'll give it a go if it's so. However, I remember changing a no. of
>>> options to build and in the end, it was slower. that's a few yrs ago though.
>> It varies, but usually not by a large factor and a broken compiler takes
>> infinitely long to produce correct answers.  Report the bug to Intel,
>> use gfortran (latest version), and get on with your business.  If/when
>> Intel fixes the bug, if you still have a license, try ifort again.