This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: O2 Agressive Optimisation by GCC
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: David Brown <david at westcontrol dot com>
- Cc: Umesh Kalappa <umesh dot kalappa0 at gmail dot com>, Richard Biener <richard dot guenther at gmail dot com>, gcc at gcc dot gnu dot org, Martin Sebor <msebor at gmail dot com>
- Date: Mon, 23 Jul 2018 07:23:48 -0500
- Subject: Re: O2 Agressive Optimisation by GCC
- References: <CAGfacvTvkR6d+dqG0Et04gxqcz9JcH3JV1vi8S=WbfJbOnv3JA@mail.gmail.com> <5b6864e6-8256-756b-54b3-29d2e949c72e@gmail.com> <26C0A936-A52F-422B-9772-54B8A53E5341@gmail.com> <CAGfacvS=nj2RpoH=dynjRCxzS2TNCtBeu=ScjyXO0oLLOZjRug@mail.gmail.com> <5B55AFC2.5020503@westcontrol.com>
Hi!
On Mon, Jul 23, 2018 at 12:36:50PM +0200, David Brown wrote:
> This is nothing to do with undefined behaviour, but a matter of
> scheduling of effects that are visible in different circumstances. In
> particular, i and j are declared in a way that tells the compiler that
> the compiler, in its current thread of execution has full control of
> them. The compiler knows that while it is executing the code in test,
> nothing else can affect the value of i or j, nor can they be affected by
> the values of i and j. The compiler knows that code from elsewhere may
> read or write them, but only before test() is called, during functions
> called from test(), or after test() returns. It knows for sure that
> there are no other threads of execution that interact via i and j.
It could in theory know that, yes, but in this case it just hoists the
assignment to after the loop. And it's an infinite loop, so it just
disappears.
> So how do you inhibit these kinds of optimisations? Stop lying to your
> compiler.
Yup :-)
Segher