After compiling the whole codes without no errors, I'm getting into
the trouble of  "segmentation fault" when I try to run the executable
file.
It's a little bit annoying....
Although I've known it's generated by several factors:
# An array index is outside the declared range.
# The name of an array index is misspelled.
# The calling routine has a REAL argument, which the called routine
has as INTEGER.
# An array index is miscalculated.
# The calling routine has fewer arguments than required.
# A pointer is used before it has been defined.
.....I can't find the fatal factor(s).

But is there any software or package to check this progress?
My OS is openSUSE 11.0, the compiler is SCons.

On Jun 1, 7:53=A0am, Benjamin <benjami...@googlemail.com> wrote:
> After compiling the whole codes without no errors, I'm getting into
> the trouble of =A0"segmentation fault" when I try to run the executable
> file.
> It's a little bit annoying....
> Although I've known it's generated by several factors:
> # An array index is outside the declared range.
> # The name of an array index is misspelled.
> # The calling routine has a REAL argument, which the called routine
> has as INTEGER.
> # An array index is miscalculated.
> # The calling routine has fewer arguments than required.
> # A pointer is used before it has been defined.
> ....I can't find the fatal factor(s).
>
> But is there any software or package to check this progress?
> My OS is openSUSE 11.0, the compiler is SCons.

Scons appears to be some sort of integrated build environment.
What is the actual Fortran compiler installed on your system?

--
steve

On 1 Jun., 16:59, steve <kar...@comcast.net> wrote:
> On Jun 1, 7:53=A0am, Benjamin <benjami...@googlemail.com> wrote:
>
>
>
> > After compiling the whole codes without no errors, I'm getting into
> > the trouble of =A0"segmentation fault" when I try to run the executable
> > file.
> > It's a little bit annoying....
> > Although I've known it's generated by several factors:
> > # An array index is outside the declared range.
> > # The name of an array index is misspelled.
> > # The calling routine has a REAL argument, which the called routine
> > has as INTEGER.
> > # An array index is miscalculated.
> > # The calling routine has fewer arguments than required.
> > # A pointer is used before it has been defined.
> > ....I can't find the fatal factor(s).
>
> > But is there any software or package to check this progress?
> > My OS is openSUSE 11.0, the compiler is SCons.
>
> Scons appears to be some sort of integrated build environment.
> What is the actual Fortran compiler installed on your system?
>
> --
> steve

Oh, sry, gFortran is the actual comiler

Hello,
a debugger might be a great help in this situation.
If you are planning to dig deep into programming,
learning to use the available debuggers is a worthwhile option.

Another possible reason: Too small memory sizes, like stack size.
Can usually be corrected with ulimit.

Good luck
Alois

Benjamin wrote:

> 
> After compiling the whole codes without no errors, I'm getting into
> the trouble of  "segmentation fault" when I try to run the executable
> file.
> It's a little bit annoying....
> Although I've known it's generated by several factors:
> # An array index is outside the declared range.
> # The name of an array index is misspelled.
> # The calling routine has a REAL argument, which the called routine
> has as INTEGER.
> # An array index is miscalculated.
> # The calling routine has fewer arguments than required.
> # A pointer is used before it has been defined.
> ....I can't find the fatal factor(s).
> 
> But is there any software or package to check this progress?
> My OS is openSUSE 11.0, the compiler is SCons.

1. Compile with the checking options of your compiler set ON
(e.g., -C -traceback ... check your compiler options list see what to use)

AND/OR

2. Compile with -g, and use tools such as GDB and VALGRIND.

Once you establish that the seg-fault is traceable to your code, you may see
it as a good thing, if the alternative is to propagate erroneous results
throughout your program with no notification to you. 

Compiling without errors merely establishes that those errors that are
detectable by static analysis of the code have been removed. By no means
does it follow that there are no more errors left in the code.

-- mecej4

