From gcc-return-59279-listarch-gcc=gcc dot gnu dot org at gcc dot gnu dot org Tue Aug 27 21:52:20 2002 Return-Path: Delivered-To: listarch-gcc at gcc dot gnu dot org Received: (qmail 9944 invoked by alias); 27 Aug 2002 21:52:20 -0000 Mailing-List: contact gcc-help at gcc dot gnu dot org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner at gcc dot gnu dot org Delivered-To: mailing list gcc at gcc dot gnu dot org Received: (qmail 9936 invoked from network); 27 Aug 2002 21:52:19 -0000 Received: from unknown (HELO kiruna.synopsys.com) (204.176.20.18) by sources dot redhat dot com with SMTP; 27 Aug 2002 21:52:19 -0000 Received: from mother.synopsys.com (mother.synopsys.com [146.225.100.171]) by kiruna dot synopsys dot com (Postfix) with ESMTP id 2067BF2F2; Tue, 27 Aug 2002 14:52:19 -0700 (PDT) Received: from atrus.synopsys.com (localhost [127.0.0.1]) by mother dot synopsys dot com (8 dot 9 dot 1/8 dot 9 dot 1) with ESMTP id OAA04029; Tue, 27 Aug 2002 14:52:01 -0700 (PDT) From: Joe Buck Received: (from jbuck@localhost) by atrus dot synopsys dot com (8 dot 9 dot 3+Sun/8 dot 9 dot 1) id OAA29945; Tue, 27 Aug 2002 14:52:17 -0700 (PDT) Message-Id: <200208272152.OAA29945@atrus.synopsys.com> Subject: Re: documenting C++ and libstdc++ ABI issues To: jsm28 at cam dot ac dot uk (Joseph S dot Myers) Date: Tue, 27 Aug 2002 14:52:17 -0700 (PDT) Cc: janis187 at us dot ibm dot com (Janis Johnson), gcc at gcc dot gnu dot org In-Reply-To: from "Joseph S dot Myers" at Aug 27, 2002 08:08:00 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > On Tue, 27 Aug 2002, Janis Johnson wrote: > > > This information is of interest to GCC users, not just developers, so > > it should be in the GCC manual rather than the internals manual. > > There's a need for user information about when ABI incompatibilities > affect linking code built with different compilers or compiler versions. > But there's also a need for the technical documentation defining what the > ABI is, where this goes beyond the external standards (e.g., the ABI for > code using GCC extensions), and what the actual "3.2 ABI" is in cases > where it differs from the specification (whereas the user documentation > need only discuss what code is affected, not the detailed differences in > those cases). I feel that technical documentation fits better in the > internals manual. Users will wish to know how to avoid code that tweaks one of the incompatibilities, and such an explanation could appear in the user manual. Beyond that, I'd agree that the main guts go in internals.