This is the mail archive of the
mailing list for the GCC project.
Re: How to avoid constant propagation into functions?
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Alexander Monakov <amonakov at ispras dot ru>, Georg-Johann Lay <avr at gjlay dot de>, Tim Prince <n8tm at aol dot com>, gcc at gcc dot gnu dot org
- Date: Wed, 14 Dec 2016 18:27:46 +0100
- Subject: Re: How to avoid constant propagation into functions?
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <20161207121400.GM2767@gate.crashing.org> <email@example.com> <20161207124232.GN2767@gate.crashing.org> <alpine.LNX.firstname.lastname@example.org> <email@example.com> <20161207174413.GP2767@gate.crashing.org>
* Segher Boessenkool:
> On Wed, Dec 07, 2016 at 06:27:56PM +0100, Florian Weimer wrote:
>> >> > When I am writing a test with noinline + noclone then my
>> >> > expectation is that no such propagation happens, because
>> >> > otherwise a test might turn trivial...
>> >> The usual ways to prevent that are to add some volatile, or an
>> >> asm("" : "+g"(some_var)); etc.
>> > No, that doesn't sound right. As far as I can tell from looking
>> > that the GCC testsuite, the prevailing way is actually the
>> > noinline+noclone combo, not the per-argument asms or volatiles.
>> Agreed, that's what I've been using in the past for glibc test cases.
>> If that doesn't work, we'll need something else. Separate compilation
>> of test cases just to thwart compiler optimizations is a significant
>> burden, and will stop working once we have LTO anyway.
>> What about making the function definitions weak? Would that be more
> It depends a lot on what you want the test to actually test.
The most recent case was about constructing the expected call stack
for an unwinder test.
In another test, I needed to perform free (malloc (1)).
> Just sprinkling noinline,noclone everywhere as a poor man's "DWIM"
> just does not work.
Maybe we should compile all glibc tests twice, once with
-ffreestanding, and once without, so that we test both the
implementation and what an application would do. But I don't know if
-ffreestanding would even work this way.