[Bug fortran/35223] New: IBITS gives compiler error

[Bug fortran/35223] New: IBITS gives compiler error

[phl at kth dot se]

hades [TEST] cat bug-ibits.f90
program main
  write (*, *) ibits (-1, 0, bit_size (0))
end program main


hades [TEST] gfortran bug-ibits.f90
bug-ibits.f90:2.22:

  write (*, *) ibits (-1, 0, bit_size (0))
                     1
Error: Result of IBITS overflows its kind at (1)


hades [TEST] gfortran --version
GNU Fortran (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4)
Copyright (C) 2007 Free Software Foundation, Inc.


Of course, compiling with my mac-version of gfortran
gives the same result:

epsilon [TEST] gfortran bug-ibits.f90 
bug-ibits.f90:2.22:

  write (*, *) ibits (-1, 0, bit_size (0))
                     1
Error: Result of IBITS overflows its kind at (1)
epsilon [TEST] gfortran --version
GNU Fortran (GCC) 4.3.0 20071017 (experimental) [trunk revision 129405]
Copyright (C) 2007 Free Software Foundation, Inc.

Compiling with g95 works fine though.

Sincerely
   PHL


-- 
           Summary: IBITS gives compiler error
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: phl at kth dot se


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223

[Bug fortran/35223] IBITS gives compiler error

[jvdelisle at verizon dot net]

------- Comment #1 from jvdelisle at verizon dot net  2008-02-17 00:21 -------
Subject: Re:   New: IBITS gives compiler error

phl at kth dot se wrote:
> hades [TEST] cat bug-ibits.f90
> program main
>   write (*, *) ibits (-1, 0, bit_size (0))
> end program main
> 
> 
> hades [TEST] gfortran bug-ibits.f90
> bug-ibits.f90:2.22:
> 
>   write (*, *) ibits (-1, 0, bit_size (0))
>                      1
> Error: Result of IBITS overflows its kind at (1)

Use -fno-range-check when you compile.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223

[Bug fortran/35223] IBITS gives compiler error

[kargl at gcc dot gnu dot org]

