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: unassig...@gcc.gnu.org
        ReportedBy: bur...@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.

Reply via email to