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

[TAY wee-beng]

Hi,

I encountered the error below when compiling my code using intel fortran:

/tmp/ifortlPEDlK.i90: catastrophic error: **Internal compiler error:
segmentation violation signal raised** Please report this error along
with the circumstances in which it occurred in a Software Problem
Report. Note: File and line given may not be explicit cause of this error.

In the end, I realised that it is due to using *petsc.h90*:

module PETSc_solvers

use set_matrix

...

implicit none

contains

subroutine semi_momentum_simple_xyz(du,dv,dw)

*#include "finclude/petsc.h90"*

integer :: i,j,k,ijk,ierr,II !,ro...

If I use :

*#include "finclude/petsc.h"

or
*
*#include "finclude/petscdmda.h90"*
*#include "finclude/petscksp.h90"*

Then there is no problem.

May I know why this is happening?

Although I can now compile and build successfully, is this the right way
to go?

[TAY wee-beng]

Sorry I realised that

*#include "finclude/petscdmda.h90"*
*#include "finclude/petscksp.h90"*

also gave errors:

*//home/wtay/Lib/petsc-3.4.4_shared_rel/include/finclude/ftn-custom/petscdmda.h90(10):
error #5082: Syntax error, found ',' when expecting one of: ( % [ : . =
=>/**/
/**/ PetscInt, pointer :: array(:)/**/
/**/------------------^/**/
/**//home/wtay/Lib/petsc-3.4.4_shared_rel/include/finclude/ftn-custom/petscdmda.h90(10):
error #5082: Syntax error, found END-OF-STATEMENT when expecting one of:
) ,/**/
/**/ PetscInt, pointer :: array(:)/**/
/**/---------------------------------------^/**/
/**//home/wtay/Lib/petsc-3.4.4_shared_rel/include/finclude/ftn-custom/petscdmda.h90(11):
error #5082: Syntax error, found IDENTIFIER 'N' when expecting one of: (
% [ : . = =>/**/
/**/ PetscInt n/**/
/**/--------------------^/**/
/**//home/wtay/Lib/petsc-3.4.4_shared_rel/include/finclude/ftn-custom/petscdmda.h90(12):
error #5082: Syntax error, found IDENTIFIER 'IERR' when expecting one
of: ( % [ : . = =>/**/
/**/ PetscErrorCode ierr/**/
/**/-------------------------^/**/
/**//home/wtay/Lib/petsc-3.4.4_shared_rel/include/finclude/ftn-custom/petscdmda.h90(13):
error #5082: Syntax error, found IDENTIFIER 'V' when expecting one of: (
% [ : . = =>/*

Thank you

Yours sincerely,

TAY wee-beng

Post by TAY wee-beng
Hi,
segmentation violation signal raised** Please report this error along
with the circumstances in which it occurred in a Software Problem
Report. Note: File and line given may not be explicit cause of this error.
module PETSc_solvers
use set_matrix
...
implicit none
contains
subroutine semi_momentum_simple_xyz(du,dv,dw)
*#include "finclude/petsc.h90"*
integer :: i,j,k,ijk,ierr,II !,ro...
*#include "finclude/petsc.h"
or
*
*#include "finclude/petscdmda.h90"*
*#include "finclude/petscksp.h90"*
Then there is no problem.
May I know why this is happening?
Although I can now compile and build successfully, is this the right
way to go?
--
Thank you
Yours sincerely,
TAY wee-beng

[Matthew Knepley]

How about just including petsc.h90 so you get everything.

Thanks,

Matt

Post by TAY wee-beng
Sorry I realised that
*#include "finclude/petscdmda.h90"*
*#include "finclude/petscksp.h90"*
error #5082: Syntax error, found ',' when expecting one of: ( % [ : . = =>*
* PetscInt, pointer :: array(:)*
*------------------^*
error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: )
,*
* PetscInt, pointer :: array(:)*
*---------------------------------------^*
error #5082: Syntax error, found IDENTIFIER 'N' when expecting one of: ( %
[ : . = =>*
* PetscInt n*
*--------------------^*
error #5082: Syntax error, found IDENTIFIER 'IERR' when expecting one of: (
% [ : . = =>*
* PetscErrorCode ierr*
*-------------------------^*
error #5082: Syntax error, found IDENTIFIER 'V' when expecting one of: ( %
[ : . = =>*
Thank you
Yours sincerely,
TAY wee-beng
Hi,
segmentation violation signal raised** Please report this error along with
File and line given may not be explicit cause of this error.
module PETSc_solvers
use set_matrix
...
implicit none
contains
subroutine semi_momentum_simple_xyz(du,dv,dw)
*#include "finclude/petsc.h90"*
integer :: i,j,k,ijk,ierr,II !,ro...
*#include "finclude/petsc.h" or *
*#include "finclude/petscdmda.h90"*
*#include "finclude/petscksp.h90"*
Then there is no problem.
May I know why this is happening?
Although I can now compile and build successfully, is this the right way
to go?
--
Thank you
Yours sincerely,
TAY wee-beng

[TAY wee-beng]

Post by Matthew Knepley
How about just including petsc.h90 so you get everything.
Thanks,
Matt

Sorry this is my 2nd email. See below for the 1st email. Using petsc.h90
gave the error "... segmentation violation signal raised ...."

Post by Matthew Knepley
Sorry I realised that
*#include "finclude/petscdmda.h90"*
*#include "finclude/petscksp.h90"*
error #5082: Syntax error, found ',' when expecting one of: ( % [
: . = =>/**/
/**/ PetscInt, pointer :: array(:)/**/
/**/------------------^/**/
error #5082: Syntax error, found END-OF-STATEMENT when expecting
one of: ) ,/**/
/**/ PetscInt, pointer :: array(:)/**/
/**/---------------------------------------^/**/
error #5082: Syntax error, found IDENTIFIER 'N' when expecting one
of: ( % [ : . = =>/**/
/**/ PetscInt n/**/
/**/--------------------^/**/
error #5082: Syntax error, found IDENTIFIER 'IERR' when expecting
one of: ( % [ : . = =>/**/
/**/ PetscErrorCode ierr/**/
/**/-------------------------^/**/
error #5082: Syntax error, found IDENTIFIER 'V' when expecting one
of: ( % [ : . = =>/*
Thank you
Yours sincerely,
TAY wee-beng

Post by TAY wee-beng
Hi,
/tmp/ifortlPEDlK.i90: catastrophic error: **Internal compiler
error: segmentation violation signal raised** Please report this
error along with the circumstances in which it occurred in a
Software Problem Report. Note: File and line given may not be
explicit cause of this error.
module PETSc_solvers
use set_matrix
...
implicit none
contains
subroutine semi_momentum_simple_xyz(du,dv,dw)
*#include "finclude/petsc.h90"*
integer :: i,j,k,ijk,ierr,II !,ro...
*#include "finclude/petsc.h"
or
*
*#include "finclude/petscdmda.h90"*
*#include "finclude/petscksp.h90"*
Then there is no problem.
May I know why this is happening?
Although I can now compile and build successfully, is this the
right way to go?
--
Thank you
Yours sincerely,
TAY wee-beng

--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener

[Matthew Knepley]

Post by Matthew Knepley
How about just including petsc.h90 so you get everything.
Thanks,
Matt
Sorry this is my 2nd email. See below for the 1st email. Using petsc.h90
gave the error "... segmentation violation signal raised ....

Right, the solution there is not to use a buggy compiler. I suggest gcc. It
is also faster for a lot of code than Intel.

Matt

Post by Matthew Knepley

Post by TAY wee-beng
Sorry I realised that
*#include "finclude/petscdmda.h90"*
*#include "finclude/petscksp.h90"*
error #5082: Syntax error, found ',' when expecting one of: ( % [ : . = =>*
* PetscInt, pointer :: array(:)*
*------------------^*
error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: )
,*
* PetscInt, pointer :: array(:)*
*---------------------------------------^*
error #5082: Syntax error, found IDENTIFIER 'N' when expecting one of: ( %
[ : . = =>*
* PetscInt n*
*--------------------^*
error #5082: Syntax error, found IDENTIFIER 'IERR' when expecting one of: (
% [ : . = =>*
* PetscErrorCode ierr*
*-------------------------^*
error #5082: Syntax error, found IDENTIFIER 'V' when expecting one of: ( %
[ : . = =>*
Thank you
Yours sincerely,
TAY wee-beng

Hi,

Post by TAY wee-beng
segmentation violation signal raised** Please report this error along with
File and line given may not be explicit cause of this error.
module PETSc_solvers
use set_matrix
...
implicit none
contains
subroutine semi_momentum_simple_xyz(du,dv,dw)
*#include "finclude/petsc.h90"*
integer :: i,j,k,ijk,ierr,II !,ro...
*#include "finclude/petsc.h" or *
*#include "finclude/petscdmda.h90"*
*#include "finclude/petscksp.h90"*
Then there is no problem.
May I know why this is happening?
Although I can now compile and build successfully, is this the right way
to go?
--
Thank you
Yours sincerely,
TAY wee-beng

--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

[Barry Smith]

Did you submit an Intel "Software Problem Report” as they requested? Perhaps they already have updates that fix the problem.

Barry

Post by Matthew Knepley
How about just including petsc.h90 so you get everything.
Thanks,
Matt

Sorry this is my 2nd email. See below for the 1st email. Using petsc.h90 gave the error "... segmentation violation signal raised ....
Right, the solution there is not to use a buggy compiler. I suggest gcc. It is also faster for a lot of code than Intel.
Matt

Post by Matthew Knepley
Sorry I realised that
#include "finclude/petscdmda.h90"
#include "finclude/petscksp.h90"
/home/wtay/Lib/petsc-3.4.4_shared_rel/include/finclude/ftn-custom/petscdmda.h90(10): error #5082: Syntax error, found ',' when expecting one of: ( % [ : . = =>
PetscInt, pointer :: array(:)
------------------^
/home/wtay/Lib/petsc-3.4.4_shared_rel/include/finclude/ftn-custom/petscdmda.h90(10): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: ) ,
PetscInt, pointer :: array(:)
---------------------------------------^
/home/wtay/Lib/petsc-3.4.4_shared_rel/include/finclude/ftn-custom/petscdmda.h90(11): error #5082: Syntax error, found IDENTIFIER 'N' when expecting one of: ( % [ : . = =>
PetscInt n
--------------------^
/home/wtay/Lib/petsc-3.4.4_shared_rel/include/finclude/ftn-custom/petscdmda.h90(12): error #5082: Syntax error, found IDENTIFIER 'IERR' when expecting one of: ( % [ : . = =>
PetscErrorCode ierr
-------------------------^
/home/wtay/Lib/petsc-3.4.4_shared_rel/include/finclude/ftn-custom/petscdmda.h90(13): error #5082: Syntax error, found IDENTIFIER 'V' when expecting one of: ( % [ : . = =>
Thank you
Yours sincerely,
TAY wee-beng

Hi,
/tmp/ifortlPEDlK.i90: catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
module PETSc_solvers
use set_matrix
...
implicit none
contains
subroutine semi_momentum_simple_xyz(du,dv,dw)
#include "finclude/petsc.h90"
integer :: i,j,k,ijk,ierr,II !,ro...
#include "finclude/petsc.h"
or
#include "finclude/petscdmda.h90"
#include "finclude/petscksp.h90"
Then there is no problem.
May I know why this is happening?
Although I can now compile and build successfully, is this the right way to go?
--
Thank you
Yours sincerely,
TAY wee-beng

--
What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
-- Norbert Wiener

--
What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
-- Norbert Wiener

[TAY wee-beng]

Post by TAY wee-beng

Post by Matthew Knepley
How about just including petsc.h90 so you get everything.
Thanks,
Matt

Sorry this is my 2nd email. See below for the 1st email. Using
petsc.h90 gave the error "... segmentation violation signal raised
....
Right, the solution there is not to use a buggy compiler. I suggest
gcc. It is also faster for a lot of code than Intel.

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.

Post by TAY wee-beng
Matt

Post by Matthew Knepley
Sorry I realised that
*#include "finclude/petscdmda.h90"*
*#include "finclude/petscksp.h90"*
error #5082: Syntax error, found ',' when expecting one of: (
% [ : . = =>/**/
/**/ PetscInt, pointer :: array(:)/**/
/**/------------------^/**/
error #5082: Syntax error, found END-OF-STATEMENT when
expecting one of: ) ,/**/
/**/ PetscInt, pointer :: array(:)/**/
/**/---------------------------------------^/**/
error #5082: Syntax error, found IDENTIFIER 'N' when
expecting one of: ( % [ : . = =>/**/
/**/ PetscInt n/**/
/**/--------------------^/**/
error #5082: Syntax error, found IDENTIFIER 'IERR' when
expecting one of: ( % [ : . = =>/**/
/**/ PetscErrorCode ierr/**/
/**/-------------------------^/**/
error #5082: Syntax error, found IDENTIFIER 'V' when
expecting one of: ( % [ : . = =>/*
Thank you
Yours sincerely,
TAY wee-beng

Post by TAY wee-beng
Hi,
I encountered the error below when compiling my code using
/tmp/ifortlPEDlK.i90: catastrophic error: **Internal
compiler error: segmentation violation signal raised**
Please report this error along with the circumstances in
which it occurred in a Software Problem Report. Note: File
and line given may not be explicit cause of this error.
module PETSc_solvers
use set_matrix
...
implicit none
contains
subroutine semi_momentum_simple_xyz(du,dv,dw)
*#include "finclude/petsc.h90"*
integer :: i,j,k,ijk,ierr,II !,ro...
*#include "finclude/petsc.h"
or
*
*#include "finclude/petscdmda.h90"*
*#include "finclude/petscksp.h90"*
Then there is no problem.
May I know why this is happening?
Although I can now compile and build successfully, is this
the right way to go?
--
Thank you
Yours sincerely,
TAY wee-beng

--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to
which their experiments lead.
-- Norbert Wiener

--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener

[Matthew Knepley]

Post by Matthew Knepley

Post by Matthew Knepley
How about just including petsc.h90 so you get everything.
Thanks,
Matt
Sorry this is my 2nd email. See below for the 1st email. Using
petsc.h90 gave the error "... segmentation violation signal raised ....

Right, the solution there is not to use a buggy compiler. I suggest gcc.
It is also faster for a lot of code than Intel.
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.

Anything is faster than a seg-faulting compiler. However, we have just run
a number of tests in which
gcc was faster.

Matt

Post by Matthew Knepley
Matt

Post by Matthew Knepley

Post by TAY wee-beng
Sorry I realised that
*#include "finclude/petscdmda.h90"*
*#include "finclude/petscksp.h90"*
error #5082: Syntax error, found ',' when expecting one of: ( % [ : . = =>*
* PetscInt, pointer :: array(:)*
*------------------^*
error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: )
,*
* PetscInt, pointer :: array(:)*
*---------------------------------------^*
error #5082: Syntax error, found IDENTIFIER 'N' when expecting one of: ( %
[ : . = =>*
* PetscInt n*
*--------------------^*
error #5082: Syntax error, found IDENTIFIER 'IERR' when expecting one of: (
% [ : . = =>*
* PetscErrorCode ierr*
*-------------------------^*
error #5082: Syntax error, found IDENTIFIER 'V' when expecting one of: ( %
[ : . = =>*
Thank you
Yours sincerely,
TAY wee-beng

Hi,

Post by TAY wee-beng
segmentation violation signal raised** Please report this error along with
File and line given may not be explicit cause of this error.
module PETSc_solvers
use set_matrix
...
implicit none
contains
subroutine semi_momentum_simple_xyz(du,dv,dw)
*#include "finclude/petsc.h90"*
integer :: i,j,k,ijk,ierr,II !,ro...
*#include "finclude/petsc.h" or *
*#include "finclude/petscdmda.h90"*
*#include "finclude/petscksp.h90"*
Then there is no problem.
May I know why this is happening?
Although I can now compile and build successfully, is this the right way
to go?
--
Thank you
Yours sincerely,
TAY wee-beng

--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

[Jed Brown]

Post by TAY wee-beng
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.

[TAY wee-beng]

Post by Jed Brown

Post by TAY wee-beng
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.

Actually in my original email, I mentioned that by using petsc.h instead
of petsc.h90, I was able to compile and build successfully. Running it
seems to be fine. I will try gfortran when I have the time and report my
results. Thanks!

[Barry Smith]

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

Post by Jed Brown

Post by TAY wee-beng
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.

[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

Post by Barry Smith
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

Post by Jed Brown

Post by TAY wee-beng
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.

[Jed Brown]

Post by TAY wee-beng
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.

Writing portable standards-compliant code pays off.

Post by TAY wee-beng
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?

They often have modules to access more recent versions. You can also
request it. Paying to upgrade commercial compilers while leaving open
source compilers at an old version is not good machine maintenance.

Post by TAY wee-beng
Also, can anyone recommend options to get optimized results in gfortran?
-fno-signed-zeros -fno-trapping-math -ffast-math -march=native
-funroll-loops -ffree-line-length-none -O3

I usually use this, with or without -ffast-math depending on requirements:

-O3 -march=native -ftree-vectorize

[TAY wee-beng]

Hi all,

Thank you for the gfortran options. I will try them out!

Yours sincerely,

TAY wee-beng

Post by Jed Brown

Post by TAY wee-beng
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.

Writing portable standards-compliant code pays off.

Post by TAY wee-beng
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?

They often have modules to access more recent versions. You can also
request it. Paying to upgrade commercial compilers while leaving open
source compilers at an old version is not good machine maintenance.

Post by TAY wee-beng
Also, can anyone recommend options to get optimized results in gfortran?
-fno-signed-zeros -fno-trapping-math -ffast-math -march=native
-funroll-loops -ffree-line-length-none -O3

-O3 -march=native -ftree-vectorize

[Dharmendar Reddy]

Hello wee-beng,
What is the version of intel compiler you
are using ? I use 13.1.0.146 Build 20130121, i have no issues using
petsc.h90 in my fortran code.

Reddy

Post by 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?
-fno-signed-zeros -fno-trapping-math -ffast-math -march=native
-funroll-loops -ffree-line-length-none -O3
Thank you.
Yours sincerely,
TAY wee-beng

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

Post by Jed Brown

Post by TAY wee-beng
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.

[TAY wee-beng]

Post by Dharmendar Reddy
Hello wee-beng,
What is the version of intel compiler you
are using ? I use 13.1.0.146 Build 20130121, i have no issues using
petsc.h90 in my fortran code.
Reddy

Hi Reddy,

Thanks for the help. I was also using petsc.h90 w/o problem until I
added some DM functions into my code. I'm using ifort 11 and 12. Maybe
it's fixed in 13 but my cluster doesn't have it.

Anyway, I can circumvent the error by using petsc.h instead.

Regards.

Post by Dharmendar Reddy

Post by 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?
-fno-signed-zeros -fno-trapping-math -ffast-math -march=native
-funroll-loops -ffree-line-length-none -O3
Thank you.
Yours sincerely,
TAY wee-beng

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

Post by Jed Brown

Post by TAY wee-beng
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.