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 14:14:03 +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> <20161221125014.0e8abe26@vepi2> <CAO9iq9Hdwb1A3DyOnEcTeQZgF8BZwomtwGd2JVSZhrnGhS1CNQ@mail.gmail.com>
> Now when I think about this some more, I have a vague recollection
> that a long time ago it used to be something like that. The problem
> is that MIN_EXPR<CONSTANT, NON-CONSTANT> will of course be
> NON-CONSTANT, so the memcpy call can't be inlined. Hence it was
> changed to two separate __builtin_memmove() calls to have better
> opportunity to inline. So probably a no-go to change it back. :(
I don't get that. From the former only one of the memmove's could have been
inlined assuming that only CONSTANT sizes are inlined. The other one had a
NON-CONSTANT as long as pointer following and constant propagation was not
effective together. In our case the "NON-CONSTANT branch" would have been used,
which is resolved by constant propagation (of the size of constant memory p
points to). I assume the warning is triggered, because dead-code elimination
has not removed the else part.
Following this thought the MIN_EXPR would be propagated to 5 and the inliner
can do its magic. Albeit it may be that now some other optimization level will
trigger a warning, because some part has not been removed/constant replaced.
What do you think of that?
--
Andre Vehreschild * Email: vehre ad gmx dot de