[Bug fortran/54072] New: BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND

[Bug fortran/54072] New: BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND

[burnus at gcc dot gnu.org]

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

             Bug #: 54072
           Summary: BOZ with -std=f2008: wrongly accepted to
                    TRANSFER/ABS/...; two BOZ not rejected for
                    IOR/IEOR/IAND
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org


Motivated by the question at
http://www.rhinocerus.net/forum/lang-fortran/710304-why-does-boz-literal-work-ok-transfer-call-but-not-declarationwith-gfortran.html

Note that for INT(<overflowing BOZ>) the standard has: "If A is a
boz-literal-constant, the value of the result is the value whose bit sequence
according to the model in 13.3 is the same as that of A as modified by padding
or truncation according to 13.3.3. The interpretation of a bit sequence whose
most significant bit is 1 is processor dependent." - Thus, printing an error
should be fine.

 * * *

Fortran 2008 only allows BOZ at:

"C4102 (R463) A boz-literal-constant shall appear only as a data-stmt-constant
in a DATA statement, or where explicitly allowed in subclause 13.7 as an actual
argument of an intrinsic procedure."

If one looks for "BOZ" for TRANSFER, one finds nothing:

   SOURCE shall be a scalar or array of any type.

Thus, I think one has to conclude that it is not allowed. - But gfortran
silently accepts it.  Similarly for, e.g., ABS.

 * * *

The following is accepted
  print *, ior(z'111',z'010')

However, the standard requires:
  I and J shall not both be boz-literal-constants.
Similarly for iand and ieor. However, two BOZ to dshiftr are properly rejected.

[Bug fortran/54072] BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-07-23 12:46:18 UTC ---
Misleading error message:

   Error: Extension: BOZ literal at (1) outside a DATA statement and outside
          INT/REAL/DBLE/CMPLX 

As comment 0 shows, there are now many more intrinsics where BOZ literals are
allowed. The message text should be updated.

[Bug fortran/54072] BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-07-23 13:17:33 UTC ---
Currently, gfortran prints the following error message if the BOZ exceeds (for
integers) the positive value:

Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1). This
check can be disabled with the option -fno-range-check 


That perfectly matches the behaviour of Fortran 95, which had:

"If a data-statement-constant is a boz-literal-constant, the corresponding
object shall be of type integer. A data-stmt-constant that is a
boz-literal-constant is treated as if the constant were an int-literalconstant
with a kind-param that specifies the representation method with the largest
decimal exponent range supported by the processor."


I am not sure that the message text is the best for Fortran 2008, which has for
DATA:

"If a data-stmt-constant is a boz-literal-constant, the corresponding variable
shall be of type integer. The boz-literal-constant is treated as if it were
converted by the intrinsic function INT (13.7.81) to type integer with the kind
type parameter of the variable"

And for INT see the text quoted in comment 0, i.e. it is "is processor
dependent".

[Bug fortran/54072] BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-07-23 13:44:47 UTC ---
(In reply to comment #1)
> Misleading error message:
>    Error: Extension: BOZ literal at (1) outside a DATA statement and outside
>           INT/REAL/DBLE/CMPLX 
> As comment 0 shows, there are now many more intrinsics where BOZ literals are
> allowed. The message text should be updated.

http://gcc.gnu.org/onlinedocs/gfortran/BOZ-literal-constants.html has a similar
issue: It also only lists the 4 Fortran 2003 intrinsics; one should mention
that some additional Fortran 2008 intrinsics also accept BOZ.

[Bug fortran/54072] BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-09-03
     Ever confirmed|0                           |1

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmed at revision 202213. Note that for IAND, IOR, ..., the constraint is a
'shall', i.e., according my understanding of the standard, the burden is on the
user not on the compiler.