http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604
Thomas Koenig <tkoenig at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |UNCONFIRMED Ever confirmed|1 |0 --- Comment #7 from Thomas Koenig <tkoenig at gcc dot gnu.org> --- (In reply to Steve Kargl from comment #5) > On Fri, Dec 27, 2013 at 07:53:00PM +0000, tkoenig at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604 > > > > Thomas Koenig <tkoenig at gcc dot gnu.org> changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > Blocks| |58003 > > > > --- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> --- > > (In reply to kargl from comment #2) > > > (In reply to Thomas Koenig from comment #1) > > > > TRANSFER gets this right. > > > > > > It is unclear what you mean here. > > > > What I mean is that > > > > program test > > if (transfer(z'FFFFFFFF',1) /= -1) call abort > > end program test > > > > does not call abort. > > I suspect that the above is not portable as transfer() simply copies > bits. z'FFFFFFF' is an integer(8) (or integer(16)) entity. Transfer() > is copying 32-bits from that entity. It is clear from the > -fdump-tree-original that middle-end is "converting" the resulting > 32-bit thing into -1. So, you're relying on twos-complement wrap > around semantics. As gcc supports only twos complement arithmetic, I think this is OK.