------- Comment #2 from kargl at gcc dot gnu dot org  2008-02-17 01:08 -------
(In reply to comment #0)
> hades [TEST] cat bug-ibits.f90
> program main
>   write (*, *) ibits (-1, 0, bit_size (0))
> end program main
> 

(snip)

What result do you expect?

> Compiling with g95 works fine though.

Appears g95 may have a bug.  See Sec. 13.3, 13.4, and most importantly
13.7 in the 'Final Committee Draft J3/03-007R2' of the Fortran 2003
standard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223

[Bug fortran/35223] IBITS gives compiler error

[phl at kth dot se]

------- Comment #3 from phl at kth dot se  2008-02-17 05:18 -------
Subject: Re:  IBITS gives compiler error

>
>
> ------- Comment #2 from kargl at gcc dot gnu dot org  2008-02-17 01:08
> -------
> (In reply to comment #0)
>> hades [TEST] cat bug-ibits.f90
>> program main
>>   write (*, *) ibits (-1, 0, bit_size (0))
>> end program main
>>
>
> (snip)
>
> What result do you expect?


In this case I expect a running program to print "-1".


>
>> Compiling with g95 works fine though.
>
> Appears g95 may have a bug.  See Sec. 13.3, 13.4, and most importantly
> 13.7 in the 'Final Committee Draft J3/03-007R2' of the Fortran 2003
> standard.


In that case a lot of compilers have the same bug. :-)
Appears more likely gfortran has a bug.
Pasting from the f90-standard:

"13.13.42  IBITS (I, POS, LEN)  Description.  Extracts a sequence of bits.
 Class.  Elemental function.  Arguments.  I  must be of type integer.  POS
 must be of type integer.  It must be nonnegative and POS + LEN must be
less  than or equal to BIT_SIZE (I).  LEN  must be of type integer and
nonnegative.  Result Type and Type Parameter.  Same as I.  Result Value. 
The result has the value of the sequence of LEN bits in I beginning at bit
POS right-  adjusted and with all other bits zero.  The model for the
interpretation of an integer value as a  sequence of bits is in 13.5.7. 
Example.  IBITS (14, 1, 3) has the value 7."

To conclude, the error message is incorrect.

Regards
   PHL


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223

[Bug fortran/35223] IBITS gives compiler error

[kargl at gcc dot gnu dot org]

------- Comment #4 from kargl at gcc dot gnu dot org  2008-02-17 06:38 -------
(In reply to comment #3)
> Subject: Re:  IBITS gives compiler error
 > ------- Comment #2 from kargl at gcc dot gnu dot org  2008-02-17 01:08
> > -------
> > (In reply to comment #0)
> >> hades [TEST] cat bug-ibits.f90
> >> program main
> >>   write (*, *) ibits (-1, 0, bit_size (0))
> >> end program main
> >>
> >
> > (snip)
> >
> > What result do you expect?
> 
> 
> In this case I expect a running program to print "-1".
> 
> 
> >
> >> Compiling with g95 works fine though.
> >
> > Appears g95 may have a bug.  See Sec. 13.3, 13.4, and most importantly
> > 13.7 in the 'Final Committee Draft J3/03-007R2' of the Fortran 2003
> > standard.
> 
> In that case a lot of compilers have the same bug. :-)
> Appears more likely gfortran has a bug.
> Pasting from the f90-standard:
> 
> "13.13.42  IBITS (I, POS, LEN)  Description.

I know what 13.13.42 says.  I also know what 13.5.7 in the F95
standard says about the model numbers that are used by IBITS:

    Effectively, this model defines an integer object to consist of z bits
    in sequence numbered from right to left from 0 to z - 1 . This model
    is valid only in the context of the use of such an object as the argument
    or result of one of the bit manipulation procedures. In all other contexts,
    the model defined for an integer in 13.7.1 applies.

and 13.14 from the Fortran 95 standard says

    This section contains detailed specifications of the generic intrinsic
    procedures in alphabetical order.  The types and type parameters of
    intrinsic procedure arguments and function results are determined by
    these specifications.  A program is prohibited from invoking an intrinsic
    procedure under circumstances where a value to be returned in a subroutine
    argument or function result is outside the range of values representable
    by objects of the specified type and type parameters.

Read that last sentence carefully.  You, as the programmer, are prohibited
from calling an intrinsic procedure if it will return a value outside the
representable range.

Now, go read about the model numbers for the bit intrinsics and for integers.
The bit intrinsic model numbers do not have a sign bit, and you're asking 
IBITS to return 2**32, which is outside of the range for gfortran's default
integer kind.

Also note, that a compiler is not required to detect the programming error.
It can in fact do anything including what you expect as well as report an
error.

> 
> To conclude, the error message is incorrect.
>

You conclusion is wrong.

Jerry already told you how to disable the error with -fno-range-check
option.  But, you should probably think about fixing your program.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sgk at troutmask dot apl dot
                   |                            |washington dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223

[Bug fortran/35223] IBITS gives compiler error

[phl at kth dot se]

------- Comment #5 from phl at kth dot se  2008-02-17 11:55 -------
Subject: Re:  IBITS gives compiler error


> The bit intrinsic model numbers do not have a sign bit, and you're asking
> IBITS to return 2**32, which is outside of the range for gfortran's
> default
> integer kind.
>


Actually it is supposed to just return the first 32 bits of
the integer "-1" = (1111...1)_2 and interpret it as "-1".

What about replacing the IBITS statement with "NOT (0)" or
"IAND (-1, -1)", or "IOR (-1, 0)" these would then also fall
outside the range and not work either?

However, they all work fine with version
"GNU Fortran (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4)"
and they print "-1". On the other hand I get

/usr/bin/ld: warning can't open dynamic library: /libgcc_s.1.dylib
referenced from:
/usr/local/gfortran/lib/gcc/powerpc-apple-darwin8.10.0/4.3.0/../../../libgfortran.dylib
(checking for undefined symbols may be affected) (No such file or
directory, errno = 2)

when I run it on my mac with version
"GNU Fortran (GCC) 4.3.0 20071017 (experimental) [trunk revision 129405]"

but perhaps that also as it should be?

Regards
   /PHL


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223

[Bug fortran/35223] IBITS gives compiler error

[dominiq at lps dot ens dot fr]

------- Comment #6 from dominiq at lps dot ens dot fr  2008-02-17 13:10 -------
I dont want to rant again about gfortran feature, but nevertheless I'll repeat
that this error should not be the default behavior (even a warning will an
overkill that should be restricted to -std=f* -pedantic).

Now I think the gfortran behavior is inconsistent with this respect. The
following code

print *, not(0), iand(-1,-1)!, ibits (-1, 0, bit_size (0))
print *, ibset(2147483647, bit_size(0)-1)
end

compiles silently and the executable prints:

          -1          -1
          -1

Why 2**32-1 should give an error as the result of ibits(-1, 0, bit_size (0))
and -1 as the result of ibset(2147483647, bit_size(0)-1)?

Looking at the f2003 standard (just before 13.4), I read:

Effectively, this model defines an integer object to consist of z bits in
sequence numbered from right to left from 0 to z − 1. This model is valid
only in the context of the use of such an object as the argument or result of
one of the bit manipulation procedures. In all other contexts, the model
defined for an integer in 13.4 applies. In particular, whereas the models are
identical for w_{z−1} = 0, they do not correspond for w_{z−1} = 1
and the interpretation of bits in such objects is processor dependent.

As usual, the last sentence shows the infinite wisdom of  the committee, but
does not say that w_{z−1} = 1 is forbidden, nor that the "processor"
should throw an error. According my understanding of the "least surprise
effect", I think gfortran should follow the other compilers and consider that
outside the "bit pattern" context, w_{z−1} = 1 corresponds to "s=-1" in
the integer model defined in 13.4.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223

[Bug fortran/35223] IBITS gives compiler error

[dominiq at lps dot ens dot fr]

------- Comment #7 from dominiq at lps dot ens dot fr  2008-02-17 13:15 -------
/z−1/z-1/


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223

[Bug fortran/35223] IBITS gives compiler error

[sgk at troutmask dot apl dot washington dot edu]

------- Comment #8 from sgk at troutmask dot apl dot washington dot edu  2008-02-17 18:09 -------
Subject: Re:  IBITS gives compiler error

On Sun, Feb 17, 2008 at 01:10:06PM -0000, dominiq at lps dot ens dot fr wrote:
> 
> I dont want to rant again about gfortran feature, but nevertheless I'll repeat
> that this error should not be the default behavior (even a warning will an
> overkill that should be restricted to -std=f* -pedantic).

You're more than welcomed to submit a patch.

> Now I think the gfortran behavior is inconsistent with this respect. The
> following code
> 
> print *, not(0), iand(-1,-1)!, ibits (-1, 0, bit_size (0))
> print *, ibset(2147483647, bit_size(0)-1)
> end
> 
> compiles silently and the executable prints:
> 
>           -1          -1
>           -1
> 
> Why 2**32-1 should give an error as the result of ibits(-1, 0, bit_size (0))
> and -1 as the result of ibset(2147483647, bit_size(0)-1)?

I don't remember the details for NOT() other than the simplification
isn't simply because of the internal representation with GMP and 
GMP does not have a mpz_not function.  So, NOT() may accidentally get
the expected answer.  I'm unfamiliar with the other functions you 
mentioned.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223

[Bug fortran/35223] IBITS gives compiler error

[jvdelisle at gcc dot gnu dot org]

------- Comment #9 from jvdelisle at gcc dot gnu dot org  2008-02-17 19:10 -------
We do need to fix some things here.  The runtime perhaps should catch the
invalid of pos + len > 32 for bit_size being 32.

Also from my read of the standard the ibits is extracting bits from (in this
case) a 32 bit integer interpreted as unsigned since it just looks at bits and
the result is plugging the resulting 32 bits back into a signed 32 bit word. 
The key to this is interpreting the plugging back in to treat the receiving
words sign bit as one of those 32 bits or not.

"This model is valid only in the context of the use of such an object as the
argument or result of one of the bit manipulation procedures."

I think Steve has a good point.  I also think that the result is type integer
with a sequence of bits fitting the model of 13.3 mapped into the model for
13.4 if used in a numerical context, in this case WRITEing an integer.

So I support removing the range check just for these bit manipulation
procedures.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223

[Bug fortran/35223] IBITS gives compiler error

[dominiq at lps dot ens dot fr]

------- Comment #10 from dominiq at lps dot ens dot fr  2008-02-17 19:56 -------
> I don't remember the details for NOT() other than the simplification
> isn't simply because of the internal representation with GMP and 
> GMP does not have a mpz_not function.  So, NOT() may accidentally get
> the expected answer.  I'm unfamiliar with the other functions you 
> mentioned.

I think the basic problem with all the bit-manipulation intrinsics it that they
does not make sense outside an unsigned integer model which does not exist in
FORTRAN outside this context. 

The f9* standard should have added unsigned integer along with the bit
manipulations, this would have avoided their embarrassment between 13.3 and
13.4.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223

[Bug fortran/35223] IBITS gives compiler error

[sgk at troutmask dot apl dot washington dot edu]

------- Comment #11 from sgk at troutmask dot apl dot washington dot edu  2008-02-17 19:59 -------
Subject: Re:  IBITS gives compiler error

On Sun, Feb 17, 2008 at 07:10:19PM -0000, jvdelisle at gcc dot gnu dot org
wrote:
> ------- Comment #9 from jvdelisle at gcc dot gnu dot org  2008-02-17 19:10 -------
> We do need to fix some things here.  The runtime perhaps should catch the
> invalid of pos + len > 32 for bit_size being 32.
> 

(snip)

> So I support removing the range check just for these bit manipulation
> procedures.

Yes, that is probably a good compromise, then let the middle-end
deal with possible out of range values.  One probably needs to
check the expansion of 

  i = -1
  i = ibits(i,0,32)

-fdump-tree-original shows

  i = -1;
  i = i >> 0 & ~(-1 << 32);

for the above, which of course gives the user desired result of -1.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223

[Bug fortran/35223] IBITS gives compiler error

[jvdelisle at gcc dot gnu dot org]

------- Comment #12 from jvdelisle at gcc dot gnu dot org  2008-02-17 22:50 -------
The fix is straight forward.  I will take care of this when 4.4 opens


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-02-17 22:50:12
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223

[Bug fortran/35223] IBITS gives compiler error

[jvdelisle at gcc dot gnu dot org]

------- Comment #13 from jvdelisle at gcc dot gnu dot org  2008-02-17 22:50 -------
Assigning to myself


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-02-17 22:50:12         |2008-02-17 22:50:53
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223

[Bug fortran/35223] IBITS gives compiler error

[burnus at gcc dot gnu dot org]

------- Comment #14 from burnus at gcc dot gnu dot org  2008-02-18 07:45 -------
> Error: Result of IBITS overflows its kind at (1)

I wonder whether one should also add to simplify.c's range_check
"Result of %s overflows its kind at %L"
the following
". This check can be disabled with the option -fno-range-check"

(That is independent of the removal of the bit manipulations range check.)


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223

[Bug fortran/35223] IBITS gives compiler error

[jvdelisle at gcc dot gnu dot org]

------- Comment #15 from jvdelisle at gcc dot gnu dot org  2008-02-24 19:19 -------
Subject: Bug 35223

Author: jvdelisle
Date: Sun Feb 24 19:18:27 2008
New Revision: 132597

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132597
Log:
2008-02-24  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR fortran/35223
        * simplify.c (gfc_simplify_ibclr), (gfc_simplify_ibits),
        (gfc_simplify_ibset): Remove call to range_check.
        (simplify_cmplx), (gfc_simplify_dble), (gfc_simplify_float)
        (gfc_simplify_real): Add call gfc_clear_ts to initialize the
        temporary gfc_typspec variable.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/simplify.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223

[Bug fortran/35223] IBITS gives compiler error

[jvdelisle at gcc dot gnu dot org]

------- Comment #16 from jvdelisle at gcc dot gnu dot org  2008-02-24 19:45 -------
Fixed on trunk, Thanks for report.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223