Re: FD_ZERO: Request for FAQ entry

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> The subject says it already: It would be great if someone knowledgeable
> could submit a FAQ entry regarding that FD_ZERO stuff...

Uh, wouldn't this match the asmclobber entry?
 To answer this myself: apparently not often enough, from a user
perspective, although it's (AFAICT) a perfect match with no
questions unanswered.

How can we improve this (perceived) situation; that the FAQ
entries are not understood well enough on their own?
 Should we provide cross-references from experienced problem
perspectives to canned FAQ items with brief summaries?
As below?

Note that this is just a suggested *outline* of changes; I do
not know if this particular (asmclobber-)problem is *exactly*
confined to the libc-5.4.46 release, or if there is a specific
version of something (libc5?) that remedies the problem.

I do not think everybody's package with buggy code should be
filled-in here, just the big ones, reported (multiple times) to
an egcs list...

Maybe the asmclobber entry and stuff from the linuxkernel entry
should be moved to this new list (and the list moved to a page
of its own), with specific examples of what packages break and
how the breakage looks like.  I don't know.  Just thoughts.

Index: faq.html
===================================================================
RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/faq.html,v
retrieving revision 1.76
diff -p -c -r1.76 faq.html
*** faq.html	1998/11/20 14:12:42	1.76
--- faq.html	1998/11/22 01:31:32
*************** comp.std.c++ FAQ</a>.
*** 25,30 ****
--- 25,34 ----
    <li><a href="#mips">Problems building on MIPS platforms</a>
    <li><a href="#x86eh">Problems with exception handling on x86 platforms</a>
    <li><a href="#asmclobber">Problems with <tt>Invalid `asm' statement</tt>s</a>
+   <li><a href="#othercc">Problems with code that works with other compilers or earlier gcc releases:</a>
+   <ul>
+     <li><a href="#fdzero">FD_ZERO macro</a>
+   </ul>
    <li><a href="#hpcompare">Bootstrap comparison failures on HPs</a>
    <li><a href="#makebugs">Bootstrap loops rebuilding cc1 over and over</a>
    <li><a href="#rpath">Dynamic linker is unable to find GCC libraries</a>
*************** buggy assembler.
*** 322,327 ****
--- 326,345 ----
  Or, you can try a
  <a href="ftp://egcs.cygnus.com/pub/egcs/infrastructure/gas-970915.tar.gz"> binutils snapshot</a>; however, be aware that the binutils snapshot is untested
  and may not work (or even build).  Use it at your own risk.
+ 
+ <hr>
+ <h2><a name="othercc">Problems with code that works with other compilers or earlier gcc releases:</a></h2>
+ <p>Improvements in tools that are widely used are sooner or
+ later unfortunately bound to break <i>something</i>.  Sometimes,
+ the code that breaks was wrong, and then the code should be
+ fixed, even if it works for earlier versions of gcc or other
+ compilers.  The following problems with widely used code
+ packages of some releases have been identified:
+ <ul>
+   <li><h3><a name="fdzero">FD_ZERO macro</a></h3>
+   <p>The FD_ZERO macro in (e.g.) libc-5.4.46 is incorrect, it's
+   uses <a href="#asmclobber">invalid asm clobbers</a>.
+ </ul>
  
  <hr>
  <h2><a name="asmclobber">Problems with invalid `asm' statements</a></h2>


Just for reference, here's the answer to the daily x86
gcc-asm-clobber exercise (unchecked and uncompiled for your
amusement):

# define __FD_ZERO(fdsetp) \
  __extension__ ({         \
  int __Dummy1, __Dummy2;  \
  __asm__ __volatile__ ("cld; rep; stosl"				      \
			: "=c" (__Dummy1), "=D" (__Dummy2),		      \
                          "=m" ((fdsetp)->fds_bits[__FDELT (__FD_SETSIZE)])   \
			: "a" (0), "0" (sizeof (__fd_set)		      \
					/ sizeof (__fd_mask)),		      \
			  "1" (&(fdsetp)->fds_bits[0])			      \
			:"memory"); })

brgds, H-P