On 1 Jun., 17:56, mecej4 <mecej4.nyets...@operamail.com> wrote:
> Benjamin wrote:
>
> > After compiling the whole codes without no errors, I'm getting into
> > the trouble of =A0"segmentation fault" when I try to run the executable
> > file.
> > It's a little bit annoying....
> > Although I've known it's generated by several factors:
> > # An array index is outside the declared range.
> > # The name of an array index is misspelled.
> > # The calling routine has a REAL argument, which the called routine
> > has as INTEGER.
> > # An array index is miscalculated.
> > # The calling routine has fewer arguments than required.
> > # A pointer is used before it has been defined.
> > ....I can't find the fatal factor(s).
>
> > But is there any software or package to check this progress?
> > My OS is openSUSE 11.0, the compiler is SCons.
>
> 1. Compile with the checking options of your compiler set ON
> (e.g., -C -traceback ... check your compiler options list see what to use=
)
>
> AND/OR
>
> 2. Compile with -g, and use tools such as GDB and VALGRIND.
>
> Once you establish that the seg-fault is traceable to your code, you may =
see
> it as a good thing, if the alternative is to propagate erroneous results
> throughout your program with no notification to you.
>
> Compiling without errors merely establishes that those errors that are
> detectable by static analysis of the code have been removed. By no means
> does it follow that there are no more errors left in the code.
>
> -- mecej4

Thanks a lot.
I've complied the program with SCons...
now I'm trying to debug the program with gdb..

On Jun 1, 8:01=A0am, Benjamin <benjami...@googlemail.com> wrote:
> On 1 Jun., 16:59, steve <kar...@comcast.net> wrote:
>
>
>
> > On Jun 1, 7:53=A0am, Benjamin <benjami...@googlemail.com> wrote:
>
> > > After compiling the whole codes without no errors, I'm getting into
> > > the trouble of =A0"segmentation fault" when I try to run the executab=
le
> > > file.
> > > It's a little bit annoying....
> > > Although I've known it's generated by several factors:
> > > # An array index is outside the declared range.
> > > # The name of an array index is misspelled.
> > > # The calling routine has a REAL argument, which the called routine
> > > has as INTEGER.
> > > # An array index is miscalculated.
> > > # The calling routine has fewer arguments than required.
> > > # A pointer is used before it has been defined.
> > > ....I can't find the fatal factor(s).
>
> > > But is there any software or package to check this progress?
> > > My OS is openSUSE 11.0, the compiler is SCons.
>
> > Scons appears to be some sort of integrated build environment.
> > What is the actual Fortran compiler installed on your system?
>
> > --
> > steve
>
> Oh, sry, gFortran is the actual comiler

With gfortran try the compiler options '-fbounds-check -Wall -Wextra -
g'.
The -Wall and -Wextra option will most likely produce a large amount
that (IMHO) should be fixed.  -fbounds-check should help catch array
index issues.

--
steve

Benjamin wrote:
....

> Thanks a lot.
> I've complied the program with SCons...
> now I'm trying to debug the program with gdb..

As others have noted, use all available error trapping and traceback 
options first.

One could also disable optimization until the problem(s) is/are resolved 
as well as it may make determination of just where something went sought 
somewhat easier.

Rarely would there be no clues or breadcrumbs to follow after such has 
been done...

--

On 6/1/2010 8:53 AM, Benjamin wrote:
>
> After compiling the whole codes without no errors, I'm getting into
> the trouble of  "segmentation fault" when I try to run the executable
> file.
> It's a little bit annoying....
> Although I've known it's generated by several factors:

<snip>
> # The name of an array index is misspelled.

Use "implicit none" if you're not doing so already.  You'll have to 
declare all of your variables, and unless you declare two variables with 
very similar names, the compiler is likely to catch misspellings.

> # The calling routine has a REAL argument, which the called routine
> has as INTEGER.
<snip>
> # The calling routine has fewer arguments than required.
<snip>

Use modules.  The compiler will convert arguments as necessary (someone 
want to verify this?) or flag argument list mismatches.

Louis

In article <5KWdnQAwhvwt9ZjRnZ2dnUVZ_g6dnZ2d@indra.net>,
 Louis Krupp <lkrupp_nospam@indra.com.invalid> wrote:

> 
> Use modules.  The compiler will convert arguments as necessary

No, nothing is converted.

> (someone 
> want to verify this?)

You must be thinking of some other language.  Other languages do 
sometimes do silent conversions to match arguments.

