In a Fortran program I have these lines.
...
print '(" ALLOCATED C:", l4)', ALLOCATED (C)
print '(" ALLOCATED X:", l4)', ALLOCATED (X)
print '(" ALLOCATED Z:", l4)', ALLOCATED (Z)
print '(" ALLOCATED p:", l4)', ALLOCATED (p)
print '(" ALLOCATED r:", l4)', ALLOCATED (r)
DEALLOCATE (C, X, Z, p, r,stat=i)
print '(" DEALLOCATE status =", i4)', i
...
When I run the program, this produces
ALLOCATED C: T
ALLOCATED X: T
ALLOCATED Z: T
ALLOCATED p: T
ALLOCATED r: T
munmap_chunk(): invalid pointer
It is the DEALLOCATE statement where it happens. Any idea why?
In a Fortran program I have these lines
...
print '(" ALLOCATED C:", l4)', ALLOCATED (C)
print '(" ALLOCATED X:", l4)', ALLOCATED (X)
print '(" ALLOCATED Z:", l4)', ALLOCATED (Z)
print '(" ALLOCATED p:", l4)', ALLOCATED (p)
print '(" ALLOCATED r:", l4)', ALLOCATED (r)
DEALLOCATE (C, X, Z, p, r,stat=i)
print '(" DEALLOCATE status =", i4)', i
...
When I run the program, this produces
ALLOCATED C: T
ALLOCATED X: T
ALLOCATED Z: T
ALLOCATED p: T
ALLOCATED r: T
munmap_chunk(): invalid pointer
It is the DEALLOCATE statement where it happens. Any idea why?
..
DEALLOCATE (C, X, Z, p, r,stat=i)
print '(" DEALLOCATE status =", i4)', i
...
When I run the program, this produces
..
munmap_chunk(): invalid pointer
It is the DEALLOCATE statement where it happens. Any idea why?
On Sunday, September 11, 2022 at 11:52:36 PM UTC+10, db wrote:
In a Fortran program I have these lines.
...
print '(" ALLOCATED C:", l4)', ALLOCATED (C)
print '(" ALLOCATED X:", l4)', ALLOCATED (X)
print '(" ALLOCATED Z:", l4)', ALLOCATED (Z)
print '(" ALLOCATED p:", l4)', ALLOCATED (p)
print '(" ALLOCATED r:", l4)', ALLOCATED (r)
DEALLOCATE (C, X, Z, p, r,stat=i)
print '(" DEALLOCATE status =", i4)', i
...
When I run the program, this produces
ALLOCATED C: T
ALLOCATED X: T
ALLOCATED Z: T
ALLOCATED p: T
ALLOCATED r: T
munmap_chunk(): invalid pointer
It is the DEALLOCATE statement where it happens. Any idea why?
You could try deallocating each one separately.
You could try deallocating each one separately.
That was the way to the solution. I found that C, X and Z were fine
but it baulked at p. So I looked further and found that although I
had allocated p and r as p(3,NX) and r(3,NZ), in a routine I assigned
values to (p(0,i) and r(0,i), so I overwrote something. When I removed
that, the problem went away. A hard one.
On 11.09.2022 18.44, Robin Vowels wrote:.
On Sunday, September 11, 2022 at 11:52:36 PM UTC+10, db wrote:That was the way to the solution. I found that C, X and Z were fine
In a Fortran program I have these lines.
...
print '(" ALLOCATED C:", l4)', ALLOCATED (C)
print '(" ALLOCATED X:", l4)', ALLOCATED (X)
print '(" ALLOCATED Z:", l4)', ALLOCATED (Z)
print '(" ALLOCATED p:", l4)', ALLOCATED (p)
print '(" ALLOCATED r:", l4)', ALLOCATED (r)
DEALLOCATE (C, X, Z, p, r,stat=i)
print '(" DEALLOCATE status =", i4)', i
...
When I run the program, this produces
ALLOCATED C: T
ALLOCATED X: T
ALLOCATED Z: T
ALLOCATED p: T
ALLOCATED r: T
munmap_chunk(): invalid pointer
It is the DEALLOCATE statement where it happens. Any idea why?
You could try deallocating each one separately.
but it baulked at p. So I looked further and found that although I
had allocated p and r as p(3,NX) and r(3,NZ), in a routine I assigned
values to (p(0,i) and r(0,i), so I overwrote something. When I removed
that, the problem went away. A hard one.
..That was the way to the solution. I found that C, X and Z were fine
You could try deallocating each one separately.
but it baulked at p. So I looked further and found that although I
had allocated p and r as p(3,NX) and r(3,NZ), in a routine I assigned
values to (p(0,i) and r(0,i), so I overwrote something. When I removed
that, the problem went away. A hard one.
You hadn't used array bounds checking?
On 13.09.2022 15.11, Robin Vowels wrote:
[...]
..That was the way to the solution. I found that C, X and Z were fine
You could try deallocating each one separately.
but it baulked at p. So I looked further and found that although I
had allocated p and r as p(3,NX) and r(3,NZ), in a routine I assigned
values to (p(0,i) and r(0,i), so I overwrote something. When I removed
that, the problem went away. A hard one.
You hadn't used array bounds checking?
I thought I did:
gfortran -o expexpsor.out -g -fcheck=bounds \
...
On 9/14/22 5:58 AM, db wrote:
gfortran -o expexpsor.out -g -fcheck=bounds \
It might be worth the effort to understand why the compiler did not
catch that array bounds mistake immediately.
On 13.09.2022 15.11, Robin Vowels wrote:
[...]
..That was the way to the solution. I found that C, X and Z were fine
You could try deallocating each one separately.
but it baulked at p. So I looked further and found that although I
had allocated p and r as p(3,NX) and r(3,NZ), in a routine I assigned
values to (p(0,i) and r(0,i), so I overwrote something. When I removed
that, the problem went away. A hard one.
You hadn't used array bounds checking?
I thought I did:
gfortran -o expexpsor.out -g -fcheck=bounds \
...
On Wednesday, September 14, 2022 at 8:42:56 AM UTC-7, Ron Shepard wrote:.
On 9/14/22 5:58 AM, db wrote:(snip)
I agree.gfortran -o expexpsor.out -g -fcheck=bounds \It might be worth the effort to understand why the compiler did not
catch that array bounds mistake immediately.
There are a number of ways to trick the bounds-check system.
Assumed size arrays can't check the upper bound,
but even for them,
I think it still checks the lower bound.
If you do separate compilation, you need bounds check on all.
It seems that it should either find a compiler bug, or some
unusual trick done by the program, that could cause problems.
On 9/14/2022 4:58 AM, db wrote:
On 13.09.2022 15.11, Robin Vowels wrote:
[...]
..That was the way to the solution. I found that C, X and Z were fine
You could try deallocating each one separately.
but it baulked at p. So I looked further and found that although I
had allocated p and r as p(3,NX) and r(3,NZ), in a routine I assigned
values to (p(0,i) and r(0,i), so I overwrote something. When I removed >>>> that, the problem went away. A hard one.
You hadn't used array bounds checking?
I thought I did:
gfortran -o expexpsor.out -g -fcheck=bounds \
...
That's why it's good to post a small program that reproduces the
problem; it helps everyone else see exactly what you're seeing.
Louis
On Thursday, September 15, 2022 at 2:17:46 AM UTC+10, gah4 wrote: h
On Wednesday, September 14, 2022 at 8:42:56 AM UTC-7, Ron Shepard wrote:
On 9/14/22 5:58 AM, db wrote:(snip)
I agree.gfortran -o expexpsor.out -g -fcheck=bounds \It might be worth the effort to understand why the compiler did not catch that array bounds mistake immediately.
There are a number of ways to trick the bounds-check system.
Assumed size arrays can't check the upper bound,.
Silverfrost F95 checks bounds for these arrays.
Someone trying one of my programs with Silverfrost told me years ago
that it wouldn't compile because i had tried to declare an integer variable with the smallest number of bits with selected-int-kind(0). Gfortran,
ifort and g95 all accepted ithat. Does Silverfrost still have that bug/feature?
Of course I changed my program to use selected_int_kind(1), but
I don't think selected-int-kind(0) should have been disallowed.
On 14.09.2022 19.22, Louis Krupp wrote:
On 9/14/2022 4:58 AM, db wrote:
On 13.09.2022 15.11, Robin Vowels wrote:
[...]
..That was the way to the solution. I found that C, X and Z were fine
You could try deallocating each one separately.
but it baulked at p. So I looked further and found that although I
had allocated p and r as p(3,NX) and r(3,NZ), in a routine I assigned >>>>> values to (p(0,i) and r(0,i), so I overwrote something. When I
removed
that, the problem went away. A hard one.
You hadn't used array bounds checking?
I thought I did:
gfortran -o expexpsor.out -g -fcheck=bounds \
...
That's why it's good to post a small program that reproduces the
problem; it helps everyone else see exactly what you're seeing.
Louis
You are right. But before I found the error I didn't know how to produce
a small program that caused it; and now that I know what did, it seems pointless. I doubt that it woulkd explain why the bounds check didn't complain. I use gfortran btw.
Someone trying one of my programs with Silverfrost told me years ago that it wouldn't compile because i had tried to declare an integer variable with the smallest number of bits with selected-int-kind(0) .You mean, selected_int_kind(0).
On Sunday, September 18, 2022 at 2:05:48 PM UTC+10, jfh wrote:
Someone trying one of my programs with Silverfrost told me years ago that it wouldn't compile because i had tried to declare an integer variable with the smallest number of bits with selected-int-kind(0) .You mean, selected_int_kind(0).
.
You wanted an integer variable capable of storing values between -1 and +1 ? In other words, you wanted an integer variable capable of storing the value 0 [i.e., zero].
You have to be joking.
On 9/18/22 4:28 AM, Robin Vowels wrote:
On Sunday, September 18, 2022 at 2:05:48 PM UTC+10, jfh wrote:
Someone trying one of my programs with Silverfrost told me years agoYou mean, selected_int_kind(0).
that it wouldn't compile because i had tried to declare an integer
variable with the smallest number of bits with selected-int-kind(0) .
.
You wanted an integer variable capable of storing values between -1
and +1 ?
In other words, you wanted an integer variable capable of storing the
value 0 [i.e., zero].
You have to be joking.
If there were ever a 1-bit integer kind introduced into the language,
then how would it be specified? selected_int_kind(1) would require at
least 5 bits, rounded up to 8-bits on most modern computers. So unless
the selected_int_kind() function is changed somehow (e.g. to specify
directly the minimum number of bits), asking for 0 decimal digits might
be the only way -- you ask for 0-bits and it would get rounded up to 1-bit.
$.02 -Ron Shepard
On Sunday, September 18, 2022 at 2:05:48 PM UTC+10, jfh wrote:
Someone trying one of my programs with Silverfrost told me years ago that it wouldn't compile because i had tried to declare an integer variable with the smallest number of bits with selected-int-kind(0) .You mean, selected_int_kind(0).
.
You wanted an integer variable capable of storing values between -1 and +1 ? In other words, you wanted an integer variable capable of storing the value 0 [i.e., zero].
You have to be joking.
On Sunday, September 18, 2022 at 9:28:11 PM UTC+12, Robin Vowels wrote:them. I note that the f2018 standard does not say that r has to be non-negative. And indeed the program below prints 127 with g95 and gfortran, showing that their lowest integer kind has 8 bits. (I don't have access to a computer with ifort this morning
On Sunday, September 18, 2022 at 2:05:48 PM UTC+10, jfh wrote:
I was not joking because selected_int_kind(1) requires all 19 integers n in the range -10 < n < +10 to be available. If there was a compiler allowing 4-bit integers, hence 16 different possible values, then selected_int_kind(0) would be a way to getSomeone trying one of my programs with Silverfrost told me years ago that it wouldn't compile because i had tried to declare an integer variable with the smallest number of bits with selected-int-kind(0) .You mean, selected_int_kind(0).
.
You wanted an integer variable capable of storing values between -1 and +1 ?
In other words, you wanted an integer variable capable of storing the value 0 [i.e., zero].
You have to be joking.
On 9/18/22 4:28 AM, Robin Vowels wrote:.
On Sunday, September 18, 2022 at 2:05:48 PM UTC+10, jfh wrote:
Someone trying one of my programs with Silverfrost told me years ago that it wouldn't compile because i had tried to declare an integer variable with the smallest number of bits with selected-int-kind(0) .You mean, selected_int_kind(0).
.
You wanted an integer variable capable of storing values between -1 and +1 ?
In other words, you wanted an integer variable capable of storing the value 0 [i.e., zero].
You have to be joking.
If there were ever a 1-bit integer kind introduced into the language,.
then how would it be specified?
selected_int_kind(1) would require at
least 5 bits, rounded up to 8-bits on most modern computers. So unless
the selected_int_kind() function is changed somehow (e.g. to specify
directly the minimum number of bits), asking for 0 decimal digits might
be the only way -- you ask for 0-bits and it would get rounded up to 1-bit.
On Monday, September 19, 2022 at 2:24:21 AM UTC+10, Ron Shepard wrote:
On 9/18/22 4:28 AM, Robin Vowels wrote: am
On Sunday, September 18, 2022 at 2:05:48 PM UTC+10, jfh wrote:
.Someone trying one of my programs with Silverfrost told me years ago that it wouldn't compile because i had tried to declare an integer variable with the smallest number of bits with selected-int-kind(0) .You mean, selected_int_kind(0).
.
You wanted an integer variable capable of storing values between -1 and +1 ?
In other words, you wanted an integer variable capable of storing the value 0 [i.e., zero].
You have to be joking.
If there were ever a 1-bit integer kind introduced into the language,.
then how would it be specified?
Well, selected_int_kind(0) won't do it, because the only value that
could be stored is '0'. And maybe -1 if 2 bits are allocated.
.
Might need a BIT type for that.
.
selected_int_kind(1) would require at
least 5 bits, rounded up to 8-bits on most modern compute
the selected_int_kind() function is changed somehow (e.g. to specify directly the minimum number of bits), asking for 0 decimal digits might
be the only way -- you ask for 0-bits and it would get rounded up to 1-bit.
You mean, selected_int_kind(0).
You wanted an integer variable capable of storing values between -1 and +1 ? In other words, you wanted an integer variable capable of storing the value 0 [i.e., zero].
You have to be joking.
I was not surprised that all three of those compilers print 127 four
times with this program, and they are standard-conforming in that
respect because none of those compilers has a 4-bit integer type.
My revised 4-line program:
integer, parameter:: ineg = selected_int_kind(-1), i0 = selected_int_kind(0),&
i1 = selected_int_kind(1), i2 = selected_int_kind(2)
print *, huge(0_ineg),huge(0_i0),huge(0_i1),huge(0_i2)
end program
On Sunday, September 18, 2022 at 10:43:36 PM UTC-7, jfh wrote:
(snip)
I was not surprised that all three of those compilers print 127 four
times with this program, and they are standard-conforming in that
respect because none of those compilers has a 4-bit integer type.
My revised 4-line program:
integer, parameter:: ineg = selected_int_kind(-1), i0 = selected_int_kind(0),&
i1 = selected_int_kind(1), i2 = selected_int_kind(2)
print *, huge(0_ineg),huge(0_i0),huge(0_i1),huge(0_i2)
end program
And especially that allows, in case anyone implemented it, a 4 bit type
that would not allow for selected_int_kind(1).
It would be nice to have a selector that allowed selecting the base
of the computation. (Not necessarily the base of the selected type.)
There could be machines with types that could not be distinguished
by whole decimal digits.
gah4 <ga...@u.washington.edu> schrieb:.
On Sunday, September 18, 2022 at 10:43:36 PM UTC-7, jfh wrote:
(snip)
I was not surprised that all three of those compilers print 127 four
times with this program, and they are standard-conforming in that
respect because none of those compilers has a 4-bit integer type.
My revised 4-line program:
integer, parameter:: ineg = selected_int_kind(-1), i0 = selected_int_kind(0),&
i1 = selected_int_kind(1), i2 = selected_int_kind(2)
print *, huge(0_ineg),huge(0_i0),huge(0_i1),huge(0_i2)
end program
And especially that allows, in case anyone implemented it, a 4 bit type that would not allow for selected_int_kind(1).
It would be nice to have a selector that allowed selecting the baseFor real types, you can select the radix with the corresponding
of the computation. (Not necessarily the base of the selected type.)
argument to SELECTED_REAL_KIND, if the hardware allows for it.
I suppose this is for decimal floats.
There could be machines with types that could not be distinguishedReal or complex arguments to SELECTED_INT_KIND, anybody?
by whole decimal digits.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 159 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 99:34:25 |
| Calls: | 3,209 |
| Files: | 10,563 |
| Messages: | 3,009,786 |