From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14481 invoked by alias); 8 Sep 2004 12:22:49 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 14448 invoked from network); 8 Sep 2004 12:22:45 -0000 Received: from unknown (HELO sophia.inria.fr) (138.96.64.20) by sourceware.org with SMTP; 8 Sep 2004 12:22:45 -0000 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i88CMjLU007037 for ; Wed, 8 Sep 2004 14:22:45 +0200 Received: from chronos.inria.fr (chronos.inria.fr [138.96.66.3]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i88CKxsB006246 for ; Wed, 8 Sep 2004 14:20:59 +0200 Received: from chronos.inria.fr (localhost.localdomain [127.0.0.1]) by chronos.inria.fr (8.12.11/8.12.5) with ESMTP id i88CKxjB014130 for ; Wed, 8 Sep 2004 14:20:59 +0200 Received: (from mlacage@localhost) by chronos.inria.fr (8.12.11/8.12.11/Submit) id i88CKxgq014129 for gcc@gcc.gnu.org; Wed, 8 Sep 2004 14:20:59 +0200 X-Authentication-Warning: chronos.inria.fr: mlacage set sender to Mathieu.Lacage@sophia.inria.fr using -f Subject: newsletter #10 From: Mathieu Lacage To: gcc Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1094646058.14103.1.camel@chronos.inria.fr> Mime-Version: 1.0 Date: Wed, 08 Sep 2004 12:22:00 -0000 X-Virus-Scanned: by amavisd-new at sophia.inria.fr X-SW-Source: 2004-09/txt/msg00355.txt.bz2 hi all, http://gccnews.chatta.us/ or, for your conveniance: gcc release Mark Mitchell sent in a gcc status summary[1] for gcc 3.4.2. He then declared the 3.4.2 branch frozen[2], released[3] 3.4.2-RC1, then 3.4.2-RC2 and then 3.4.2[4]. Mark also sent in a gcc 3.5 status summary[5] which, not surprisingly, triggered a few more or less angry mails about projects dropped in or out of the 3.5 release. It is clear to everyone that if the 3.5 release follows the path set forward by Mark, it will suffer from the dot-zero[6] syndrome. Although some people are very unhappy by this and would prefer to delay the release for a few months to try to make gcc 3.5 really better all the time than previous releases, this is unlikely to happen (There is a strong argument against such a move since it is well known that delaying a release to work more on it often, strangely-enough, entices engineers to write more code and thus more bugs. hrm. I certainly never do that, Do I ?). gcc development Daniel Berlin spent a bit of time gathering information on the current register allocator work and on future directions. He summarized the status of the current architecture in this mail[7]. Another thread was started by Caroline Tice to provide a bit more information[8] on the topic. More compiler warnings are always good. It looks like the OpenBSD folks added the sentinel (a [.] checker that can verify that varargs functions such as execl(cmd, arg1, arg2, NULL) are indeed null-terminated (when the arguments are constant)) attribute to their 2.95 gcc. Marc Espie posted the patch[9] implementing this for 2.95 gccs. Hopefully, this will get in someday. Work on new optimization passes for gcc has not stalled despite the tentative release schedule. Revital Eres sent a new version of his Variable Exansion Optiomization[10] pass. documentation Anthony Green posted a link to the original design document[11] for gcj by Cygnus back in the old days. Thanks to Joe Buck and Daniel Berlin, the gcc summit proceedings have now been split into separate papers and are hosted on gcc.gnu.org[12]. libstdc++ Contributed by jcopenha (jcopenha at typedef dot org) The libstdc++ mailing list is a rather low volume list. There were some patches submitted this week. The first[13] being a fix for do_get_time in time_get::get_time to handle leap seconds correctly. To stay in alignment with C99 if _GLIBCXX_USE_C99 is defined the valid values for seconds are 0 - 60, if using C89 0 - 61. An interesting paper on the history of leap seconds[14] was also posted. The second was a fix[15] for PR libstdc++/17215, __basic_fileunderlying fclose call. This meant the user never new if __basic_fileto soon, if for instance fclose failed with EINTR. It was decided to mimic the read and write behavior and loop on EINTR. [0] http://gcc.gnu.org/ml/gcc/2004-08/msg01117.html [1] http://gcc.gnu.org/ml/gcc/2004-08/msg01412.html [2] http://gcc.gnu.org/ml/gcc/2004-08/msg01415.html [3] http://gcc.gnu.org/ml/gcc/2004-09/msg00348.html [4] http://gcc.gnu.org/ml/gcc/2004-08/msg01418.html [5] http://gcc.gnu.org/ml/gcc/2004-08/msg01446.html [6] http://gcc.gnu.org/ml/gcc/2004-08/msg00900.html [7] http://gcc.gnu.org/ml/gcc/2004-08/msg00904.html [8] http://gcc.gnu.org/ml/gcc/2004-08/msg01105.html [9] http://gcc.gnu.org/ml/gcc/2004-08/msg01050.html [10] http://www.spindazzle.org/cygnus/design.html [11] ftp://gcc.gnu.org/pub/gcc/summit/ [12] http://gcc.gnu.org/ml/libstdc++/2004-08/msg00215.html [13] http://www.cl.cam.ac.uk/~mgk25/time/metrologia-leapsecond.pdf [14] http://gcc.gnu.org/ml/libstdc++/2004-08/msg00220.html Mathieu -- Mathieu Lacage