> or flag argument list mismatches.

This part *IS* right, and that's one of the reasons why modules are so 
useful.

$.02 -Ron Shepard

On 6/1/2010 9:40 PM, Ron Shepard wrote:
> In article<5KWdnQAwhvwt9ZjRnZ2dnUVZ_g6dnZ2d@indra.net>,
>   Louis Krupp<lkrupp_nospam@indra.com.invalid>  wrote:
>
>>
>> Use modules.  The compiler will convert arguments as necessary
>
> No, nothing is converted.
>
>> (someone
>> want to verify this?)
>
> You must be thinking of some other language.  Other languages do
> sometimes do silent conversions to match arguments.

So reals aren't truncated to integers?

Louis

Louis Krupp wrote:
> On 6/1/2010 9:40 PM, Ron Shepard wrote:
....
>> You must be thinking of some other language.  Other languages do
>> sometimes do silent conversions to match arguments.
> 
> So reals aren't truncated to integers?

In argument lists?  No, a REAL in a CALL statement for a routine 
expecting an INTEGER will generate a mismatched argument type error (in 
the module during compilation) and a mismatched call if forced to link 
outside of one where a compiler may not be able to tell of the mismatch.

--

dpb wrote:

> Louis Krupp wrote:
>> On 6/1/2010 9:40 PM, Ron Shepard wrote:
> ...
>>> You must be thinking of some other language.  Other languages do
>>> sometimes do silent conversions to match arguments.
>> 
>> So reals aren't truncated to integers?
> 
> In argument lists?  No, a REAL in a CALL statement for a routine
> expecting an INTEGER will generate a mismatched argument type error (in
> the module during compilation) and a mismatched call if forced to link
> outside of one where a compiler may not be able to tell of the mismatch.
> 
> --
To add to what dpb said: If the expected INTEGER is used as a subscript but
a real (or another mismatched type) was passed instead, a prompt SEGFAULT
may be expected.

-- mecej4

On 6/2/2010 6:24 AM, mecej4 wrote:
> dpb wrote:
>
>> Louis Krupp wrote:
>>> On 6/1/2010 9:40 PM, Ron Shepard wrote:
>> ...
>>>> You must be thinking of some other language.  Other languages do
>>>> sometimes do silent conversions to match arguments.
>>>
>>> So reals aren't truncated to integers?
>>
>> In argument lists?  No, a REAL in a CALL statement for a routine
>> expecting an INTEGER will generate a mismatched argument type error (in
>> the module during compilation) and a mismatched call if forced to link
>> outside of one where a compiler may not be able to tell of the mismatch.
>>
>> --
> To add to what dpb said: If the expected INTEGER is used as a subscript but
> a real (or another mismatched type) was passed instead, a prompt SEGFAULT
> may be expected.

Likely (given the format of IEEE floating point, for example), but not 
necessarily (if a high virtual address plus garbage with high-order bits 
turned on wrap around to a low, valid virtual address).

The same thing would happen in that Other Language with which I'm more 
familiar.

Louis

In article <8-GdnX9H3cm8lpvRnZ2dnUVZ_qudnZ2d@indra.net>,
 Louis Krupp <lkrupp_nospam@indra.com.invalid> wrote:

> > You must be thinking of some other language.  Other languages do
> > sometimes do silent conversions to match arguments.
> 
> So reals aren't truncated to integers?

No.  Actually I can't think of any situation offhand where reals are 
truncated to integers.  In some contexts, such as mixed arithmetic, 
integers are silently converged to reals, but I can't think of any 
situations where the reverse occurs.  And especially for subprogram 
arguments, no conversion is ever done silently, not even between 
different kinds of the same type, much less between different types.

$.02 -Ron Shepard

Ron Shepard <ron-shepard@nospam.comcast.net> wrote:
(snip, someone wrote)
 
>> So reals aren't truncated to integers?
 
> No.  Actually I can't think of any situation offhand where reals are 
> truncated to integers.  In some contexts, such as mixed arithmetic, 
> integers are silently converged to reals, but I can't think of any 
> situations where the reverse occurs.  And especially for subprogram 
> arguments, no conversion is ever done silently, not even between 
> different kinds of the same type, much less between different types.

