• Deallocate problem

    From db@21:1/5 to All on Sun Sep 11 15:52:32 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to All on Sun Sep 11 07:37:04 2022
    Are some of the values pointers? For example, if p and r are pointers to the same target,
    deallocating a pointer target causes the pointer association status of any other pointer that is associated with the target or a portion of the target to become undefined. So once p is deallocated r is indefined. That is just one possibility.

    How are the values defined and what declaration do they have?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to All on Sun Sep 11 09:44:39 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Louis Krupp@21:1/5 to All on Sun Sep 11 13:25:12 2022
    On 9/11/2022 7:52 AM, 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?

    Can you post a small, complete program that reproduces the problem?

    Louis

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to All on Sun Sep 11 12:16:52 2022
    On Sunday, September 11, 2022 at 9:52:36 AM UTC-4, db wrote:
    ..
    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?

    @db,

    Re: "Any idea why?," you can best answer the question by yourself.

    If you have a processor supporting Fortran 2003 or newer version of the standard, you can try introducing the ERRMSG= argument to your DEALLOCATE statement and check the message to see if that helps you figure out the problem.

    You can also try to deallocate the objects one by one with the ERRMSG= option and see if that helps.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From db@21:1/5 to Robin Vowels on Mon Sep 12 15:43:12 2022
    On 11.09.2022 18.44, Robin Vowels wrote:
    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.

    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.

    Thank you all.

    --
    Dieter Britz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to someone on Mon Sep 12 09:29:41 2022
    On Monday, September 12, 2022 at 6:43:16 AM UTC-7, db wrote:

    (snip, someone 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.

    The C deallocation funtion, free(), does not need to be told how long the variable being deallocated is. A popular implementation puts just before
    the actual array. Assigning one or two elements before the start of the
    array destroys that, or sometimes the address of the next array, and
    so free() fails in some bad ways.

    Random stores outside the array are less likely to cause this, though that means easier to miss during debugging.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to All on Tue Sep 13 06:11:03 2022
    On Monday, September 12, 2022 at 11:43:16 PM UTC+10, db wrote:
    On 11.09.2022 18.44, Robin Vowels wrote:
    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.
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From db@21:1/5 to Robin Vowels on Wed Sep 14 12:58:18 2022
    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 \

    ...


    --
    Dieter Britz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to All on Wed Sep 14 10:42:52 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Ron Shepard on Wed Sep 14 09:17:44 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Louis Krupp@21:1/5 to All on Wed Sep 14 11:22:25 2022
    On 9/14/2022 4: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 \

    ...



    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to All on Wed Sep 14 11:36:44 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From db@21:1/5 to Louis Krupp on Sat Sep 17 13:24:29 2022
    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:
    [...]
    .
    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 \

    ...



    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.

    --
    Dieter Britz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jfh@21:1/5 to Robin Vowels on Sat Sep 17 21:05:46 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to jfh on Sat Sep 17 21:31:23 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Louis Krupp@21:1/5 to All on Sun Sep 18 02:51:45 2022
    On 9/17/2022 5:24 AM, db wrote:
    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:
    [...]
    .
    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 \

    ...



    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.


    Having an example where bounds checking apparently failed might be
    interesting. You never know.

    Louis

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to jfh on Sun Sep 18 02:28:09 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to Robin Vowels on Sun Sep 18 11:24:16 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gary Scott@21:1/5 to Ron Shepard on Sun Sep 18 15:25:57 2022
    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...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jfh@21:1/5 to Robin Vowels on Sun Sep 18 16:28:29 2022
    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.)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jfh@21:1/5 to jfh on Sun Sep 18 16:49:00 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Ron Shepard on Sun Sep 18 19:09:58 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jfh@21:1/5 to Robin Vowels on Sun Sep 18 22:43:34 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Robin Vowels on Sun Sep 18 22:29:26 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to jfh on Mon Sep 19 09:34:20 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to gah4@u.washington.edu on Tue Sep 20 05:32:39 2022
    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 :-)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Thomas Koenig on Mon Sep 19 23:43:26 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)