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.