Well, reals are truncated on assignment to an integer variable,
but maybe you don't count that.

Some systems allow real expressions for subscripts, truncating
the value to an integer.

Or course the intrinsic functions specifically designed to
convert non-integer values to integers, as appropriate.

But yes, it is not done for subroutine arguments.

-- glen

On Jun 2, 3:33=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Ron Shepard <ron-shep...@nospam.comcast.net> wrote:
>
> (snip, someone wrote)
>
> >> So reals aren't truncated to integers?
> > No. =A0Actually I can't think of any situation offhand where reals are
> > truncated to integers. =A0In some contexts, such as mixed arithmetic,
> > integers are silently converged to reals, but I can't think of any
> > situations where the reverse occurs. =A0And especially for subprogram
> > arguments, no conversion is ever done silently, not even between
> > different kinds of the same type, much less between different types.
>
> Well, reals are truncated on assignment to an integer variable,
> but maybe you don't count that.
>
> Some systems allow real expressions for subscripts, truncating
> the value to an integer.
>
troutmask:sgk[218] cat > k.f
      program ohmy
      real x(3)
      x =3D (/ 1, 2, 3 /)
      print *, x(2.1)
      end
troutmask:sgk[219] gfc4x -o z k.f
k.f:4.17:

      print *,
x(2.1)
                 1
Warning: Extension: REAL array index at (1)
troutmask:sgk[220] ./z
   2.0000000

--
steve

Louis Krupp wrote:
> On 6/1/2010 9:40 PM, Ron Shepard wrote:
>> In article<5KWdnQAwhvwt9ZjRnZ2dnUVZ_g6dnZ2d@indra.net>,
>>   Louis Krupp<lkrupp_nospam@indra.com.invalid>  wrote:
>>
>>>
>>> Use modules.  The compiler will convert arguments as necessary
>>
>> No, nothing is converted.
>>
>>> (someone
>>> want to verify this?)
>>
>> You must be thinking of some other language.  Other languages do
>> sometimes do silent conversions to match arguments.
> 
> So reals aren't truncated to integers?

Certainly not with non-VALUE arguments, but that's true of just about 
any language I might care to mention; it just becomes obvious with C, 
C++, etc. because they use value arguments so frequently.

Although I don't think there's a strong technical reason for it, it does 
not appear that Fortran will do any automatic conversion for numeric 
VALUE arguments.  It seems like something that could be put in without 
an obnoxious amount of effort considering that the text of the '03 
standard already says, "If the VALUE attribute is specified, the effect 
is as if the actual argument is assigned to a temporary, and the 
temporary is then argument associated with the dummy argument."  (But 
that's in a Note, and the normative text requires that the actual 
argument be type-compatible with non-pointer, non-allocatable dummy with 
no qualifications.)

Craig Powers <craig.powers@invalid.invalid> wrote:

> Although I don't think there's a strong technical reason for it, it does
> not appear that Fortran will do any automatic conversion for numeric 
> VALUE arguments.  It seems like something that could be put in without
> an obnoxious amount of effort...

