On Tue, May 18, 2021 at 1:26 PM Richard Earnshaw via Gcc-patches
wrote:
>
>
>
> On 17/05/2021 21:52, Hans-Peter Nilsson wrote:
> > On Thu, 13 May 2021, Richard Earnshaw via Gcc-patches wrote:
> >>
> >> Normally we expect the gimple optimizers to fold away comparisons that
> >> are always true, but
On Tue, 18 May 2021, Richard Earnshaw wrote:
> On 17/05/2021 21:52, Hans-Peter Nilsson wrote:
> > On Thu, 13 May 2021, Richard Earnshaw via Gcc-patches wrote:
> > >
> > > Normally we expect the gimple optimizers to fold away comparisons that
> > > are always true, but at some lower optimization lev
On 17/05/2021 21:52, Hans-Peter Nilsson wrote:
On Thu, 13 May 2021, Richard Earnshaw via Gcc-patches wrote:
Normally we expect the gimple optimizers to fold away comparisons that
are always true, but at some lower optimization levels this is not
always the case, so the back-end has to be abl
On Thu, 13 May 2021, Richard Earnshaw via Gcc-patches wrote:
>
> Normally we expect the gimple optimizers to fold away comparisons that
> are always true, but at some lower optimization levels this is not
> always the case, so the back-end has to be able to generate correct
> code in these cases.
>
Normally we expect the gimple optimizers to fold away comparisons that
are always true, but at some lower optimization levels this is not
always the case, so the back-end has to be able to generate correct
code in these cases.
In this example, we have a comparison of the form
(unsigned long lo
