[Bug fortran/45624] Division by zero compiler error

2010-09-10 Thread leftynm at umich dot edu


--- Comment #5 from leftynm at umich dot edu  2010-09-10 16:06 ---
Thanks guys.  Yeah, I guess my use of PARAMETER wasn't consistent with how it
works.  I was using it to set a variable such that it cannot be changed.  I
found a work around though lets me keep it as a PARAMETER, but allows me to
compile.

PROGRAM test

IMPLICIT NONE
REAL*8, PARAMETER   :: alpha = 0.D0
REAL*8, DIMENSION(5,5)  :: matrix
INTEGER :: i
REAL*8  :: dummy

matrix = 0.D0

DO i=1,5
IF (alpha == 0.D0) THEN
matrix(i,i) = 0.D0
ELSE
dummy = alpha
matrix(i,i) = 1.D0/dummy
ENDIF
ENDDO

END PROGRAM

This is what I need, since when I don't make my variable a PARAMETER, it causes
other problems.  This requires less work to fix, so I'm happy with it.  I tried
PROTECTED, but my code has to be F90 because it's a small part of a bigger
project.

Thanks to everyone though.  I wouldn't have figured this out without your
inputs.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45624



[Bug fortran/45624] Division by zero compiler error

2010-09-09 Thread dominiq at lps dot ens dot fr


--- Comment #4 from dominiq at lps dot ens dot fr  2010-09-09 23:20 ---
You can use the option -fno-range-check. However, the code itself and the
sentence "since I want to protect this variable" in comment #3 let me suspect
that you have not understood what PARAMETER is for: a variable with the
PARAMETER "attribute" is an alias for its value and exists only during the
compilation. 

What you seem to want is the attribute PROTECTED, i.e. a variable that can be
changed only in a specified place as in (F2003 standard draft):

An example of the PROTECTED attribute:

MODULE temperature
REAL, PROTECTED :: temp_c, temp_f
CONTAINS
SUBROUTINE set_temperature_c(c)
REAL, INTENT(IN) :: c
temp_c = c
temp_f = temp_c*(9.0/5.0) + 32
END SUBROUTINE
END MODULE

The PROTECTED attribute ensures that the variables temp_c and temp_f cannot be
modied other than
via the set_temperature_c procedure, thus keeping them consistent with each
other.

The PROTECTED attribute is a f2003 addition, implemented at least from gfortran
4.4.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45624



[Bug fortran/45624] Division by zero compiler error

2010-09-09 Thread leftynm at umich dot edu


--- Comment #3 from leftynm at umich dot edu  2010-09-09 22:56 ---
Ok, if the fact that the variable is a parameter causes this error, I'll have
to adjust the rest of my code accordingly to work around this problem.  It
seems like there should be a better way to fix this, since I want to protect
this variable.
But, I'll take it.  Thanks for the quick reply.


-- 

leftynm at umich dot edu changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45624



[Bug fortran/45624] Division by zero compiler error

2010-09-09 Thread kargl at gcc dot gnu dot org


--- Comment #2 from kargl at gcc dot gnu dot org  2010-09-09 22:25 ---
There is no way to fix this problem unless you
would like +inf along the diagonal.

gfortran will constant fold 1./alpha if alpha has
the parameter attribute.  After all, this attribute
tells the compiler that alpha is a named constant,
ie., it will not change.  

PS:  Fortran bugs are never given a severity high
than normal unless the bug breaks bootstrapping
the compiler.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45624



[Bug fortran/45624] Division by zero compiler error

2010-09-09 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2010-09-09 22:19 ---
PARAMETER are special as it is an exact replacement for those variables.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45624