 Up |
|
|
  |
Author: monirmonir Date: Jun 13, 2008 07:17
Hello;
I would very much appreciate your help.
The following IF statement in g95 Fortran compiler:
Real EPS
Complex x
if (abs(aimag(x)) .le. 2.*EPS**2*abs(real(x))) x=cmplx(real(x),0.)
.................................................................(1)
produces the following error:
Error: Unclassifiable statement following IF-clause at (1)
Thank you kindly.
Monir
|
| |
|
| | 18 Comments |
|
|
Author: Michael MetcalfMichael Metcalf Date: Jun 13, 2008 07:31
> Hello;
>
> I would very much appreciate your help.
>
> The following IF statement in g95 Fortran compiler:
> Real EPS
> Complex x
> if (abs(aimag(x)) .le. 2.*EPS**2*abs(real(x))) x=cmplx(real(x),0.)
> .................................................................(1)
> produces the following error:
> Error: Unclassifiable statement following IF-clause at (1)
>
It looks fine and compiles with ifort. A compiler bug?
Regards,
Mike Metcalf
|
| |
|
| | no comments |
|
|
Author: dpbdpb Date: Jun 13, 2008 07:35
Michael Metcalf wrote:
>> Hello;
>>
>> I would very much appreciate your help.
>>
>> The following IF statement in g95 Fortran compiler:
>> Real EPS
>> Complex x
>> if (abs(aimag(x)) .le. 2.*EPS**2*abs(real(x))) x=cmplx(real(x),0.)
>> .................................................................(1)
>> produces the following error:
>> Error: Unclassifiable statement following IF-clause at (1)
>>
>
> It looks fine and compiles with ifort. A compiler bug?
Just for testing that out, I presume g95 will compile if use
if() then
|
| Show full article (0.74Kb) |
| no comments |
|
|
Author: nospamnospam Date: Jun 13, 2008 08:01
Michael Metcalf compuserve.com> wrote:
>> Hello;
>>
>> I would very much appreciate your help.
>>
>> The following IF statement in g95 Fortran compiler:
>> Real EPS
>> Complex x
>> if (abs(aimag(x)) .le. 2.*EPS**2*abs(real(x))) x=cmplx(real(x),0.)
>> .................................................................(1)
>> produces the following error:
>> Error: Unclassifiable statement following IF-clause at (1)
>>
>
> It looks fine and compiles with ifort. A compiler bug?
|
| Show full article (1.25Kb) |
| no comments |
|
|
Author: dpbdpb Date: Jun 13, 2008 09:31
Richard Maine wrote:
...
> ... The code then goes past the column 72 limit of
> fixed source form.
Aha! Good deduction/catch, Richard!
Crystal ball not even needed, eh? :)
--
|
| |
| no comments |
|
|
Author: James GilesJames Giles Date: Jun 13, 2008 12:41
Richard Maine wrote:
...
> If I compile the code as fixed source form (i.e. use a .f file
> extension), moving all the statements over to column 7, then I can
> reproduce your error. The code then goes past the column 72 limit of
> fixed source form.
If your compiler has an option to make long lines into some
kind of error I'd recommend always turning it on. G95 has
the following:
-Wline-truncation Warn about truncated source lines.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
|
| |
| no comments |
|
|
Author: monirmonir Date: Jun 13, 2008 14:45
On Jun 13, 3:41 pm, "James Giles" worldnet.att.net> wrote:> Richard Maine wrote:
>
> ...
>
>> If I compile the code as fixed source form (i.e. use a .f file
>> extension), moving all the statements over to column 7, then I can
>> reproduce your error. The code then goes past the column 72 limit of
>> fixed source form.
>
> If your compiler has an option to make long lines into some
> kind of error I'd recommend always turning it on. G95 has
> the following:
>
> -Wline-truncation Warn about truncated source lines.
>
> --
> J. Giles
>
> "I conclude that there are two ways of constructing a software ...
|
| Show full article (2.11Kb) |
| no comments |
|
|
Author: Sjouke BurrySjouke Burry Date: Jun 13, 2008 15:11
monir wrote:
> On Jun 13, 3:41 pm, "James Giles" worldnet.att.net> wrote:>> Richard Maine wrote:
>>
>> ...
>>
>>> If I compile the code as fixed source form (i.e. use a .f file
>>> extension), moving all the statements over to column 7, then I can
>>> reproduce your error. The code then goes past the column 72 limit of
>>> fixed source form.
>> If your compiler has an option to make long lines into some
>> kind of error I'd recommend always turning it on. G95 has
>> the following:
>>
>> -Wline-truncation Warn about truncated source lines.
>>
>> --
>> J. Giles
>>
>> "I conclude that there are two ways of constructing a software ...
|
| Show full article (2.28Kb) |
| no comments |
|
|
Author: nospamnospam Date: Jun 13, 2008 15:12
monir mondenet.com> wrote:
> 1) Replacing the IF statement by a block IF appears to be working
> fine. I'm not sure if I should replace similar statements throughout
> the program.
It has nothing to do with being an IF statement. It has everything to do
with going past col 72.
> 3) I hope you don't mind a related question!
I don't mind, but no it has no relationship at all.
|
| Show full article (3.06Kb) |
| no comments |
|
|
|
|
|
Author: nospamnospam Date: Jun 13, 2008 15:16
Sjouke Burry wrote:
> Specify your figures as double precision??(as 1.0d0 for example?)
Um. No. Right general idea - that precision is the problem - but...
1. The d0 is relevant only in source code. It has *NO* effect on I/O.
Reading a 1.0d0 does not make the result double precision. THat depends
only on the variable being read into.
2. The special case of 1.0 will be exact anyway, even insingle
precision.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
|
| |
| no comments |
|
|
|
