On 9/14/22 5:58 AM, db wrote:
> On 13.09.2022 15.11, Robin Vowels wrote:
> [...]
>>>> .
>>>> 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.
>> .
>> You hadn't used array bounds checking?
>
> I thought I did:
>
> 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.

$.02 -Ron Shepard

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)

> > 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.

I agree.

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 Thursday, September 15, 2022 at 2:17:46 AM UTC+10, gah4 wrote:
> 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)
> > > 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.
> I agree.
>
> 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.
..
> 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 Thursday, September 15, 2022 at 6:36:47 AM UTC+12, Robin Vowels wrote:
> 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)
> > > > 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.
> > I agree.
> >
> > 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 Saturday, September 17, 2022 at 9:05:48 PM UTC-7, jfh wrote:

(snip)

> 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.

I suppose I believe that negative ones shouldn't be allowed, but zero
seems like it should work.

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 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.

$.02 -Ron Shepard

On 9/18/2022 11:24 AM, Ron Shepard wrote:
> 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.
>
> $.02 -Ron Shepard
>
Careful, bit strings will raise its ugly head again...

On Sunday, September 18, 2022 at 9:28:11 PM UTC+12, 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.

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 get 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 to test what it would do.)

On Monday, September 19, 2022 at 11:28:31 AM UTC+12, jfh wrote:
> On Sunday, September 18, 2022 at 9:28:11 PM UTC+12, 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.
> 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 get 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 to test what it would do.)

Sorry, I forgot to provide the 3-line program:

integer, parameter:: ifew = selected_int_kind(-1)
print *, huge(0_ifew)
end program

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:
> > 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 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 Sunday, September 18, 2022 at 2:28:11 AM UTC-7, Robin Vowels wrote:

(snip)

> 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.

No. It is supposed to be a kind that can hold at least that many digits.

But okay, a selected_int_kind(1) should hold at least between -9 and +9.

Selected_int_kind(0) could be less, or maybe not.

On Monday, September 19, 2022 at 2:10:00 PM UTC+12, Robin Vowels wrote:
> 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

s. 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.

Robin Vowels seems to assume that selected_int_kind(0) is asking for an integer kind that can only provide integers n such that -1 < n < 1. It is not.. It is asking for the integer kind with the least decimal exponent range that includes 0. I have now found that ifort agrees with gfortran and g95 by giving 8-bit integers with huge = 127. If Robin were right then selected_int_kind(1) would give an integer type that allows -10 < n < 10 but not one that allows -100 < n < 100. 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 <gah4@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 base
> of the computation. (Not necessarily the base of the selected type.)

For real types, you can select the radix with the corresponding
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 distinguished
> by whole decimal digits.

Real or complex arguments to SELECTED_INT_KIND, anybody? A base
of 2i sounds really promising (and Knuth proposed it, so it
must be good :-)

On Tuesday, September 20, 2022 at 3:32:42 PM UTC+10, Thomas Koenig wrote:
> 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 base
> > of the computation. (Not necessarily the base of the selected type.)
> For real types, you can select the radix with the corresponding
> 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 distinguished
> > by whole decimal digits.
> Real or complex arguments to SELECTED_INT_KIND, anybody?
..
PL/I has had COMPLEX integer (as well as COMPLEX FLOAT)
SINCE 1966.