This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Heads-up, PR53273: testsuite separation and dilution problem. Fix for PR53272


> From: Richard Guenther <richard.guenther@gmail.com>
> Date: Tue, 8 May 2012 10:50:43 +0200

> On Tue, May 8, 2012 at 5:39 AM, Hans-Peter Nilsson
> <hans-peter.nilsson@axis.com> wrote:
> > The problem was spotted while fixing PR53272, a target bug with
> > crisv32-* involving the error-prone notice_update_cc function.
> >
> > When wrapping up the test-case to use as a run-test, adding main
> > and auxiliary functions to the reduced test-case unexpectedly
> > made the bug go away. ?This despite all functions (except main)
> > being decorated with noinline, noclone and the special marker
> > asm ("") ad finitum.
> > ...
> > Can we just have a way to
> > limit those pesky cross-function optimizations and all their kin
> > once and for all?
> 
> You don't say what actually is different when you add these functions.

I've looked further and added details in PR53273.  Basically,
GCC sneaked a peek at a neighboring function that was
unconditionally called, spotted a noreturning function and
optimized according to that.  While this was an erroneous
partial edit (unconditional aborting), I can probably make a
(re)throwing test-case with the similar unwanted difference in
generated code.

> There should be no IPA optimizations possible unless you tell GCC
> that it sees the whole program (which means using -flto with the
> linker plugin).  That is, marking functions noclone and noinline and
> avoiding declaring them static should be enough.
> 
> Still some pieces of GCC may expose different code generation due to
> DECL uid differences - which, as DECL uids are global, makes extra
> functions possibly result in different code for unchanged functions.  That's
> generally not wanted but it can happen (similar for other such kinds of
> numbers).

Nope, not here; just a noreturn optimization unexpectedly (and
generally when wrapping test-cases unwantedly) applied.  How do
we stop that?  If you say "just add -fno-ipa" (or whatever
option) I say "will that stop *all* future cross-function
optimizations"?  (And to keep test-case integrity, better add it
to existing test-cases.)

brgds, H-P


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]