This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [PATCH] PR 78534 Change character length from int to size_t
- From: Andre Vehreschild <vehre at gmx dot de>
- To: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Fortran List <fortran at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 21 Dec 2016 12:50:14 +0100
- Subject: Re: [PATCH] PR 78534 Change character length from int to size_t
- Authentication-results: sourceware.org; auth=none
- References: <CAO9iq9Ezp4MhhMzgLCkRsbwANE0a=m2a5TJe-CP=caAVHO56NQ@mail.gmail.com> <CAO9iq9GNtY8fXTUCV5CtxTtMNVx2zLXaFPPJV8pOxqhTA_0fGQ@mail.gmail.com> <20161216163454.3b061cdd@vepi2> <CAO9iq9EDVe=c0KtH1UjZgomPj0OFq-4UAeko+uRmxTrvk+mr8Q@mail.gmail.com> <20161220144216.0891f455@vepi2> <CAO9iq9ErjvjbE1mvR1dw==_oPBjmJgiA7x6WhR68Fcn36Wv5JA@mail.gmail.com> <20161220150019.GH21933@tucnak> <20161220162907.15f8c075@vepi2> <20161220154013.GI21933@tucnak> <20161220170454.283cef46@vepi2> <20161220160854.GJ21933@tucnak> <20161221110519.472f97be@vepi2> <CAO9iq9G0s=gLb5QL_Rsona+=BnDp-=dMC0H3-asqRyD2_BM6JQ@mail.gmail.com> <20161221113329.636333ac@vepi2> <CAO9iq9GkT7b_CWO_6WDSFSEoXNoatk=FGtU0R=f0WEGRGZx6-w@mail.gmail.com>
> Here p is the character variable, and _p is the charlen. My guess is
> that the problem is that with -O1 it sees that the second memmove
> would overflow p, but it doesn't realize that branch is never taken.
> Cranking up the optimization level to -O2 and beyond makes it realize
> it, and thus the warning disappears.
>
> Perhaps one could rewrite that to something like
>
> __builtin_memmove ((void *) *p, (void *) &"12345679"[1]{lb: 1 sz: 1},
> MIN_EXPR<(unsigned long) D.3598,8>);
> if ((unsigned long) D.3598 > 8)
> {
> __builtin_memset ((void*) *p + 8, 32, D.3599);
> }
That looks interesting. It assumes though, that D.3598 will *never* be
negative. Because when it is negative 8 characters (cast to unsigned makes the
negative number huge) will be copied, while in the former code memmove will
reject the coping of a negative number of bytes. Therefore I propose to omit
the cast in the MIN_EXPR and make the constant 8 signed, too. That should
comply and mimick the former behavior more closely. What do you think? Who's
going to try?
--
Andre Vehreschild * Email: vehre ad gmx dot de