From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8081 invoked by alias); 27 Jan 2002 13:34:26 -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 8050 invoked from network); 27 Jan 2002 13:34:24 -0000 Received: from unknown (HELO CORESMTP1.ex.riotinto.org) (57.70.13.255) by sources.redhat.com with SMTP; 27 Jan 2002 13:34:24 -0000 Received: from corehub1.ex.riotinto.org ([203.3.63.116]) by CORESMTP1.ex.riotinto.org with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 00:35:01 +1100 Received: from tbspmail.corp.riotinto.org ([192.207.121.96]) by corehub1.ex.riotinto.org with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 00:35:01 +1100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Plan for bug-fixing g77-3.1. X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Sun, 27 Jan 2002 09:49:00 -0000 Message-ID: <8D00C32549556B4E977F81DBC24E985D4101E5@crtsmail1.technol_exch.corp.riotinto.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Plan for bug-fixing g77-3.1. Thread-Index: AcGl/jEwoV7VRIvSQj2AmA3UTKY70QBOMX7A From: "Billinghurst, David (CRTS)" To: "Toon Moene" , X-OriginalArrivalTime: 27 Jan 2002 13:35:01.0217 (UTC) FILETIME=[6B878D10:01C1A737] X-SW-Source: 2002-01/txt/msg01755.txt.bz2 This doesn't seem to work for me on irix. I am away from the office, but w= ill have a look once I get back.=20=20=20 -----Original Message----- From: Toon Moene [mailto:toon@moene.indiv.nluug.nl] Sent: Saturday, 26 January 2002 11:10=20 To: gcc@gcc.gnu.org Subject: Re: Plan for bug-fixing g77-3.1. I wrote: > I'm planning to do the following to fix extant bugs in g77 for the 3.1 > release: >=20 > 1. PR 3743 Reference to intrinsic `ISHFT' invalid >=20 > This is due to the subtle bug in the intrinsics table that David > Edelsohn showed. I'll probably follow his advice in >=20 > http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00000.html >=20 > (use strcasecmp in libiberty) to fix this problem. The proposed patch is attached - it passes make bootstrap (C and Fortran), make check (Fortran only) and make install (C and Fortran) on i686-pc-linux-gnu. I send it to the list now, so that other people might try it on their systems. I'll certainly _not_ commit it before it passes on SPARC, MIPS, Alpha and PowerPC. Now for the proof that this is correct. As David Edelsohn showed, the intrinsics table of g77 (in f/intrin.def) is sorted _on the upper case names only_. This means that, in order to fix the deficiency, we have to rely on comparing to the the upper case entry only as long as this defines the search direction for `bsearch'. The attached patch does that. It first compares the would-be-intrinsic-name case-insensitively to the upper case entry of the table. In case the g77 options indicate that intrinsics have no case sensitivity or are upper case only, the result of this comparison is used directly. In case the g77 options indicate that intrinsics should have been written in lower case, the next comparison is against the exact lower case name. In case the g77 options indicate that intrinsics should have been written to a predefined "initial caps" convention, the next comparison is against the string according to that convention. If the case-insensitive comparison to the upper case entry didn't match, the comparison is returned, which will direct `bsearch' in choosing the right half of the table for further search. The interesting part is what happens if the case insensitive comparison succeeds, but the case sensitive one doesn't. Due to the fact that `bsearch' will always either choose or cut a half, this search must terminate in case there's no match. Because the comparison that's returned is always the same for each entry of the 380-entry table for invariant "intrinsic capitalisation mode", this will always be the case. End-of-proof. Note that I do not have to prove anything about alias analysis in Fortran - that's dead simple by comparison: If you don't indicate to the compiler that two items can overlap (by using EQUIVALENCE) they better don't - or else [1]. --=20 Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction) [1] According to the comp.lang.fortran FAQ, "or else" means: "could start=20 WW III, if the right - optional - hardware is installed." Obviously, the comp.lang.fortran FAQ was written during the Cold War.