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.
