This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Proposed doc update for Explicit Reg Vars 3/3
- From: David Wohlferd <dw at LimeGreenSocks dot com>
- To: Jeff Law <law at redhat dot com>, Andrew Haley <aph at redhat dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Sandra Loosemore <sandra at codesourcery dot com>
- Date: Tue, 20 Oct 2015 21:35:06 -0700
- Subject: Re: Proposed doc update for Explicit Reg Vars 3/3
- Authentication-results: sourceware.org; auth=none
- References: <561C3DAE dot 8050505 at LimeGreenSocks dot com> <5625CF7E dot 5010003 at redhat dot com> <20151020151312 dot GB25514 at gate dot crashing dot org> <56266519 dot 8070104 at redhat dot com> <56266630 dot 2050800 at redhat dot com> <562667FF dot 5000003 at redhat dot com> <562668B5 dot 6040404 at redhat dot com> <56266A5D dot 80809 at redhat dot com> <56266E4D dot 1060303 at redhat dot com> <56267219 dot 4080008 at redhat dot com>
I'm trying to sum up what was discussed here. What I'm hearing is
(quoting Jeff):
> the technical reality is I can't see a use outside the extended asm.
Andrew has discussed some other uses, but as Jeff observed:
> Given the way the optimizers and register allocation work,
> I don't think we can make guarantees around [Andrew's] use
> of the feature. It happens to still work and may work
> forever, but I'm not going to set it in stone.
If the only usage we are prepared to "set in stone" is extended asm,
then it follows that that is the only supported usage. Areas of
"non-guaranteed behavior" are things the docs should actively discourage
people from using.
Given this, I'm going to go ahead and re-work the local register
variables page (probably tomorrow) stating extended asm is the only
supported usage. Although I also think it's important to mention
Andrew's point. If someone sees it in code somewhere, at least the docs
will give them some idea what is going on.
Stop me if I've got this all wrong...
> dealing with any blow-back we get along the way
Since no one is proposing any code changes here, it's not like people's
programs are going to stop working tomorrow. It's possible that some
future code change to the Local Register Variables feature (perhaps
provoked by this doc change) will break something. But if the broken
use case is deemed valid, it's the *code* change that should get the
blow-back, not the doc change. Hopefully when that happens, the new use
case will then be added to the Local Register Variables docs. Probably
as a chunky block at the end of the page, but still...
Or did I miss your point?
Nobody has commented on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64951 (register variable
with template function). While I'm updating the page, is this a
limitation of Local Register Variables that should be doc'ed?
dw