On 04/04/14 20:48, dw wrote:
> I do not have write permissions to check this patch in.
We must fix that.
Andrew.
> Fixed.
Thanks!
--
Eric Botcazou
On 05/29/2014 11:22 AM, Eric Botcazou wrote:
>> Yes. We already know that this is better than the current docs.
>> Let's check it in.
>
> As far as I can see you did it, but didn't add a ChangeLog entry (so David
> isn't properly credited with the rewrite)?
Fixed.
Thanks,
Andrew.
> Yes. We already know that this is better than the current docs.
> Let's check it in.
As far as I can see you did it, but didn't add a ChangeLog entry (so David
isn't properly credited with the rewrite)?
--
Eric Botcazou
On Mon, 5 May 2014, Gerald Pfeifer wrote:
> > I've changed this to @code{"="}. Is that what you meant?
>
> This is a question for Joseph. I see how a single character
> under @code{} won't work, yet @code{"="} doesn't feel right,
> either. Perhaps ``@code{=}''?
If you are referring to an actu
On 05/05/2014 09:23 PM, Gerald Pfeifer wrote:
> Understood. Let's see that we can get an update committed soon.
> We can always improve on it further later on, which then will be
> a lot easier to do, review, and get pushed.
Yes. We already know that this is better than the current docs.
Let's c
+A combination that works in most places is a newline to break the
+line, plus a tab character to move to the instruction field (written
+as "\n\t").
Will everyone know what an instruction field is? I'm not sure it's
that common of a term.
Hmm. I brought that text across unchanged from the o
[ Oh no! I wrote this on a plane two days ago and now it got stuck
in my outbox. Let's get this patch in before any further delays
happen. ]
On Sun, 27 Apr 2014, dw wrote:
> The goal of this patch was to rewrite section 6.41. That's no simple
> task, since 6.41 was ~10 very full pages. U
On 4/29/2014 5:48 AM, Richard Earnshaw wrote:
On 29/04/14 11:47, dw wrote:
While I'm waiting to hear back from Gerald about my responses to his
other corrections, I have answered one question:
How does the user know what is dialect #0? Same for the others?
When I originally wrote that secti
On 29/04/14 11:47, dw wrote:
> While I'm waiting to hear back from Gerald about my responses to his
> other corrections, I have answered one question:
>
>> How does the user know what is dialect #0? Same for the others?
>>
>> When I originally wrote that section, I didn't know the answer (which
While I'm waiting to hear back from Gerald about my responses to his
other corrections, I have answered one question:
How does the user know what is dialect #0? Same for the others?
When I originally wrote that section, I didn't know the answer (which
is why I left it vague). Now I think I
On 04/27/2014 11:56 AM, Richard Kenner wrote:
> any symbols it references. This may result in those symbols getting
> discarded by GCC as unreferenced.
>>>
>>> We can omit "by GCC" here.
>>
>> We can, but we should not. We should avoid the passive voice like the
>> plague in technical docu
Please take my comments below into account for an updated patch, and
once Andrew and Richard have signed of, this is then good to commit.
You did raise a technical question I'd like to get Andrew, Richard or
someone to comment on:
How does the user know what is dialect #0? Same for the oth
> >>> any symbols it references. This may result in those symbols getting
> >>> discarded by GCC as unreferenced.
> >
> > We can omit "by GCC" here.
>
> We can, but we should not. We should avoid the passive voice like the
> plague in technical documentation, even if doing so leads to some
> slig
On 04/26/2014 10:33 PM, Gerald Pfeifer wrote:
>>> +any symbols it references. This may result in those symbols getting
>>> discarded
>>> >> +by GCC as unreferenced.
> We can omit "by GCC" here.
We can, but we should not. We should avoid the passive voice like the
plague in technical documentati
The perfect is the enemy of the good.
>From all I have seen and heard, this rewrite is a clear improvement
over the status quo. So I am going to review and approve it wearing
my doc maintainer hat, deferring to and relying on Andrew and Richard
and their deep expertise on the technical side.
On 04/25/2014 04:43 PM, James Greenhalgh wrote:
> Beyond comments on ChangeLog formatting, the review for this patch seems
> to have stalled again.
>
> The patch has been in review for two months now, with broadly positive
> comments
> and all suggestions made thus far have been incorporated. I'd
2014-04-14 14:24 GMT+08:00 dw :
> Having resolved the objections, I'm posting the updated patch. I don't have
> permissions to commit this patch, but I do have a release on file with the
> FSF.
>
>
> Problem description:
> The existing documentation does an inadequate job of describing gcc's
> imp
2014-04-14 14:24 GMT+08:00 dw :
> Having resolved the objections, I'm posting the updated patch. I don't have
> permissions to commit this patch, but I do have a release on file with the
> FSF.
>
>
> Problem description:
> The existing documentation does an inadequate job of describing gcc's
> imp
On Sun, 13 Apr 2014, dw wrote:
> So, how about this:
>
> 1) I put the (rephrased) text and examples at the end of "Local Reg Vars" page
> (starts with "Sometimes"):
> http://www.LimeGreenSocks.com/gcc/Local-Reg-Vars.html
> 2) In the constraint paragraph for both Input and Output, I added this: "If
No, it does seem deleted, I can't find it. I can only find its
deletion in the patch, not any re-insert or rewrite and I can't
find this information in the web-pages at limegreensocks. To
wit: where's the corresponding information; the replacement for
the section which started with "Sometimes
On Tue, 8 Apr 2014, dw wrote:
> > The general bits seems like a big improvement, but what worries
> > me is the deleted text. For example, the aspects of "Explicit
> > Reg Vars" when *directly feeding an asm* and how to write them
> > to avoid the named registers being call-clobbered between
> > a
Hans-Peter Nilsson: Did you have any follow up here? Or did this
response (below) address all your concerns?
I have made some minor corrections since this post:
- "make dvi" now builds my text without errors (can't say this for the
rest of extend.texi).
- All (instead of nearly all) the asm-r
Hi,
On Tue, 8 Apr 2014, Hans-Peter Nilsson wrote:
> Also, do we really want to document the trick in
> "m" ((@{ struct @{ char x[10]; @} *p = (void *) ptr ; *p; @}))
> (note: reformatted GNU-style and confusing @{ @} dropped)
We already document this since quite some time, and yes, it's indeed
On Fri, 4 Apr 2014, dw wrote:
> Problem description:
> The existing documentation does an inadequate job of describing gcc's
> implementation of the "asm" keyword. This has led to a great deal of
> confusion as people struggle to understand how it works. This entire section
> requires a rewrite th
25 matches
Mail list logo