other than completely blowing generics out of the water. :-(

And maybe a few other things, but that one immediately occurs to me.

Plus, of course, being completely unlike any other procedure arguments
in the language, which would be bound to cause no end of confusion. It
sure seems a lot simpler and more consistent to just be able to say that
arguments must match and there is never any conversion instead of having
to add "well, except in this one special class of cases, where it is
different just because it could be."

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Richard Maine <nospam@see.signature> wrote:

> Craig Powers <craig.powers@invalid.invalid> wrote:
> 
> > Although I don't think there's a strong technical reason for it, it does
> > not appear that Fortran will do any automatic conversion for numeric
> > VALUE arguments.  It seems like something that could be put in without
> > an obnoxious amount of effort...
> 
> other than completely blowing generics out of the water. :-(
> 
> And maybe a few other things, but that one immediately occurs to me.

A related one that occurred to me right after posting that is all the
stuff about how procedure resolution works. Admitedly, that is related
in that generics get all tied up with it. But I'd call it an additional
complication because it would still need work even if one came up with
some rule to make it compatible with generics. In fact, any such rule
would have to be stuck right in the middle of the the procedure name
resolution stuff.

That's one of the messier few pages of the standard. The only reason it
doesn't generate zillions of questions here is that almost all of the
cases in real programs are dead trivial; when you call a procedure by
name, there is usually only one accessible procedure with that name and
that's the one you get. Anything that touches those particular messy
pages counts as a pretty obnoxious amount of effort in my book.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Craig Powers <craig.powers@invalid.invalid> wrote:
(snip)
 
> Certainly not with non-VALUE arguments, but that's true of just about 
> any language I might care to mention; it just becomes obvious with C, 
> C++, etc. because they use value arguments so frequently.

PL/I will do it under the appropriate conditions, generating 
a temporary and passing that.  The value won't be written back
to the original variable, so you have to be careful.
 
> Although I don't think there's a strong technical reason for it, it does 
> not appear that Fortran will do any automatic conversion for numeric 
> VALUE arguments.  

It makes some sense for BIND(C) VALUE arguments, as C would
do it with a prototype in scope.

> It seems like something that could be put in without 
> an obnoxious amount of effort considering that the text of the '03 
> standard already says, "If the VALUE attribute is specified, the effect 
> is as if the actual argument is assigned to a temporary, and the 
> temporary is then argument associated with the dummy argument."  (But 
> that's in a Note, and the normative text requires that the actual 
> argument be type-compatible with non-pointer, non-allocatable dummy with 
> no qualifications.)

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Craig Powers <craig.powers@invalid.invalid> wrote:

>  
> > Although I don't think there's a strong technical reason for it, it does
> > not appear that Fortran will do any automatic conversion for numeric
> > VALUE arguments.  
> 
> It makes some sense for BIND(C) VALUE arguments, as C would
> do it with a prototype in scope.

As noted in other threads, Fortran isn't C. And no, I don't buy the
"this was just for comparison purposes." Sure reads like an explicit
suggestion to put in into Fortran to me.

"C does it" isn't much of a reason to argue that something should be
done in Fortran. It actually has to fit in the Fortran language. Yes,
that is so even for BIND(C) procedures. C does lots of things in
function calls that Fortran doesn't do.

Earlier today or yesterday you were suggesting that something be more
consistent. Now you want to make BIND(C) VALUE arguments behave
fundamentally different from all other arguments, including other
BIND(C) and other VALUE arguments; one has to have both to trigger the
special case? This for no reason other than that C does it? You appear
to have a different notion of consistency than I do.

Do note, by the way, that just because a procedure is BIND(C), that
doesn't mean it is necessarily a procedure written in C.

But I don't know why I bother to post this. It ain't going to happen. No
way. As noted in my other post, it would invalidate existing standard
conforming codes by badly breaking generics. Yes, I'd bet there are
existing codes that use BIND(C) procedures in generics. It is a natural
thing to do. While incompatibilities like that have been known to
happen, they tend to fall into one of 2 classes.

1. The incompatibility was not noticed until after the new standard was
published. Often that isn't even enough, as there have been known to be
errata to fix that kind of problem. Such an unnoticed incompatibility
has more than once been cited as being an adequate reason for an errata.
But this one isn't unnoticed. It wouldn't be unnoticed even if I hadn't
pointed out. It is a glaring big incompatibility.

or

2. There is darn good justification given. Nothing here has been even
close to the kind of justification that tends to be needed. If you think
otherwise, well.... lots of luck. I'll be confident inmy claim that it
ain't gonna happen.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Richard Maine wrote:
> Craig Powers <craig.powers@invalid.invalid> wrote:
> 
>> Although I don't think there's a strong technical reason for it, it does
>> not appear that Fortran will do any automatic conversion for numeric 
>> VALUE arguments.  It seems like something that could be put in without
>> an obnoxious amount of effort...
> 
> other than completely blowing generics out of the water. :-(
> 
> And maybe a few other things, but that one immediately occurs to me.

Oops, yeah, I forgot about that.

C++ manages it, but from what I recall when I followed C++ more closely, 
conversion and overload matching rules are a consistent sore point. 
There are definitely dragons there, so it would make sense to stay away 
with Fortran.