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
> > assignment and the asm. (Don't confuse this with the
> > asm-clobber operands which I think you covered fine.) Those
> > details are maybe not thoughtfully described, but they can't be
> > just plainly removed as they also serve as gcc specification;
> > definitions as to what works and doesn't work! (I don't know if
> > that was the only occurrence.)
>
> I don't believe that section you are talking about was actually deleted, but
> has instead been moved (along with "Asm Labels" and "Size of an asm").
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 you need to make an
@code{asm} operand be a specific register, but there's no
matching constraint letter for that register" and had the two
"sysint" examples? Maybe best placed in a separate subsection
cross-referenced from the "top" Extended-Asm Remarks section or
when first discussing constraints, in the "Output Operands"
subsection.
> Looking at the new docs, instead of those sections being buried with the ~60
> other items like in the old docs
> (http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/C-Extensions.html), (nearly) all
> the asm-related subjects got moved here
> (http://www.LimeGreenSocks.com/gcc/Using-Assembly-Language-with-C.html).
> That's what the "minor reorg of asm-related sections" was about.
I did get this, I read the thread. But, speaking of that, I
can't find anyone mentioning the copyright issue. Maybe people
didn't want to scare you away... Someone has said that FSF were
moving towards it sometimes wouldn't be required anymore, but
that comment was made about a year ago and I don't know if
anything has actually changed, so: assuming this is "still"
required, are copyright assignment papers in place with the FSF
for these changes? I can't find any "dw" (or maybe too many) in
the canonical copyright.list just refreshed so I can't tell.
> > 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)
> > IIRC this is from Linux, but I don't think GCC ever promised the
> > described semantics, and I don't think we should document
> > something that works just by accident. Do we want to make that
> > promise now?
>
> I got that trick (formatting and all) from the existing docs. Such being the
> case, the question is do we want to @emph{stop} promising something that we
> used to?
No, absolutely not. This is the joy of reorganising things
(code as well as docs): you get blamed for old warts and errors
as well! :-)
> > > Bootstrapping and testing:
> > > I have tested "make html" to produce html files, but my configuration
> > > doesn't
> > > allow for the "make dvi" test.
> > That requirement is somewhat arcane
>
> I got it off the contrib page (http://gcc.gnu.org/contribute.html#docchanges)
> when I was trying to figure out the "proper" way to submit this. If this is
> no longer a requirement, perhaps this should be updated.
(I know you later got this, so just for the record here): I
wrote "arcane" here, not "obsolete" as I meant that perhaps dvi
should be replaced by pdf, but maybe not. The point is to check
that the layout works for the printable version which has
stricter formatting requirements than the html version. I know
it spews lots of warnings; changes are supposed to not make this
worse. If it errors out due to formatting changes before your
changes: no, you don't have to fix it.
brgds, H-P
