This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Mark explicit decls as implicit when we've seen a prototype
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Joseph Myers <joseph at codesourcery dot com>, gcc-patches at gcc dot gnu dot org, jason at redhat dot com
- Date: Mon, 8 Dec 2014 14:04:29 +0100
- Subject: Re: [PATCH] Mark explicit decls as implicit when we've seen a prototype
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1412041144520 dot 8254 at zhemvz dot fhfr dot qr> <alpine dot DEB dot 2 dot 10 dot 1412041430430 dot 23422 at digraph dot polyomino dot org dot uk> <alpine dot LSU dot 2 dot 11 dot 1412041603120 dot 8254 at zhemvz dot fhfr dot qr> <alpine dot DEB dot 2 dot 10 dot 1412041520420 dot 23422 at digraph dot polyomino dot org dot uk> <alpine dot LSU dot 2 dot 11 dot 1412041619040 dot 8254 at zhemvz dot fhfr dot qr> <alpine dot DEB dot 2 dot 10 dot 1412041538390 dot 23422 at digraph dot polyomino dot org dot uk> <alpine dot LSU dot 2 dot 11 dot 1412081309380 dot 8254 at zhemvz dot fhfr dot qr> <20141208124453 dot GF1667 at tucnak dot redhat dot com> <alpine dot LSU dot 2 dot 11 dot 1412081350250 dot 8254 at zhemvz dot fhfr dot qr>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Dec 08, 2014 at 01:54:21PM +0100, Richard Biener wrote:
> On Mon, 8 Dec 2014, Jakub Jelinek wrote:
>
> > On Mon, Dec 08, 2014 at 01:24:12PM +0100, Richard Biener wrote:
> > > I'm not pushing this further for stage3, but for stage1 I'd like
> > > to eventually address this by splitting up builtin_info_type's
> > > 'implicit_p' into a flags array providing implicit_p, declared_p,
> > > used_p and maybe declared_in_system_header_p. Would you be
> > > willing to fill in the gap computing "used_p" in the C frontend?
> >
> > The used_p thing might be problematic, I'd expect that several packages
> > use libm functions somewhere in dead code or when it is folded into
> > a constant and don't link with -lm, if those dead or optimized away
> > uses would be counted as uses nevertheless, then if optimizers create new
> > libm references because of those, I'd be afraid such programs wouldn't link
> > anymore.
>
> Same applies to your STPCPY special-casing, even without introducing
> a use.
Well, the important difference there is that stpcpy is in libc, not libm,
and you get the former by default usually (-nostdlib is very rare).
Yes, supposedly overall uses libc, uses libm flags would be reasonable.
> The alternative is to decide "used" in the middle-end at one point,
> for example at the end of all_lowering_passes where hopefully
> we have constant folded and removed dead code enough. We can also
> compute an overall "uses libm" flag to fix the testcase I reported
> (of course we'd like to re-compute that at LTO time).
>
> Do you think that's better? It's of course less well-defined what
> is a "use" of exp10 then (as opposed to what Joseph specified
> with a reference outside of sizeof() and similar contexts).
Jakub